Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

[Lou Berger <[e-mail]>]

Rakesh,

On 8/16/2012 5:26 PM, Rakesh Gandhi (rgandhi) wrote:
> Hi Lou,
> 
> Thank you for your comments.
> 
> We had several email exchanges on the alias on "signaling of
> co-routed LSPs" before it was added in the draft.

I presume you're referring to your private e-mail exchange that was
forwarded to the list, mid-stream, under the subject "Re: [CCAMP]
Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03".

I addressed this in
http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html.  If
you disagree with that e-mail, please respond to it.

> 
> Regarding A)
> 
> I agree with you that GMPLS signaling can be used for co-routed LSPs
> and has many advantages.
> 
> Goal of the associated bidirectional LSPs is to tie the two
> independent LSPs together. These two LSPs may be non co-routed or
> co-routed. It is useful for an application to specify the node to
> request both LSPs go on the same path. Do you agree?

Not sure I understand your question.  Per RFC5654 and RFC6373 there is a
stated need for associated and co-routed MPLS TP transport paths.  As
discussed in RFC6373, RFC3473 already supports co-routed bidirectional
LSPs.  The draft we're discussing covers associated bidirectional.

Can you rephrase the issue/function that you believe is not addressed in
current signaling RFCs?

Lou

> 
> Thanks,
> Rakesh
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Thursday, August 16, 2012 5:10 PM
> To: Rakesh Gandhi (rgandhi)
> Cc: [e-mail]; [e-mail]
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> Rakesh,
> 	Such major changes (in scope and functionality) to WG drafts are usually discussed with the WG prior to the authors/editors just publishing the changes.  But, this is a judgment call by the document editors in how, quoting rfc2418, they "ensur[e] that the contents of the document accurately reflect the decisions that have been made by the working group."
> 
> So let's jump into discussing the changes.
> 
> As I see it this draft introduces several major functional changes that have not been discussed by the WG.  Correct me if I get them wrong, but I believe they include:
> 1) Introduction of a second method for signaling Co-routed LSPs
> 2) Support for FRR bypass tunnels for piggybacked on the TP bidirectional LSP mechanisms.
> 
>    There are also other changes, but I'll defer discussing them
>    until the discussion on the above is concluded.
> 
> Is this correct?
> 
> Assuming yes, I have questions about both rational and specific mechanisms.  For now let's look at the former, so please:
> 
> A) Articulate the issues/limitations with using the RFC3473 defined mechanisms for (co-routed) bidirectional LSPs that you'd like to see addressed.
> 
> B.1) Articulate the FRR/GMPLS-related issue you'd like to address?
> 
> B.2) Articulate why this issue should be solved in a TP-specific and not GMPLS generic fashion?
> 
> Thanks,
> Lou
> 
> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote:
>> Hi Lou,
>>
>> Yes.
>>
>> Please advise if you think detailed email is required. 
>> We believe latest draft summarizes the changes well and we could start review/discussions from there.
>>
>> Thanks,
>> Rakesh
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Thursday, August 16, 2012 4:00 PM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [CCAMP] I-D Action: 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>> Rakesh,
>> 	Is this the start of the thread that I requested in 
>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html
>>
>> In particular, is it the response to:
>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the 
>>> proposed change and the rational for each change (in one or in 
>>> separate e-mails). The WG discussion can then really begin on the 
>>> proposed changes. (Which are quite substantial both in scope and
>>> implication.)
>>
>> Lou
>>
>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi All,
>>>
>>> We have uploaded a new version of this draft with following changes:
>>  
>> 1.  Added a section on Signaling of Co-routed LSPs
>>
>> 2.  Added clarification on Signaling of Associated Bidirectional 
>> Protection LSPs
>>
>> 3.  Added a section on Signaling of Auto-tunnel Mesh-group LSPs
>>
>> 4.   Added clarification on Signaling of Inter-domain Associated  Bidirectional LSPs 
>>
>> 5.  The Extended ASSOCIATION object format with Association Type "Associated Bidirectional LSP". Clarified on how to populate different fields in this object.
>>
>>  
>>> We believe that some of these changes were necessary to avoid the interoperability issues due to potentially different interpretations.
>>>
>>> Your review comments are welcome.
>>>
>>> Thanks,
>>> Rakesh
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On 
>>> Behalf Of [e-mail]
>>> Sent: Wednesday, August 15, 2012 10:53 AM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: [CCAMP] I-D Action: 
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>  This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
>>>
>>> 	Title           : RSVP-TE Extensions for Associated Bidirectional LSPs
>>> 	Author(s)       : Fei Zhang
>>>                           Ruiquan Jing
>>>                           Rakesh Gandhi
>>> 	Filename        : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>> 	Pages           : 17
>>> 	Date            : 2012-08-15
>>>
>>> Abstract:
>>>    The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654],
>>>    describes that MPLS-TP MUST support associated bidirectional point-
>>>    to-point LSPs.
>>>
>>>    This document provides a method to bind two unidirectional Label
>>>    Switched Paths (LSPs) into an associated bidirectional LSP.  The
>>>    association is achieved by defining the new Association Type in the
>>>    Extended ASSOCIATION object.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> a
>>> ssociated-lsp
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ
>>> a
>>> ted-lsp-04
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> a
>>> ssociated-lsp-04
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
>>
>>
>>
>>
> 
> 
> 
>