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..<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. This rule can be overridden by the management entity to designate a side to become an association source.


  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. As a tie breaker rule by default higher IP address destination is used and it can be overridden by the management entity.



- 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.
> 
>