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,

Thank you for your reply.

I agree with you to revise the draft capturing the agreed changes so far. 

Your proposal for the following text looks good. 

3.2.6. Associated Bidirectional LSPs and LSP Recovery

LSP recovery as defined in [RFC4872], [RFC4873] and [RFC4090] is not impacted by this document.  The recovery mechanisms defined in [RFC4872] and [RFC4873] rely on the use of ASSOCIATION Objects, but use a different Association Type field value than defined in this document so should not be impacted.  The mechanisms defined in [RFC4090] does not rely on the use of ASSOCIATION Objects and is therefore also not impacted by the mechanisms defined in this document.

3.2.7. Associated Bidirectional LSPs and TE Mesh-Groups

TE mesh-groups is defined in [RFC4972]. A node supporting both Associated Bidirectional LSPs and TE mesh-groups, MAY include an ASSOCIATION object as defined in this document in Path messages of LSPs used to support the mesh-group.  To enable unambiguous identification of the mesh-group's associated bidirectional LSPs, the information carried in the ASSOCIATION object, including the contents of the Association Source and Identifier fields MUST be provisioned.


Thanks,
Rakesh



-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Wednesday, September 12, 2012 12:11 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,
	Looks like you switched threads in your last message.  (BTW I think I'm getting lost in the number of changes being discussed and think having a new version capturing changes to date would help...)

Let me try to merge them:

>On 8/27/2012 5:16 PM, Rakesh Gandhi (rgandhi) wrote:
>>
>> Let me propose revised texts for section 3.2.6 [item 7], 3.2.7 [item
8] and 4.1 [items 1,2,3,6].	
>>
>> Regards,
>> Rakesh
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Sunday, August 26, 2012 10:31 AM
>> 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 (using normal reply notation)...
>>
>> On 8/24/2012 5:18 PM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi Lou,
>>>
>>> Please see inline..<RG2>..
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:[e-mail]]
>>> Sent: Friday, August 24, 2012 4:41 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/24/2012 2:31 PM, Rakesh Gandhi (rgandhi) wrote:
>>>> Hi Lou,
>>>>
>>>> Thanks for your review. Please see inline..<RG>..
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:[e-mail]]
>>>> Sent: Friday, August 24, 2012 1:55 PM
>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: [e-mail]
>>>> Subject: Re: [CCAMP] Review Request For Changes in 
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>>> Rakesh,
>>>>
>>>> Speaking as a WG participant, and ignoring changes 4 and 5 as you
plan to revert these:
>>>>
>>>> On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote:
>[...]
>
>>>>> 7. Path Protection object:
>>>>> Version 03 of the draft vaguely mentioned and assumed of using 
>>>>> protection object for path protection. New version 04 adds some 
>>>>> texts to clarify it, no new rule is added.
>>>>>
>>>>
>>>> I think providing informative text on interactions of this document 
>>>> with the various defined recovery (4872 and 4872) and reroute 
>>>> (4090) mechanisms is a really good idea. That said, I found this 
>>>> section a bit opaque. Ignoring the wordsmithing, what specific 
>>>> points are you trying to make?
>>>> 
>>>>
>>>> <RG> It just highlights that for a bi-directional tunnel, there can 
>>>> be a working bidirectional LSPs and protecting bidirectional LSPs. 
>>>> That's all.
>>>>
>>>
>>> I think the proposed text is really confusing and doesn't cover the 
>>> full scope (in particular 4872 is about recovery which is both 
>>> protection and restoration, it doesn't cover 4873 or 4090). Can you 
>>> propose (one the
>>> list) some alternate text?
>>>
>>> <RG2> Idea here is that there are multiple bidirectional LSPs for a 
>>> tunnel for different LSP roles. We could remove the LSP type as 
>>> primary and secondary reference from the text, and just state LSPs 
>>> for different roles.
>>>
>>
>> Again, I think the issue is with the proposed language.


On 9/4/2012 12:26 PM, Rakesh Gandhi (rgandhi) wrote:
> Thanks Lou.
> Potential text for the remained two sections in the draft can be as  
> follows. Please feel free to revise.
>
> 3.2.6 Signaling of Associated Bidirectional LSP For Different LSP 
> Roles There can also be a pair of recovery and/or reroute LSPs as per 
> procedures define in [RFC4872], [RFC4873] and [RFC4090]. Together with 
> those procedures, a node uses Extended ASSOCIATION object or 
> ASSOCIATION object defined in this document to form an associated 
> bidirectional LSP pair for each LSP role.

I still don't understand this text.  Perhaps you mean something like:

3.2.6. Associated Bidirectional LSPs and LSP Recovery

LSP recovery as defined in [RFC4872], [RFC4873] and [RFC4090] is not impacted by this document.  The recovery mechanisms defined in [RFC4872] and [RFC4873] rely on the use of ASSOCIATION Objects, but use a different Association Type field value than defined in this document so should not be impacted.  The mechanisms defined in [RFC4090] does not rely on the use of ASSOCIATION Objects and is therefore also not impacted by the mechanisms defined in this document.


>>
>>
>>>>
>>>>> 8. Auto-tunnel mesh:
>>>>> New version 04 adds a section to elaborate on a use case for 
>>>>> auto-tunnel mesh. This is added as an FYI and can be removed if WG 
>>>>> thinks so.
>>>>>
>>>>
>>>> How is the association id field value selected in this case?
>>>>
>>>> <RG> Proposal allows that single association-id can be provisioned 
>>>> for a mesh-group.
>>> I don't think you have text that supports this.  The closest you 
>>> come is:
>>>    A node provisioned to
>>>    build a mesh of associated bidirectional LSPs may use identical
>>>    association ID for the given mesh-group member peers.
>>>
>>> which doesn't say that the "identical association ID" MUST be 
>>> provisioned.
>>>
>>> <RG2> Yes, we can clarify this.


On 9/4/2012 12:26 PM, Rakesh Gandhi (rgandhi) wrote:
>
> 3.2.7. Signaling of Auto-tunnel Mesh-group LSPs A node may build LSPs 
> automatically to remote peers in a mesh using the mesh-group 
> membership defined in [RFC4972]. A node MUST be provisioned with 
> identical association ID for the given mesh-group members peers to 
> build a mesh of associated bidirectional LSPs. The extended 
> association ID can be used to form unique Extended ASSOCIAITON object 
> in each LSP to different remote peers.

How about something along the lines of:

3.2.7. Associated Bidirectional LSPs and TE Mesh-Groups

TE mesh-groups is defined in [RFC4972]. A node supporting both Associated Bidirectional LSPs and TE mesh-groups, MAY include an ASSOCIATION object as defined in this document in Path messages of LSPs used to support the mesh-group.  To enable unambiguous identification of the mesh-group's associated bidirectional LSPs, the information carried in the ASSOCIATION object, including the contents of the Association Source and Identifier fields MUST be provisioned.

Lou (as WG participant)

>>>
>>
>> Great!
>>
>> Lou
>>
>>> Thanks,
>>> Rakesh
>>>
>>> Lou
>