Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-ext

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 23 Feb 2012 22:12:44 +0000

All,

This starts a two-week working group last call on draft-ietf-ccamp-assoc-ext.

This working group last call ends March 8th. Please send your comments to the CCAMP mailing list.

Deborah (and Lou)

---

From: [email-masked]
Date: Fri, 24 Feb 2012 16:15:33 +0800

Just one comment about the citations.

As described in section 3.1, the Association ID and Association Source is 
the same as defined in RFC4872.

And according to the description in section 16.1 of RFC4872, cited here

" Association ID: 16 bits
         A value assigned by the LSP head-end.  When combined with the
         Association Type and Association Source, this value uniquely
         identifies an association."

" Association Source: 4 or 16 bytes
         An IPv4 or IPv6 address, respectively, that is associated to
         the node that originated the association."

<fei> 

(1) When the association object is used for the co-routed bidirectional 
LSP, the tunnel ID locally assigned at Z9 node maybe be filled here, 
however,
it is not assigned by the LSP head-end (A1 node), or we can interpret that 
Z9 is also the LSP head-end?

(2) Another usecase is that for the associated bidirectional LSP, this 
field maybe be filled by the the tunnel ID of the forward LSP1 or the 
backward LSP2. If it is the tunnel ID of LSP1, which is not assigned by 
the LSP2 head-end. 

(3)Similarly as above, the association source maybe be related to A1 or Z9 
node, and both of them are the nodes that originate the association when 
double sided provisionging mode is used.

(3)In the general scenarios, the combination of Association Type, 
Association Source, Global Association Source and extended Association id 
will identify
an association.

Just my2cents, the descriptions about the association source and id are 
accurate under the scope of RFC4872, but the direct citation from RFC4872 
is not accurate here if we consider the more usecases. Can the limitation 
be released or these words be organized in another way?

</fei>

Best regards

Fei

"BRUNGARD, DEBORAH A" <[email-masked]> 
发件人:  [email-masked]
2012-02-24 06:12

收件人
CCAMP <[email-masked]>
抄送

主题
[CCAMP] WG Last Call on draft-ietf-ccamp-assoc-ext

All,

This starts a two-week working group last call on 
draft-ietf-ccamp-assoc-ext.

This working group last call ends March 8th. Please send your comments to 
the CCAMP mailing list.

Deborah (and Lou)

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Fri, 24 Feb 2012 12:53:57 -0500

Fei,
	see below for in-line responses.

On 2/24/2012 3:15 AM, [email-masked] wrote:
> As described in section 3.1, the Association ID and Association Source
> is the same as defined in RFC4872.
> 
> it is not assigned by the LSP head-end (A1 node), or we can interpret
> that Z9 is also the LSP head-end?
> 

The intent was that "the association ID is selected by the node creating
the association object".  This should be explicitly stated by the draft.
 This is an important clarification and will result in a few tweaks to
the current document.

Good catch.

> backward LSP2. If it is the tunnel ID of LSP1, which is not assigned by

Agreed.  I think the above revision will accommodate this.

> 
> (3)Similarly as above, the association source maybe be related to A1 or
> Z9 node, and both of them are the nodes that originate the association
> when double sided provisionging mode is used.

same response...

> Association Source, Global Association Source and extended Association
> id will identify
> an association.

I'm not clear on your comment here.  Does this relate to specific text?
 Are you looking for a change in the draft?  Please clarify.

> accurate under the scope of RFC4872, but the direct citation from
> RFC4872 is not accurate here if we consider the more usecases. 

I think we're in agreement.

> Can the
> limitation be released or these words be organized in another way?

Yes, will revise as part of the post-LC revision.

Thanks,
Lou
> 
> </fei>
> 
> 
> Best regards
> 
> Fei
> 
> 
> *"BRUNGARD, DEBORAH A" <[email-masked]>*

---

From: Lou Berger <[email-masked]>
Date: Fri, 24 Feb 2012 13:38:22 -0500

Fei/All,
I propose to address the Fei's comments by adding the following new
section to the document. (as well as some other related editorial changes.)

2. Modified Association ID Field Definition

The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION
objects defined in [RFC4872]. The [RFC4872] definition of the field
reads:

A value assigned by the LSP head-end. When combined with the
Association Type and Association Source, this value uniquely
identifies an association.

This document allows for the origination of ASSOCIATION objects by
nodes other than "the LSP head-end". As such, the definition of the
Association ID field needs to be modified to accommodate such usage.
This document defines the Association ID field of the IPv4 and IPv6
ASSOCIATION objects as:

A value assigned by the the node that originated the association.
When combined with the Association Type and Association Source,
this value uniquely identifies an association.

This change in definition does not impact [RFC4872] or [RFC4873]
defined procedures or mechanisms, nor does it impact existing
implementations of [RFC4872] or [RFC4873].

I believe this addresses the comment. Let me know if you disagree, or
have other comments.

Much thanks,
Lou (draft co-author)

---

From: [email-masked]
Date: Mon, 27 Feb 2012 09:20:18 +0800

Lou 

Thanks for your response immediately, and I think that the revised 
sentence "A value assigned by the the node that originated the association
" reflects my comments precisely.

According to the section 3.1 of the draft draft-ietf-ccamp-assoc-ext, the 
Extended Associaiton object is defined by adding two fields in the old 
Association 
object, one is the Global Association Source and the other is the Extended 
Association ID. In some cases, for example, like an LSP across different 
ASs, or 
the Association ID field is insufficient, the association is uniquly 
identified by the combination of Association Type、Association Source、
Global Association
Source and Extended Association ID. Of cource, the Global Association 
Source maybe be set to zero, or the length of the Extended Association 
field is zero.

So as to the second revised sentence that "When combined with the 
Association Type and Association Source, this value uniquely identifies an 
association", which
may let the readers think that the Global Association Source and the the 
Extended Association ID are not used to identify an association uniquly.

What about the revision like "When combined with the Association Type、
Association Source、Global Association Source and Extended Association ID, 
this value uniquely identifies an association" or in other way if you 
think the clarification is useful?

Best

Fei

Lou Berger <[email-masked]> 
2012-02-25 02:38

收件人
[email-masked]
抄送
"[email-masked]" 
<[email-masked]>, "BRUNGARD, DEBORAH A" 
<[email-masked]>, CCAMP <[email-masked]>
主题
Re: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-ext

Fei/All,
I propose to address the Fei's comments by adding the following new
section to the document. (as well as some other related editorial 
changes.)

Much thanks,
Lou (draft co-author)

---

From: [email-masked]
Date: Mon, 27 Feb 2012 09:29:11 +0800

Lou

<fei> Sorry for the unclear description, please check my response in 
another mail which is the same. </fei>

Best 

Fei

2012-02-25 01:53

收件人
[email-masked]
抄送
"BRUNGARD, DEBORAH A" <[email-masked]>, CCAMP <[email-masked]>, 
[email-masked]
主题
Re: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-ext

Fei,

Good catch.

same response...

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Feb 2012 10:32:12 -0500

Fei,
	Okay, but I think we're really splitting hairs here.  I'll change it to:

      A value assigned by the the node that originated the association.
      When combined with the other fields carried in the object, this
      value uniquely identifies an association.

I think this covers all possible uses/interpretations.

Lou

On 2/26/2012 8:20 PM, [email-masked] wrote:
> sentence "A value assigned by the the node that originated the
> association" reflects my comments precisely.
> 
> According to the section 3.1 of the draft draft-ietf-ccamp-assoc-ext,
> the Extended Associaiton object is defined by adding two fields in the
> old Association
> object, one is the Global Association Source and the other is the
> Extended Association ID. In some cases, for example, like an LSP across
> different ASs, or
> Association Type and Association Source, this value uniquely identifies
> an association", which
> Association Source、Global Association Source and Extended Association
> ID, this value uniquely identifies an association" or in other way if
> you think the clarification is useful?
> 
> Best
> 
> Fei
> 
> 
> *Lou Berger <[email-masked]>*
> 
> 2012-02-25 02:38
> 
> 	
> 收件人
> 	[email-masked]
> 抄送