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

[John E Drake <[e-mail]>]

Hi,

It's my understanding that this draft started by describing how to instantiate associated bi-directional LSPs by creating an association in signaling between two uni-directional LSPs.  Then came the observation that these two uni-directional LSPs might have congruent paths.  From what I understand, the authors then decided it would be useful to have an option to force two uni-directional LSPs onto congruent paths.

This is when the disconnect occurred.

I think we should simply state that if a co-routed bi-directional LSP is required use RFC 3473, and we should remove the option of forcing two uni-directional LSPs onto congruent paths from the draft.

I also think that the bi-directional FRR material should be removed from the draft.

Thanks,

John 

Sent from my iPhone

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Lou Berger
> Sent: Thursday, August 16, 2012 3:17 PM
> To: Rakesh Gandhi (rgandhi)
> Cc: [e-mail]
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
> associated-lsp-04.txt
> 
> Rakesh,
> 	See below.
> 
> On 8/16/2012 5:59 PM, Rakesh Gandhi (rgandhi) wrote:
> > Hi Lou,
> >
> > Please see inline..<RG>..
> >
> > -----Original Message-----
> > From: Lou Berger [mailto:[e-mail]]
> > Sent: Thursday, August 16, 2012 5:42 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,
> >
> > 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?
> >
> > <RG> I understand what you are saying and do not see any issue there.
> > But I am not looking at it from that view point.
> 
> Actually, I'm not making any statement on if there's an issue or not.
> I'm asking you to state the issue or new function that you'd like
> addressed by a new mechanism.  It's really simple, if there's no issue
> or need for a new function, then there's no need to defined a new
> mechanism.
> 
> I'm guessing that you see an issue or limitation, and I'd genuinely
> like to understand what it is.
> 
> > All we are saying is
> > that when bidirectional LSPs are associated via signaling, they could
> > take the same path and it can be provisioned to do so.
> 
> Well, this is already stated in RFC5654 (and referenced RFC6373).  If
> that's it, we can easily close this topic.
> 
> Lou
> 
> >
> > Thanks,
> > Rakesh
> >
> > 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-
> ex
> >>>> t
> >>>> -
> >>>> a
> >>>> ssociated-lsp
> >>>>
> >>>> There's also a htmlized version available at:
> >>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-
> asso
> >>>> c
> >>>> i
> >>>> 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-
> ex
> >>>> t
> >>>> -
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp