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

[Gregory Mirsky <[e-mail]>]

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]; [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.
> 
>