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

[Greg Mirsky <[e-mail]>]

Hi Francesco,
"from a data-plane view point b) and c2) are the same thing"
I think that given that c) is associated bi-directional LSP that implies
independent OAM and protection for each direction, b) and c2) are not the
same in the data plane view. E.g., there will be single CC/CV/RDI session
for b) while c2) will have two sessions. And if linear protection
requested, b) will be protected by single bi-directional LSP, but c2) - by
two unidirectional LSPs.

Regards,
Greg

On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli <
[e-mail]> 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
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>