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

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

Greg,

I think the text I quoted from RFC 5654 is remarkably clear.  Eric is certainly entitled to his opinion but it doesn't seem to be aligned with RFC 5654.

Yours Irrespectively,

John

> -----Original Message-----
> From: Gregory Mirsky [mailto:[e-mail]]
> Sent: Monday, October 14, 2013 10:02 AM
> To: John E Drake; Alexander Vainshtein
> Cc: [e-mail]; Bhatia, Manav (Manav); [e-mail]; draft-ietf-mpls-
> [e-mail]; [e-mail]
> Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> 
> Hi John,
> I was thinking that two unidirectional LSPs that happen to be co-routed can
> form an associated bi-directional LSP. I believe that Eric Gray explained that
> that was not interpretation and intention of RFC 5960 to see co-routed bi-
> directional p2p LSP not as single unified object but as two federated objects. I
> recall that intention was to have case of accidental co-routedness in
> associated p2p LSP. In other words, associated bi-directional was not meant to
> happen to be co-routed. Well, that is my recollection of talking with Eric and
> hope it's accurate one.
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: John E Drake [mailto:[e-mail]]
> Sent: Monday, October 14, 2013 7:55 AM
> To: Alexander Vainshtein; Gregory Mirsky
> Cc: [e-mail]; Bhatia, Manav (Manav); [e-mail]; draft-ietf-mpls-
> [e-mail]; [e-mail]
> Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> 
> 
> 
> Yours Irrespectively,
> 
> John
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Alexander Vainshtein
> > Sent: Monday, October 14, 2013 1:08 AM
> > To: Gregory Mirsky
> > 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
> >
> > Greg,
> > Lots of thanks for an important comment.
> >
> > Regarding your example: my personal interpretation of 5654 is like following:
> > - Co-routed bidirectional LSPs MAY be protected using bi-directional
> > protection schemes but MUST NOT be protected using unidirectional ones
> 
> [JD]  I don't think that is true for a pair of co-routed associated unidirectional
> LSPs.
> 
> > - Associated bidirectional LSPs MAY be protected using both
> > unidirectional and bi-directional protection schemes
> 
> [JD]  Conversely, if a pair of associated unidirectional LSPs are diversely routed,
> it
> may be difficult to apply bidirectional protection to them.
> 
> >
> > Does this match your understanding?
> >
> > Regards,
> >      Sasha
> >
> > > -----Original Message-----
> > > From: Gregory Mirsky [mailto:[e-mail]]
> > > Sent: Monday, October 14, 2013 9:23 AM
> > > To: Bhatia, Manav (Manav); Alexander Vainshtein
> > > 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
> > >
> > > Hi Manav,
> > > I do feel that "fate sharing" already has certain interpretation in
> > > the
> > industry.
> > > Difference in, for example, protection between co-routed and
> > > associated bi- directional LSPs doesn't seem not to be described by
> > > "fate sharing". I think of it as in co-routed case LSP protected as
> > > a single entity while in associated case each direction of LSP is
> > > protected
> > independently of the other.
> > >
> > > 	Regards,
> > > 		Greg
> > >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On Behalf
> > > Of Bhatia, Manav (Manav)
> > > Sent: Sunday, October 13, 2013 10:26 PM
> > > To: Alexander Vainshtein
> > > Cc: [e-mail]; [e-mail];
> > > draft-ietf-mpls-tp-rosetta- [e-mail]; [e-mail]
> > > Subject: Re: [mpls] RtgDir review:
> > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > >
> > > Sasha,
> > >
> > > I think the confusion is over what we mean by "fate sharing".
> > >
> > > To me, if the forward path is torn down for some reason, and that
> > > results in the backward path being torn down as well, then they
> > > inextricably
> > "share the fate".
> > >
> > > If the path of the forward LSP changes because of an IGP trigger,
> > > then the backward LSP changes too in case of co-routed bidirectional LSPs.
> > > However, this isn't true in case of Associated bidirectional LSPs.
> > > Similarly, an IGP change (or a network event -- link/node flap,
> > > link/node down) will always result in both directions changing their
> > > path in case of co-routed bidirectional LSPs. This doesn't happen in
> > > case of Associated bidirectional LSPs. Its this difference that I
> > > wanted the
> > authors to highlight as part of my review comment.
> > >
> > > If you think "fate sharing" is not the most appropriate term then
> > > you can suggest something else as long as you believe its something
> > > that ought to be mentioned.
> > >
> > > Cheers, Manav
> > >
> > > > -----Original Message-----
> > > > From: Alexander Vainshtein
> > > > [mailto:[e-mail]]
> > > > Sent: Monday, October 14, 2013 9:37 AM
> > > > To: Bhatia, Manav (Manav)
> > > > Cc: [e-mail];
> > > > [e-mail];
> > > > [e-mail]; [e-mail]
> > > > Subject: RE: RtgDir review:
> > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > >
> > > >
> > > > Manav,
> > > > Lots of thanks for a prompt response.
> > > >
> > > > I must admit that I've mssed the text in 5960 to which you refer.
> > > >
> > > > The original definition, to the best of my understanding, is in
> > > > Section 1.2.2. of RFC 5654 and says something else:
> > > >
> > > >
> > > >    Co-routed Bidirectional path: A path where the forward and backward
> > > >    directions follow the same route (links and nodes) across the
> > > >    network.  Both directions are setup, monitored and protected as a
> > > >    single entity.  A transport network path is typically co-routed.
> > > >
> > > > To me this means that if one of the directions of the co-routed
> > > > bi-directional path fails to convey traffic, the monitoring
> > > > mechanisms will report the entire bi-directional path as failed.
> > > >
> > > > To the best of my recollection when I=D to become RFC 5960 has
> > > > been discussed I've asked the authors of RFC 5960 whether the
> > > > pairing between two directions of a co-routed bi-directional
> > > > MPLS-TP LSP in a transit LSR is limited to OAM processing, and
> > > > they (or one of
> > > > them) have confirmed that this is indeed so.
> > > >
> > > > I wonder whether this can be interpreted as "fate-sharing".
> > > >
> > > > Regards,
> > > >      Sasha
> > > >
> > > > ________________________________________
> > > > From: Bhatia, Manav (Manav) [[e-mail]]
> > > > Sent: Monday, October 14, 2013 4:21 AM
> > > > To: Alexander Vainshtein
> > > > Cc: [e-mail];
> > > > [e-mail];
> > > > [e-mail]; [e-mail]
> > > > Subject: RE: RtgDir review:
> > > > draft-ietf-mpls-tp-rosetta-stone-12.txt
> > > >
> > > > Hi Sasha,
> > > >
> > > > RFC 5960 that describes the MPLS-TP data plane says the following:
> > > >
> > > > A point-to-point co-routed bidirectional LSP is a point-to-point
> > > > associated bidirectional LSP with the additional constraint that
> > > > its two unidirectional component LSPs in each direction follow the
> > > > same path (in terms of both nodes and links).  An important
> > > > property of co-routed bidirectional LSPs is that their
> > > > unidirectional component LSPs share fate.
> > > >
> > > > Am I missing something?
> > > >
> > > > Cheers, Manav
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Alexander Vainshtein
> > > > > [mailto:[e-mail]]
> > > > > Sent: Sunday, October 13, 2013 9:46 PM
> > > > > To: Bhatia, Manav (Manav)
> > > > > Cc: [e-mail];
> > > > > [e-mail];
> > > > > [e-mail]; [e-mail]
> > > > > Subject: RE: 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.
> > > >
> > > >
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls
> >
> >
> > 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.
> >
> >
> 
> 
>