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

[Lou Berger <[e-mail]>]

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
>