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

[[e-mail]]

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?

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