Re: [mpls] ITU-T LS on MRPS (RFC 8227)

["Ryoo, Jeong-dong " <[e-mail]>]

Sasha,


In my opinion, it is ok for a ring protection to operate with three or more nodes.

The migration strategy from linear to ring that Huub mentioned in his earlier email can also be used.


So far, my understanding is that the ring protection defined in RFC 8227 will not work on a two node ring.



Best regards,


Jeong-dong









________________________________
보낸 사람 : "Alexander Vainshtein" <[e-mail]>
보낸 날짜 : 2019-06-13 20:01:47 ( +09:00 )
받는 사람 : 류정동 <[e-mail]>
참조 : '[e-mail]' <[e-mail]>, [e-mail] <[e-mail]>, Italo Busi <[e-mail]>
제목 : RE: [mpls] ITU-T LS on MRPS (RFC 8227)



Dear Jeong-dong,

I fully agree that we have only been asked to clarify a point for ITU-T.

But as part of the discussion around this request I see proposals to add some information  to the protocol messages, or to add some configuration knobs and buttons – which, if accepted, would  mean new work in this WG.

It is this work that I would like to avoid because I think that the problem they would solve is not worth the effort.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Ryoo, Jeong-dong <[e-mail]>



Sent: Thursday, June 13, 2019 1:48 PM



To: Alexander Vainshtein <[e-mail]>; [e-mail]; Italo Busi <[e-mail]>



Cc: '[e-mail]' <[e-mail]>



Subject: RE: [mpls] ITU-T LS on MRPS (RFC 8227)


Sasha and all,



According to the LS from ITU-T, they are unclear on the minimum number of nodes that the MPLS-TP ring protection defined in RFC 8227 can support. A unidirectinal failure case is shown in the LS, and they are asking for clarification of the expected behaviour in that specific case.



As far as I know, they are working on Revision of G.808.2, which describes generic aspects of various ring protection technologies, including MPLS-TP ring protection. In G.808.2, there is text describing how many nodes on a ring can be supported at minimum.



I don't think this discussion here to propose any improvements over the existing RFC.

We just need to clarify the point that ITU-T are not clear on.



Jeong-dong









________________________________
보낸 사람 : "Alexander Vainshtein" <[e-mail]<mailto:[e-mail]>>
보낸 날짜 : 2019-06-13 19:03:24 ( +09:00 )
받는 사람 : 류정동 <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Italo Busi <[e-mail]<mailto:[e-mail]>>
참조 : '[e-mail]' <[e-mail]<mailto:[e-mail]>>
제목 : RE: [mpls] ITU-T LS on MRPS (RFC 8227)


Dear all,
It seems  that this thread is mainly about a handling a unidirectional failure in a 2-node ring.

One possible way to solve that would be to use BFD (where B stays for “Bi-directional”) at the MPLS-TP Section layer.

If this is acceptable, I think that we (the MPLS WG) can save ourselves time and effort in trying to improve the protocol for what looks as a corner case of dubious practical value.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Ryoo, Jeong-dong <[e-mail]<mailto:[e-mail]>>


Sent: Thursday, June 13, 2019 12:32 PM


To: [e-mail]<mailto:[e-mail]>; Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>


Cc: '[e-mail]' <[e-mail]<mailto:[e-mail]>>


Subject: RE: [mpls] ITU-T LS on MRPS (RFC 8227)


Huub,



I agree that the text in RFC 8227 is correct.

But, the question we want to answer is if RFC 8227 will work on a ring with only two nodes.



When node A detects a unidirectional failure, node B needs to know which span is experiencing the failure through RPS messages. As there is no indication of short/long span in the RPS protocol message defined in RFC 8227, I don't think node B can determine which span will be used for traffic.Is there any other way that I am missing?



Best regards,



Jeong-dong





________________________________
보낸 사람 : "Huub van Helvoort" <[e-mail]<mailto:[e-mail]>>
보낸 날짜 : 2019-06-13 17:57:15 ( +09:00 )
받는 사람 : 류정동 <[e-mail]<mailto:[e-mail]>>, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>, Italo Busi <[e-mail]<mailto:[e-mail]>>
참조 : '[e-mail]' <[e-mail]<mailto:[e-mail]>>
제목 : Re: [mpls] ITU-T LS on MRPS (RFC 8227)


Hello Italo, Jeong-dong, Sasha, all,




Indeed the two node ring protection could be replaced by a linear protection


if this is the final configuration. It may be possible that in the (near-) future


the ring will grow by adding more ring nodes.


When setting up linear protection a working path and a protection path have


to be determined, similar in ring protection a short path and a long path have


to be determined.
So even before the ring protection becomes active the nodes will know which
of the two is the short path.


Based on that knowledge each node will be able to send the appropriate
request on the appropriate path.


IMHO the description of the protocol in RFC 8227 is correct.


Cheers, Huub.


=========



Italo and Sasha,



I am not sure about whether a two node ring has any practical significance. I think that linear protection would be more appropriate. Nevertheless, I also think it is important to know the extent to which any protocol is applied.



Please, see my responses inline below starting with [JR]:



Best regards,



Jeong-dong



________________________________
보낸 사람 : "Alexander Vainshtein" <[e-mail]><mailto:[e-mail]>
보낸 날짜 : 2019-06-12 03:27:30 ( +09:00 )
받는 사람 : Italo Busi <[e-mail]><mailto:[e-mail]>
참조 : '[e-mail]<mailto:[e-mail]>' <[e-mail]><mailto:[e-mail]>
제목 : Re: [mpls] ITU-T LS on MRPS (RFC 8227)


Italo,


I wonder if the question about a 2-node ring has any practical significance?


One could use MPLS-TP Linear ptotection in this case IMHO.


My 2c


Thumb typed by Sasha Vainshtein


From: mpls <[e-mail]><mailto:[e-mail]> on behalf of Italo Busi <[e-mail]><mailto:[e-mail]>


Sent: Tuesday, June 11, 2019 4:41:27 PM


To: [e-mail]<mailto:[e-mail]>


Subject: [mpls] ITU-T LS on MRPS (RFC 8227)


MPLS WG,


I have read the ITU-T LS 1609 (https://datatracker.ietf.org/liaison/1609/)


I think that the technical issue described in the LS is valid


However, the definition of short and long path in RFC 8227 is independent from the location of the unidirectional failure:


   Here, the short path refers to the shorter path on the ring between


   the source and destination node of the RPS request, and the long path


   refers to the longer path on the ring between the source and


   destination node of the RPS request.  Upon receipt of the RPS request


It seems to me that the MRPS protocol, as defined in RFC 8227, would still work if both nodes A and B consider the span affected by the unidirectional failure as the long path:


   The destination node MUST acknowledge the received RPS    requests by replying with an RPS request with the RR code on the    short path and an RPS request with the received RPS request code on    the long path.  Accordingly, when the node that detects the failure    receives the RPS request with RR code on the short path, then the RPS    request received from the same node along the long path SHOULD be    ignored.


In this case node A will receive RR from the long path (which has no failures) and ignore the SF which is not received from the short path (because of the unidirectional failure).


Therefore, it seems that the RPS protocol defined in RFC 8227 could work also with two‑nodes ring, assuming that both nodes have a common view about which span is the short path and which is the long path



[JR] I don’t think the common view on which span is short or long would solve the problem. The important thing is how node B knows which span should be used for selecting/bridging the traffic, when node A detects a unidirectional failure. Distinction between the short path and the long path is required because the traffic will be moved away from the short path, which has the failure, after protection switching.


The confusion is due to the fact that in a two‑nodes ring, the two paths have the same topology distance so the definition of short and long path is “arbitrary” and the required behavior seems not described in RFC 8227



[JR] We cannot pre-assign the short and long paths to two spans. The span that has a failure should be the short span and the traffic should be switched away from the short span. (Of course, we can define the failed span as the long span assuming the traffic will be moved to the short span. But, normally, a failed span is shorter than the remaining spans on a ring.)


It seems therefore possible to conclude that the RPS protocol defined in RFC 8227 could work also with two‑nodes ring but the description of the behavior is missing from RFC 8227



[JR] I think we need a short/long span indication in a RPS protocol message if we want to cover a two node ring. My conculsion would be that the RPS protocol defined in RFC 8227 will not work on a two node ring.


What do you think?


Thanks, Italo


Italo Busi


Principal Optical Transport Network Research Engineer


Huawei Technologies Co., Ltd.


Tel : [phone]


Email : [e-mail]<mailto:[e-mail]>



--

================================================================

Always remember that you are unique...just like everyone else...


clear="both">___________________________________________________________________________




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.


___________________________________________________________________________





clear="both">___________________________________________________________________________





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.



___________________________________________________________________________