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

[Loa Andersson <[e-mail]>]

All,

First, I have made a mistake and did not notice this liaison in time.

It is now only five days left until we have to respond, and currently I
only have vague idea what to say.

Please discuss this also, if there is a way extending the dead-line that
would be appreciated.

/Loa

On 2019-06-13 15:35, 류정동 wrote:
> 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]>
> *보낸 날짜 : *2019-06-12 03:27:30 ( +09:00 )
> *받는 사람 : *Italo Busi <[e-mail]>
> *참조 : *'[e-mail]' <[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]> on behalf of Italo Busi 
> <[e-mail]>
> 
> *Sent:*Tuesday, June 11, 2019 4:41:27 PM
> 
> *To:*[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]
> 
> Image
> 
> This e-mail and its attachments contain confidential information from 
> HUAWEI, which is intended only for the person or entity whose address is 
> listed above. Any use of the information contained herein in any way 
> (including, but not limited to, total or partial disclosure, 
> reproduction, or dissemination) by persons other than the intended 
> recipient(s) is prohibited. If you receive this e-mail in error, please 
> notify the sender by phone or email immediately and delete it!
> 
> 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.
> 
> ___________________________________________________________________________
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]