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

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

Rakesh,

1)  In the context of MPLS-TP, the control plane is GMPLS not MPLS.

2)  The distinction between an MPLS control plane and a GMPLS control plane is largely moot;  i.e., it's just RSVP signaling with some different objects and both can co-exist without any issues in a sensible implementation.

3)  Whether you add the objects defined in RFC 3473 or you add the objects in this proposal, you are adding new objects and their associated procedures.

4)  This proposal was considered twelve years ago and rejected in favor of the approach in RFC 3473.

5)  In the context of MPLS-TP, we have spent the past three years arguing that doing the same function in different ways is a Bad Idea(tm).  Why would we want to suddenly embrace two methods of establishing co-routed bidirectional packet LSPs, especially when the new proposal is known to be sub-optimal relative to the existing method?

Thanks,

John

Sent from my iPhone

> -----Original Message-----
> From: Rakesh Gandhi (rgandhi) [mailto:[e-mail]]
> Sent: Friday, August 17, 2012 10:29 AM
> To: Lou Berger; Francesco Fondelli
> Cc: John E Drake; [e-mail]
> Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
> associated-lsp-04.txt
> 
> Thanks Francesco and Lou.
> 
> Just like c1 in the initial proposal of the draft for the associated
> bidirectional LSP, c2 allows the MPLS-TE packet control plane currently
> deployed in the network (non GMPLS) to be used to provide co-routed
> (associated bidirectional) LSP functionality without having to migrate
> to GMPLS protocol in RFC 3473.
> 
> I do agree with you Lou on some of the complexity that may come with it
> (MBB, rerouting, recovery, etc.).
> 
> Thanks,
> Rakesh
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Friday, August 17, 2012 10:38 AM
> To: Francesco Fondelli
> Cc: Rakesh Gandhi (rgandhi); John E Drake; [e-mail]
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
> associated-lsp-04.txt
> 
> Francesco,
> 
> 	Nice summary.  I think your last observation, about b and c2
> being the same in the data plane, is the key one.  Up to now, I don't
> know of anyone or any draft that has suggested anything but using b for
> the control plane representation of co-routed TP paths.  The JWT even
> called out using b.
> 
> We had a lot of discussion (okay, arguments) about this in the early
> days of GMPLS where we debated just using the then practice of using
> EROs to provide a bidirectional co-routed data path using 2
> unidirectional control plane LSPs.  Obviously the position of using (b)
> won out.  Largely because the b approach greatly simplified the control
> plane for complex behaviors such as MBB, rerouting, recovery, etc.
> 
> It does seem that the draft/proposal is in fact for c2, as confirmed by
> Fei's mail.  I was hoping that we could get someone to describe the
> issue they are trying to address (perhaps as an intended usage
> scenario) as well as why the added control plane complexity is a good
> idea.
> Particularly as all the corner cases need to be addressed.
> 
> Lou
> 
> On 8/17/2012 4:48 AM, Francesco Fondelli wrote:
> > Hi All,
> >
> > I think I'm lost, please help.
> >
> > Rakesh is talking about "co-routed associated bidirectional LSP"...
> > for the sake of clarity, let me try to categorize LSPs from a control
> > plane view point:
> >
> >   a) Point-to-point unidirectional
> >   b) Point-to-point co-routed bidirectional
> >   c) Point-to-point associated bidirectional
> >    c1) fwd and rev LSP follow different paths
> >    c2) fwd and rev LSP follow same path
> >   d) Point-to-multipoint unidirectional
> >   e) Multipoint-to-point unidirectional
> >
> > Is section 3.2.5 (Signaling of Co-routed LSPs) of
> > mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?
> >
> > In my opinion:
> >
> > - b) should be signaled with 3473
> > - c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp)
> >
> > Am I missing something?
> >
> > thank you
> > ciao
> > fra
> >
> > PS
> > from a data-plane view point b) and c2) are the same thing.
> >
> > On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi)
> > <[e-mail]> wrote:
> >> Hi Lou,
> >>
> >> Thanks for initiating discussions on the changes in the draft.
> >>
> >> Agree with you here, if we/WG do not agree on the "co-routed
> associated bidirectional LSP" part, we are ok to remove it from this
> draft and can always submit a new draft just for that. We respect
> your/WG decision.
> >>
> >> Thanks,
> >> Rakesh
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Lou Berger [mailto:[e-mail]]
> >> Sent: Thursday, August 16, 2012 6:08 PM
> >> To: John E Drake
> >> Cc: Rakesh Gandhi (rgandhi); [e-mail]
> >> Subject: Re: [CCAMP] I-D Action:
> >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> >>
> >> John,
> >>         While strictly speaking WG drafts should only reflect
> current WG consensus, and it is the WG draft editor's job to ensure
> this, in practice authors/editors are given a lot of latitude in timing
> / ordering in introduction to changes.  I personally think this is a
> practical way of keeping the process moving.  Also if the WG disagrees
> with a change, it can always be backed out.
> >>
> >> So, yes, the WG could do exactly as you say if it comes to it.  (The
> >> chairs can even appoint different editor if needed, e.g., to make
> >> this
> >> happen.)  While I'm not happy with how this revision came about, as
> I covered in earlier mail, my feeling is to let the discussion take
> place on the list (and at the next IETF, if needed) and then have the
> draft updated to reflect the WG discussion/consensus.
> >>
> >> Lou
> >>
> >> On 8/16/2012 5:35 PM, John E Drake wrote:
> >>> Lou,
> >>>
> >>> Since the WG did not agree to this changes, let alone discuss them,
> >>> would it be possible to simply rollback these changes and ask the
> >>> authors to write a draft addressing the topics you list in your
> >>> email, below?
> >>>
> >>> Thanks,
> >>>
> >>> John
> >>>
> >>> Sent from my iPhone
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: [e-mail] [mailto:[e-mail]] On
> >>>> Behalf Of Lou Berger
> >>>> Sent: Thursday, August 16, 2012 2:10 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,
> >>>>      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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> CCAMP mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> CCAMP mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ccamp
> >
> >
> >
> >