Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Hi Lou,

Please see inline..<RG2>.

-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Tuesday, August 28, 2012 12:02 PM
To: Rakesh Gandhi (rgandhi)
Cc: [e-mail]; [e-mail]
Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,
	See below.

On 8/28/2012 11:28 AM, Rakesh Gandhi (rgandhi) wrote:
> Hi Lou,
> 
> Please see inline..<RG>..
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Tuesday, August 28, 2012 8:47 AM
> To: [e-mail]
> Cc: [e-mail]; Rakesh Gandhi (rgandhi)
> Subject: Re: [CCAMP] Review Request For Changes in 
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> Fei,
> 
> I don't think the text addresses the issue of selection of association object contents in the case of double sided provisioning.  How about:
> - in the case of double sided provisioning *only*
>   1. Association Source is set to an address selected by the node that
>      originates the association. (which may be a management entity.)
> 
>> <RG> For double sided provisioning, both sides can originate the LSPs 
>> independently. In this case, there needs to be a rule for a default 
>> behavior on which side becomes the association source and hence the 
>> proposal to pick the side with lower IP address for the source.

Why are you assuming that one of the endpoints must be the source?  The key requirement is that the source+ID(s) must be unique.  This means that ID(s) must be selected or obtained from the association source.

<RG2> I saw your reply to Fei. So ok, association-source is not necessarily a router source address.  


>> This rule can be overridden by the management entity to designate a 
>> side to become an association source.

This is where we disagree.  IMO the entity that selects the ID(s) is the source and must provide the IP address in which the ID is scoped.

<RG2> I see, so association source and ID must be given to a node.



> 
>   2. Association ID is a value assigned but the node that originates
>      the association.
>   3. Global Association Source, when used, is set to the Global_ID of
>      the node that originates the association.
>   4. Extended Association ID, when used, is selected by the node that
>      originates the association.
>   -  If either (3) or (4) are used, an Extended ASSOCIATION object
>      [assoc-ext] is used.  Otherwise a ASSOCIATION object [rfc4872]
>      is used
> 
>> <RG> As both sides can originate LSPs independently,  it would be 
>> useful to have a sentence in the draft to indicate how this is 
>> populated.

How what is populated, i.e., what is "this"?

<RG2> Extended association ID.

>> As a tie breaker rule by default higher IP address destination is 
>> used and it can be overridden by the management entity.

I'm sorry, I just don't see how the "higher/lower" IP address scheme provides uniqueness WRT the ID(s).  You previously said that the entity that provisions the LSP selects the ID.  In this case it should also provide the IP address to ensure the object is unique.

<RG2> I see now what you are saying. So identical values for <Association-ID + Source + Ext-ID> must be given to nodes on both sides of the LSPs. It is not tied to the LSP source/destination.

Thanks,
Rakesh


What am I missing?

Thanks,
Lou

> 
> 
> 
> - while we're at it, in the case of single sided provisioning *only* (note only #1 differs)
>   1. Association Source is set to an address assigned to the node that
>      originates the LSP.
>   2. Association ID is a value assigned but the node that originates
>      the association.
>   3. Global Association Source, when used, is set to the Global_ID of
>      the node that originates the association.
>   4. Extended Association ID, when used, is selected by the node that
>      originates the association.
>   -  If either (3) or (4) are used, an Extended ASSOCIATION object
>      [assoc-ext] is used.  Otherwise a ASSOCIATION object [rfc4872]
>      is used
> 
> I think the above addresses my point as it can be used to ensure unique LSP association in all cases.  BTW it also aligns very nicely with the existing definition of the association objects.
> 
> <RG> This sounds good.
> 
> Thanks,
> Rakesh
> 
> 
> To address what I suspect is your concern, 3.2.8 can then become something like (feel free to revise):
> 
>   3.2.8  MPLS-TP Associated Bidirectional LSP Identifiers
> 
>   [RFC6370] defines the LSP associated identifiers based on the
>   signaling parameters of each unidirectional LSP. The combination
>   of each unidirectional LSP's parameters is used to identify the
>   Associated Bidirectional LSP.  Using the mechanisms defined in
>   this document, any node that is along the path of both
>   unidirectional LSPs can identify which pair of unidirectional LSPs
>   support an Associated Bidirectional LSP as well as the signaling
>   parameters required by [RFC6370].  Note that the LSP end-points
>   will always be the path of both unidirectional LSPs.
> 
> Lou
> 
> On 8/27/2012 10:20 PM, [e-mail] wrote:
>>
>> Thank you lou
>>
>> How about changing the descriptions in paragraph 3.2.8
>>
>>    In some scenarios, a node that is the association source MAY need to
>>   learn about the Global_ID [RFC6370] of the peer node, which can be
>>   done by inserting the ASSOCIATION object with Association Type "LSP
>>   identifiers" in the outgoing Path message and being carried back in
>>   the Resv message, as defined in [I-D, draft-zhang-ccamp-mpls-tp-
>>   rsvpte-ext-tunnel-num].
>>
>> into
>>
>>    In some scenarios, a node that is the association source MAY need to
>>   learn about the Global_ID [RFC6370] of the peer node. Although the
>>    scope of the draft [I-D,
>> draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num]
>>    is limited to the co-routed bidirectional LSP, the defined 
>> procedures can
>>    be reused here also. The ASSOCIATION object with Association Type "LSP
>>   Identifiers" is inserted in the outgoing Path message at the association
>>    source and carried back in the corresponding Resv message. All the 
>> fields
>>    of the ASSOCIATION object except the Association Type in the Path 
>> message
>>    can be ignored by the receiver and the Global_ID of the peer node 
>> is pushed
>>    into the field of the Global Association Source in the Resv message.
>>
>> Best regards
>>
>> Fei
>>
>>
>> *Lou Berger <[e-mail]>*
>>
>> 2012-08-28 02:30
>>
>> 	
>> 收件人
>> 	[e-mail]
>> 抄送
>> 	"[e-mail]" <[e-mail]>, "Rakesh Gandhi (rgandhi)"
>> <[e-mail]>
>> 主题
>> 	Re: [CCAMP] Review Request For Changes in 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>>
>> 	
>>
>>
>>
>>
>>
>> Fei,
>>                 The problem only exists in the double sided 
>> provisioing case, so no need to complicate the single sided 
>> provisioning case.
>>
>> Lou
>>
>>
>> On 8/26/2012 9:03 PM, [e-mail] wrote:
>>> The administrative
>>> approach can integrate both models, will be a good idea.
>>
>>