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

[Lou Berger <[e-mail]>]

Fei,

On 8/28/2012 10:46 AM, [e-mail] wrote:
> 
> Lou
> 
> - 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.)
> 
> <fei> Do you mean the assocition source can be neither A1 nor Z9 here?
> 

Yes.  The only requirement is (global) uniqueness.

>   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.
> 
> <Fei> RFC6370 requires A1-global_ID and Z9-global_ID, how to push them
> into the Extended ASSOCIATION object without new Association type?
>  

Solving this issue, i.e., how to signal Global_ID of an LSP, is
currently not within the scope of this document.

Given it's such a small addition, I as a WG contributor, see no reason
not to broaden the scope of this draft (assuming the WG agrees) to
include such support. Although, I think the title and intro of the
document will need to be updated to reflect this change.  I'm also fine
with keeping out of scope, and solving it elsewhere.

Lou

> Hope your clarification
> 
> Thanks
> 
> Fei
> 
> 
> *Lou Berger <[e-mail]>*
> 
> 2012-08-28 20:46
> 
> 	
> 收件人
> 	[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,
> 
> 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.)
>  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
> 
> - 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.
> 
> 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.
>>
>>
> 
>