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

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 13 Oct 2013 15:55:37 +0000

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 13 Oct 2013 16:15:41 +0000

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: [email-masked] [[email-masked]] on behalf of Bhatia, Manav (Manav) [[email-masked]]
Sent: Sunday, October 13, 2013 5:55 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt

Hello,

Nits:

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.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 14 Oct 2013 02:21:40 +0000

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:[email-masked]] 
> Sent: Sunday, October 13, 2013 9:46 PM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> 
> Manav and all,
> "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).
> 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: [email-masked] [[email-masked]] on 
> behalf of Bhatia, Manav (Manav) [[email-masked]]
> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> 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.
> 
> 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) 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.
> 
> "OAM packets are subject to the same forwarding treatment as 
> the data traffic, but they are distinct from the data traffic."
> 
> 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.
> 
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Oct 2013 04:06:42 +0000

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) [[email-masked]]
Sent: Monday, October 14, 2013 4:21 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt

Hi Sasha,

Am I missing something?

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 14 Oct 2013 05:26:05 +0000

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 

> Sent: Monday, October 14, 2013 9:37 AM
> The original definition, to the best of my understanding, is 
> in Section 1.2.2. of RFC 5654 and says something else:
> 
> 
> 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. 
> 
> 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
> 
> 
> > "it would be useful to mention that an important property 
> of co-routed 
> > bidirectional path is that the forward and backward 
> directions share 
> > fate."
> >
> 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).
> co-routed 
> > bi-directional trail will result in traffic failur in the affected 
> > direction but not necessarily in the reverse one
> >
> 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: [email-masked] [[email-masked]] 
> on behalf of 
> > Bhatia, Manav (Manav) [[email-masked]]
> > 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.
> Routing ADs. 
> > For more information about the Routing Directorate, please 
> 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.
> >
> > 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) When explaining Control Plane (3.6) should we mention that it is 
> > possible to operate an MPLS-TP network without using a 
> Control Plane?
> >
> property of 
> > 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)."
> >
> fault cause 
> > is. It took me some time to understand what was meant by "fault 
> > cause". Can the authors of the draft rephrase
> 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.
> >
> > "OAM packets are subject to the same forwarding treatment 
> as the data 
> > traffic, but they are distinct from the data traffic."
> >
> > 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.
> >
> > 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.
> >
> >
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Oct 2013 06:21:41 +0000

Manav,
Lots of thanks for a prompt response.
I fully agree that the confusion is over what "fate-sharing" means.

E.g., OAM for an MPLS-TP LSP and user traffic that is carried by such an LSP are fate-sharing by design: 
* Your interpretation (as I understand from your example) mainly deals with the control/management plane aspects of an LSP. From this point of view the forward and backward directions of a co-routed bi-directional LSP are indeed fate-sharing. E.g., the definition in 5654 implies (from my point of view) that the corresdponding data plane configuration is set up/torn down atomically.  
However, if I extend/tweak your example a bit, I could say that unidirectional MP2M  LSPs set up by LDP within a given AS are fate-sharing with IP traffic paths set up by the IGP running in this AS - but somehow I do not feel that such a usage of the term "fate-sharing" would be appropriate. (If it were. there would be no need for LSP Ping...)

* My interpretation includes also the data plane aspects of an LSP. E.g.,  user traffic in an MPLS-TP LSP (of any type) and its OAM packets are fate-sharing by design, because exactly the same part of the label stack is looked for forwarding decisions (please note that both identification of OAM packets using GAL/GACH and prohibition of ECMP are part of this design). But two directions of a co-routed bi-direction LSP are not fate-sharing in this sense IMHO - unless such an LSP is (a) monitored using some OAM mechanism and (b) user traffic is blocked on both directions of an LSP if the monitoring mechanism  reports that one direction has failed. However, it is usually possible to say which direction has really failed in the case of a uni-directional failure: e.g., the local diagnostic of the BFD session - if used for monitoring - would report time-out expiration at one endpoint and "peer declared session down" at the other endpoint.  

Sent: Monday, October 14, 2013 7:26 AM

Sasha,

Cheers, Manav

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 14 Oct 2013 06:22:36 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Sunday, October 13, 2013 10:26 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt

Sasha,

Cheers, Manav 

> fax, and then delete the original and all copies thereof.
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Oct 2013 08:08:09 +0000

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
- Associated bidirectional LSPs MAY be protected using both unidirectional and bi-directional protection schemes

Does this match your understanding?

Regards,
     Sasha

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Monday, October 14, 2013 9:23 AM
> To: Bhatia, Manav (Manav); Alexander Vainshtein
> 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
> 
> 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
>

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Oct 2013 13:42:07 +0000

Sasha,

I think your comments apply equally to bidirectional LSPs.

Yours Irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexander Vainshtein
> Sent: Sunday, October 13, 2013 9:16 AM
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt
> 
> Manav and all,
> "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).
> 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: [email-masked] [[email-masked]] on behalf of Bhatia,
> Manav (Manav) [[email-masked]]
> 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
> 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.
> 
> 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) 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.
> 
> "OAM packets are subject to the same forwarding treatment as the data
> 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.
> 
> 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

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Oct 2013 14:34:04 +0000

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

> From: John E Drake [mailto:[email-masked]]
> Sent: Monday, October 14, 2013 4:42 PM
> To: Alexander Vainshtein; Bhatia, Manav (Manav)
> information

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Oct 2013 14:48:32 +0000

Manav,

Snipped, comment inline.

Yours Irrespectively,

John

> Bhatia, Manav (Manav)
> 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".
> 
> 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
> doesn't happen in case of Associated bidirectional LSPs.

[JD]  You attributing to the endpoints of a pair of Associated LSPs a behavior which
I think is actually at their discretion. 

> Its this difference that

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Oct 2013 14:55:05 +0000

Yours Irrespectively,

John

> Sent: Monday, October 14, 2013 1:08 AM
> To: Gregory Mirsky
> Cc: [email-masked]; Bhatia, Manav (Manav); [email-masked]; draft-ietf-mpls-
> [email-masked]; [email-masked]
> - 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. 

> 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.   

> > Cc: [email-masked]; [email-masked];
> > draft-ietf-mpls-tp-rosetta- [email-masked]; [email-masked]
> > 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
> >
> > Cc: [email-masked]; [email-masked];
> > draft-ietf-mpls-tp-rosetta- [email-masked]; [email-masked]
> > 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
> >
> > > The original definition, to the best of my understanding, is in
> > > Section 1.2.2. of RFC 5654 and says something else:
> > >
> > >
> > > 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.
> > >
> > > > From: Alexander Vainshtein
> > > > [mailto:[email-masked]]
> > > > 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
> > > > (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
> > > >
> > > >
> > > >
> > > > routing-related drafts as they pass through IETF last call and
> > > > IESG review, and sometimes on special request.
> > > > 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
> > > > 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
> > > > 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?
> > > >
> > > > An LSP segment comprises one or more continuous hops on the path
> > > > of the LSP.  [RFC5654] defines two terms.  A "segment"
> > > > inform us by e-mail, phone or fax, and then delete the original
> > > > and all copies thereof.
> > > >
> > > >
> > >
> > > information which is CONFIDENTIAL and which may be proprietary to
> > > ECI Telecom. If you have received this transmission in error, please

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Oct 2013 14:58:11 +0000

John,
RFC 5654 states that both directions of a co-routed bi-directional LSP are protected as a whole.
Hence I do not see how they may participate in a unidirectional protection scheme.

Regards,
     Sasha

> Sent: Monday, October 14, 2013 5:55 PM
> To: Alexander Vainshtein; Gregory Mirsky
> Cc: [email-masked]; Bhatia, Manav (Manav); [email-masked]; draft-ietf-mpls-tp-
> [email-masked]; [email-masked]
> > - Associated bidirectional LSPs MAY be protected using both unidirectional
> and
> > bi-directional protection schemes
>

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Oct 2013 15:09:39 +0000

Sasha,

My point was simply that in the data plane there isn't any difference between the two.

Yours Irrespectively,

John

> Sent: Monday, October 14, 2013 7:34 AM
> To: John E Drake
> 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
> 
> 
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf
> > Of
> > > Alexander Vainshtein
> > > 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
> > > 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.
> > > label is
> > used
> > > From: [email-masked] [[email-masked]] on behalf
> > > of Bhatia, Manav (Manav) [[email-masked]]
> > > 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
> > > 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.
> > >
> > > possible
> > to
> > > o) In 3.7, it would be useful to mention that an important property
> > > of co-
> > routed
> > > Similarly, in 3.1, we should mention that the forward and backward
> > > directions don't share fate.
> > >
> > > (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
> > > 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
> > >
> > > 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.
> > >
> > > "OAM packets are subject to the same forwarding treatment as the
> > > data traffic, but they are distinct from the data traffic."
> > >
> > > 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.
> > >
> > > 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.
> > >
> > >
> >
> 
> 
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 14 Oct 2013 11:17:08 -0400

They also share control plane / "connection" fate.

Lou

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Oct 2013 15:22:46 +0000

Sasha,

>From RFC 5654:

"Associated bidirectional path: A path that supports traffic flow in both directions but that is constructed from a pair of unidirectional
   paths (one for each direction) that are associated with one another at the path's ingress/egress points.  The forward and backward
   directions are setup, monitored, and protected independently.  As a consequence, they may or may not follow the same route (links
   and nodes) across the network."

Please pay special attention to the last two sentences. 

Yours Irrespectively,

John

> Sent: Monday, October 14, 2013 7:58 AM
> To: John E Drake; Gregory Mirsky
> > Cc: [email-masked]; Bhatia, Manav (Manav); [email-masked];
> > draft-ietf-mpls-tp- [email-masked];
> > [email-masked]
> > > Cc: [email-masked]; Bhatia, Manav (Manav); [email-masked];
> > > draft-ietf-mpls- [email-masked];
> > > [email-masked]
> > [JD]  Conversely, if a pair of associated unidirectional LSPs are
> > diversely routed, it may be difficult to apply bidirectional
> > protection to them.
> >
> > >
> > > > I do feel that "fate sharing" already has certain interpretation
> > > > in the
> > > industry.
> > > > 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
> > > > 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.
> > > > 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
> > > > 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
> > > >
> > > > > 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
> > > > > 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
> > > > >
> > > > >
> > > > > > 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
> > > > > > bi-directional trail will result in traffic failur in the
> > > > > > affected direction but not necessarily in the reverse one
> > > > > >
> > > > > > correctly. Since co-routed bi-directional trails do not
> > > > > > require using the
> > > > > same label in
> > > > > > Review Date: October 13th, 2013 IETF LC End Date: October 16,
> > > > > > 2013 Intended Status: Informational
> > > > > >
> > > > > > function
> > > > > > is. It took me some time to understand what was meant by
> > > > > > "fault cause". Can the authors of the draft rephrase
> > > > > > 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.
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > >
> > > > >
> > > > > transmission in error, please inform us by e-mail, phone or fax,
> > > > > and then delete the original and all copies thereof.
> > > > >
> > > > >

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Oct 2013 15:27:08 +0000

John,

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

> Sent: Monday, October 14, 2013 6:10 PM
> To: Alexander Vainshtein

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Oct 2013 15:37:43 +0000

Sasha,

I think the use of the term 'fate sharing' here is an example of 'mission creep'.

Yours Irrespectively,

John

> Sent: Monday, October 14, 2013 8:27 AM
> To: John E Drake
> 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
> 
> 
> > > 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
> > >
> > >
> > > > > From: [email-masked] [mailto:[email-masked]]
> > > > > On Behalf
> > > > Of
> > > > > Alexander Vainshtein
> > > > > directions
> > > > > trail will result in traffic failur in the affected direction
> > > > > but not necessarily in
> > > > the
> > > > > reverse one
> > > > >
> > > > > 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.
> > > > > same label is
> > > > > 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
> > > > > ADs, it would be helpful if you could consider them along with
> > > > > any other IETF Last
> > > > Call
> > > > > 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:
> > > > >
> > > > > is possible
> > > > > property of co-
> > > > > Similarly, in 3.1, we should mention that the forward and
> > > > > backward directions don't share fate.
> > > > >
> > > > > 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
> > > > >
> > > > > 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.
> > > > >
> > > > > 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.
> > > > >
> > > > > contains
> > > > > 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.
> > > > >
> > > > >
> > > >
> > >
> > >
> > >

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 14 Oct 2013 16:00:39 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Monday, October 14, 2013 8:27 AM
To: John E Drake
Cc: [email-masked]; [email-masked]; Bhatia, Manav (Manav); [email-masked]; [email-masked]
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt

John,

Regards,
     Sasha

> > > > us by e-mail, phone or fax, and then delete the original and all copies thereof.
> > > >
> > > >
> > >
> >
> >
> >

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Oct 2013 16:13:32 +0000

Greg,

I don't recall mentioning OAM. 

Yours Irrespectively,

John

> Sent: Monday, October 14, 2013 9:01 AM
> To: Alexander Vainshtein; John E Drake
> Cc: [email-masked]; [email-masked]; Bhatia, Manav (Manav); draft-
> [email-masked]; [email-masked]
> 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
> 
> Cc: [email-masked]; [email-masked]; Bhatia, Manav (Manav); draft-
> [email-masked]; [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Oct 2013 16:40:35 +0000

Greg,

I do not think that there is any contradiction between the two statements in question:

1. From the data plane point of view, when an OAM packet is trapped by a transit LSR due to TTL expiration (there is no other way to do that), it is identified as such based on the GAL/GACH in its label stack and passed to the "OAM engine" which is NOT part of the data plane. 
2. The difference between co-routed and associated bidirectional LSPs only comes into play if/when the "OAM engine", as part of its handling of the specific trapped packet, decides to send a response back to the its originator:
(a) In the case of an associated bi-directional LSP it may be unable to do so in MPLS-TP (in IP/MPLS the response could be sent as an unlabeled packet)
- In the case of a co-routed bi-directional LSP it can always send a response to the head-end LER because it understands the pairing between the forward and backward directions of this LSP (and it is the only entity that understands that). This pairing effectively means that the outgoing label for the backward direction of the co-routed bi-directional LSP can be found by the OAM engine if it knows the incoming label (and its context) of the trapped OAM packet
- If (as in the case of segment OAM) the response should be trapped by an upstream transit LSR and not by the head-end, it needs, the OAM engine, in addition to forming an appropriate label stack, must set the TTL to the right value - this is what http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-ttl-tlv-05 is about.

Hopefully these notes clarify my understanding of the situation. IMHO and FWIW they comply with the general claim of shared data plane between IP/MPLS and MPLS-TP.

Regards,
     Sasha

> Sent: Monday, October 14, 2013 7:01 PM
> Cc: [email-masked]; [email-masked]; Bhatia, Manav (Manav); draft-ietf-
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; Bhatia, Manav (Manav); draft-ietf-
> [email-masked]; [email-masked]

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 14 Oct 2013 17:01:58 +0000

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:[email-masked]] 
Sent: Monday, October 14, 2013 7:55 AM
To: Alexander Vainshtein; Gregory Mirsky
Cc: [email-masked]; Bhatia, Manav (Manav); [email-masked]; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt

Yours Irrespectively,

John

> Behalf Of Alexander Vainshtein
> - Co-routed bidirectional LSPs MAY be protected using bi-directional 
> protection schemes but MUST NOT be protected using unidirectional ones

> - Associated bidirectional LSPs MAY be protected using both 
> unidirectional and bi-directional protection schemes

> > I do feel that "fate sharing" already has certain interpretation in 
> > the
> industry.
> > "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
> > then the backward LSP changes too in case of co-routed bidirectional LSPs.
> > you can suggest something else as long as you believe its something 
> > that ought to be mentioned.
> >
> > Cheers, Manav
> >
> > > its two unidirectional component LSPs in each direction follow the 
> > > same path (in terms of both nodes and links).  An important 
> > > > and IESG review, and sometimes on special request.
> > > 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.
> > >
> > >
> information which is CONFIDENTIAL and which may be proprietary to ECI 
> inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
> 
>

---

From: John E Drake <[email-masked]>
Date: Mon, 14 Oct 2013 17:08:29 +0000

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

> Sent: Monday, October 14, 2013 10:02 AM
> To: John E Drake; Alexander Vainshtein
> 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
>

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 17 Oct 2013 14:53:14 +0200

Hello Manav,

You wrote:

> I have been selected as the Routing Directorate reviewer for this draft.

Thank you for your review.

I will address all your comments in the next spin of the draft.

I only want to bring some clarification to your proposal:

 > and backward directions share fate.

Fate-sharing is NOT a requirement for co-routed bi-directional
paths.  It is only a secondary effect.
E.g. in a cable only one of the fibers can fail/break, same for internal 
ports in routers, as well as forwarding.

The main requirements for co-routed bidirectional paths are:
== follow exactly the same path i.e. physical sections, and
    nodes in both directions
== the MEPS at the end-points can communicate directly via
    the RI (remote interface) NOT via the management plane
== during a protection switch both directions are switched
    (at the same time) from working entity to protection entity.
== both are managed as a single entity

The only fate-sharing requirement in ITU-T is for OAM packets
and data packets transported between the same endpoints
See the first paragraph in clauses 6.4 and 7.1 of G.8113.1
and G.8113.2.

To resolve your point I can add text to 3.7 that both directions
are managed and operated as a single entity;
and in 3.1 that they need not be a single management and
operational entity.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 21 Oct 2013 15:20:11 +0000

I saw the revised ID and the changes look good.

Cheers, Manav

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: Thursday, October 17, 2013 6:23 PM
To: Bhatia, Manav (Manav); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-rosetta-stone-12.txt

Hello Manav,

I only want to bring some clarification to your proposal:

 > 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.

Fate-sharing is NOT a requirement for co-routed bi-directional paths.  It is only a secondary effect.
E.g. in a cable only one of the fibers can fail/break, same for internal ports in routers, as well as forwarding.

    the RI (remote interface) NOT via the management plane == during a protection switch both directions are switched

The only fate-sharing requirement in ITU-T is for OAM packets and data packets transported between the same endpoints See the first paragraph in clauses 6.4 and 7.1 of G.8113.1 and G.8113.2.

To resolve your point I can add text to 3.7 that both directions are managed and operated as a single entity; and in 3.1 that they need not be a single management and operational entity.