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

[[e-mail]]

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.