Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt

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

Greg,

I don't recall mentioning OAM. 

Yours Irrespectively,

John

> -----Original Message-----
> From: Gregory Mirsky [mailto:[e-mail]]
> Sent: Monday, October 14, 2013 9:01 AM
> To: Alexander Vainshtein; John E Drake
> Cc: [e-mail]; [e-mail]; Bhatia, Manav (Manav); draft-
> [e-mail]; [e-mail]
> Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> 
> Hi Sasha, John, et. al,
> isn't there bit of contradiction when first stating that co-routed bidirectional
> and associated bidirectional LSPs are indistinguishable in data plane to note
> that there are difference in their OAM? OAM, in large part, is in data plane and
> how co-routed and associated bidirectional LSP being references in OAM is
> different in the data plane, not only in control and/or management planes.
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Alexander Vainshtein
> Sent: Monday, October 14, 2013 8:27 AM
> To: John E Drake
> Cc: [e-mail]; [e-mail]; Bhatia, Manav (Manav); draft-
> [e-mail]; [e-mail]
> Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> 
> John,
> Lots of thanks for a prompt response.
> 
> I fully agree with you that there is no difference in the data plane between two
> directions a co-routed bi-directional LSP and two directions of an associated bi-
> directional LSP. The difference is mainly in management/control plane, in the
> OAM etc.
> 
> This is exactly why I find the term "fate-sharing" inappropriate when it is
> applied to forward and backward directions of a co-routed bi-directional LSP
> because to me fate-staring refers to first of all to the data plane behavior.
> 
> Regards,
>      Sasha
> 
> 
> > -----Original Message-----
> > From: John E Drake [mailto:[e-mail]]
> > Sent: Monday, October 14, 2013 6:10 PM
> > To: Alexander Vainshtein
> > Cc: [e-mail]; Bhatia, Manav (Manav); [e-mail];
> > draft-ietf-mpls-tp- [e-mail];
> > [e-mail]
> > Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> >
> > Sasha,
> >
> > My point was simply that in the data plane there isn't any difference
> > between the two.
> >
> > Yours Irrespectively,
> >
> > John
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf
> > Of
> > > Alexander Vainshtein
> > > Sent: Monday, October 14, 2013 7:34 AM
> > > To: John E Drake
> > > Cc: [e-mail]; Bhatia, Manav (Manav); [e-mail];
> > > draft-ietf-mpls- [e-mail];
> > > [e-mail]
> > > Subject: Re: [RTG-DIR] RtgDir review:
> > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > >
> > > John,
> > > Not sure I fully understood your message.
> > >
> > > My comments have been about applicability of the term "fate-sharing"
> > > to the two directions of a co-routed bi-directional LSP.
> > > It is of course true that each direction of an associated
> > > bi-directional LSP can fail independently of the other one, but,
> > > presumably, nobody has expected anything else in this case.
> > >
> > > Regards,
> > >      Sasha
> > >
> > >
> > > > -----Original Message-----
> > > > From: John E Drake [mailto:[e-mail]]
> > > > Sent: Monday, October 14, 2013 4:42 PM
> > > > To: Alexander Vainshtein; Bhatia, Manav (Manav)
> > > > Cc: [e-mail]; [e-mail];
> > > > draft-ietf-mpls-tp-rosetta- [e-mail];
> > > > [e-mail]
> > > > Subject: RE: RtgDir review:
> > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > >
> > > > Sasha,
> > > >
> > > > I think your comments apply equally to bidirectional LSPs.
> > > >
> > > > Yours Irrespectively,
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:[e-mail]]
> > > > > On Behalf
> > > > Of
> > > > > Alexander Vainshtein
> > > > > Sent: Sunday, October 13, 2013 9:16 AM
> > > > > To: Bhatia, Manav (Manav)
> > > > > Cc: [e-mail]; [e-mail];
> > > > > draft-ietf-mpls-tp-rosetta- [e-mail];
> > > > > [e-mail]
> > > > > Subject: Re: [RTG-DIR] RtgDir review:
> > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > > >
> > > > > Manav and all,
> > > > > Regarding one of the nits you've identified:
> > > > > "it would be useful to mention that an important property of
> > > > > co-routed bidirectional path is that the forward and backward
> > > > > directions
> > > share fate."
> > > > >
> > > > > IMHO and FWIW this is not correct. To the best of my
> > > > > understanding the two directions of an MPLS-TP co-routed
> > > > > bi-directional path share lifespan (i.e.,they are set up and
> > > > > torn down in a single management or
> > > control plane operation).
> > > > > But they do not share fate, as can be seen from the following examples:
> > > > >
> > > > > 1. A unidirectiona fiber cut in one of the links used by a
> > > > > co-routed
> > > > > bi-
> > > > directional
> > > > > trail will result in traffic failur in the affected direction
> > > > > but not necessarily in
> > > > the
> > > > > reverse one
> > > > >
> > > > > 2. Consider the case when one of entries the ILM in one of the
> > > > > transit LSRs is corruped. This will result in incorrect failure
> > > > > of a single label, but the rest of
> > > > the
> > > > > labels would be handled correctly. Since co-routed
> > > > > bi-directional trails do not require using the same label in
> > > > > both directions of a trail, the fate sharing
> > > > would
> > > > > be broken.
> > > > > (Actually, in such a way it could be easily broken even if the
> > > > > same label is
> > > > used
> > > > > on each segment of the LSP in both directions...)
> > > > >
> > > > > My 2c,
> > > > >      Sasha
> > > > >
> > > > >
> > > > >
> > > > > ________________________________________
> > > > > From: [e-mail] [[e-mail]] on
> > > > > behalf of Bhatia, Manav (Manav)
> > > > > [[e-mail]]
> > > > > Sent: Sunday, October 13, 2013 5:55 PM
> > > > > To: [e-mail]
> > > > > Cc: [e-mail];
> > > > > [e-mail];
> > > > > [e-mail]
> > > > > Subject: [RTG-DIR] RtgDir review:
> > > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > > >
> > > > > Hello,
> > > > >
> > > > > I have been selected as the Routing Directorate reviewer for
> > > > > this draft. The Routing Directorate seeks to review all routing
> > > > > or routing-related drafts as they pass through IETF last call
> > > > > and IESG review, and sometimes on special request. The purpose
> > > > > of the review is to provide assistance to the Routing ADs. For
> > > > > more information about the Routing Directorate, please
> > > > > seehttp://www.ietf.org/iesg/directorate/routing.html
> > > > >
> > > > > Although these comments are primarily for the use of the Routing
> > > > > ADs, it would be helpful if you could consider them along with
> > > > > any other IETF Last
> > > > Call
> > > > > comments that you receive, and strive to resolve them through
> > > > > discussion or by updating the draft.
> > > > >
> > > > > Document: draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > > > Reviewer: Manav Bhatia
> > > > > Review Date: October 13th, 2013
> > > > > IETF LC End Date: October 16, 2013 Intended Status:
> > > > > Informational
> > > > >
> > > > > Summary:  This document is basically ready for publication, but
> > > > > has nits that should be considered prior to publication.
> > > > >
> > > > > Comments: This document is built on top of terms already defined
> > > > > in different RFCs and ITU-T documents. The terms and definitions
> > > > > have already been reviewed so there is a trifle little that
> > > > > needs to be done there. Overall, the document looks good and
> > > > > ready for publication. Some of my comments can be
> > > > >
> > > > > Nits:
> > > > >
> > > > > o) Please expand PW in either the Abstract or Sec 3.5
> > > > >
> > > > > o) When explaining Control Plane (3.6) should we mention that it
> > > > > is possible
> > > > to
> > > > > operate an MPLS-TP network without using a Control Plane?
> > > > >
> > > > > o) In 3.7, it would be useful to mention that an important
> > > > > property of co-
> > > > routed
> > > > > bidirectional path is that the forward and backward directions share
> fate.
> > > > > Similarly, in 3.1, we should mention that the forward and
> > > > > backward directions don't share fate.
> > > > >
> > > > > o) 3.12 in the current text doesn't look very helpful. Can it be
> > > > > rephrased it to something like, "The equipment management
> > > > > function
> > > > > (EMF) provides the means through which an element management
> > > > > system
> > > > > (EMS) and other managing entities manage the network element
> > > > > function
> > > (NEF)."
> > > > >
> > > > > o) 3.13 talks about Fault cause without explaining what a fault
> > > > > cause is. It
> > > > took
> > > > > me some time to understand what was meant by "fault cause". Can
> > > > > the authors of the draft rephrase 3.13 in their own language to
> > > > > explain what they mean by a Failure. The current definition in
> > > > > the draft has been picked up as-is from ITU-T G.806
> > > > >
> > > > > o) 3.14 talks about "inability of a function to perform a
> > > > > required action". Since this RFC-to-be is in the IETF domain,
> > > > > can this be rephrased to use a term like router/switch instead
> > > > > of a more esoteric "function". This is a general
> > > > comment
> > > > > and applies to most of the definitions that have been copied
> > > > > from the ITU-T documents.
> > > > >
> > > > > o) The last paragraph of 3.17 says the following:
> > > > >
> > > > > "OAM packets are subject to the same forwarding treatment as the
> > > > > data traffic, but they are distinct from the data traffic."
> > > > >
> > > > > In what sense are the OAM packets distinct from the data traffic?
> > > > >
> > > > > o) Please include "T-PE" and "S-PE" in Sec 1.2. These have not
> > > > > been expanded in the document.
> > > > >
> > > > > o) Sec 3.19 uses TCM without expanding it first.
> > > > >
> > > > > o) In Sec 3.23, s/Tandem Connections/Tandem Connection
> > > > >
> > > > > o) In 3.28.3, can the following text be added:
> > > > >
> > > > > An LSP segment comprises one or more continuous hops on the path
> > > > > of the LSP.  [RFC5654] defines two terms.  A "segment" is a
> > > > > single hop along the
> > > > path
> > > > > of an LSP, while a "concatenated segment" is more than one hop
> > > > > along the path of an LSP.
> > > > >
> > > > > o) In 3.31, Isn't Operations Support Systems (OSS) a more common
> > > > > term than Operations Systems (OS)?
> > > > >
> > > > > Cheers, Manav
> > > > >
> > > > > This e-mail message is intended for the recipient only and
> > > > > contains
> > > > information
> > > > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom.
> > > > > If you have received this transmission in error, please inform
> > > > > us by e-mail, phone or fax, and then delete the original and all copies
> thereof.
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > This e-mail message is intended for the recipient only and contains
> > information
> > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom.
> > > If you have received this transmission in error, please inform us by
> > > e-mail, phone or fax, and then delete the original and all copies thereof.
> > >
> > >
> >
> 
> 
> 
> This e-mail message is intended for the recipient only and contains information
> which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
> have received this transmission in error, please inform us by e-mail, phone or
> fax, and then delete the original and all copies thereof.
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>