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

[Jiangyuanlong <[e-mail]>]

One further enhancement:

Suggest to replace "If there is a need to extend the protocol to work for two-node rings that work should be brought to the IETF and MPLS working group in the form of an Internet Draft" with:

"If there is a need to extend the protocol to work for two-node rings, that work should be brought to the IETF and MPLS working group in the form of an Internet Draft".



Thanks,

Yuanlong



-----Original Message-----
From: mpls [mailto:[e-mail]] On Behalf Of Alexander Vainshtein
Sent: Sunday, June 16, 2019 3:55 PM
To: Loa Andersson <[e-mail]>
Cc: '[e-mail]' <[e-mail]>; [e-mail]; Italo Busi <[e-mail]>
Subject: Re: [mpls] ITU-T LS on MRPS (RFC 8227)



Loa,

Looks great!



One nit:



s/ and reached and reached/and reached/.



Regards,

Sasha



Office: [phone]

Cell:      [phone]

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



-----Original Message-----

From: Loa Andersson <[e-mail]<mailto:[e-mail]>>

Sent: Sunday, June 16, 2019 6:03 AM

To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Ryoo, Jeong-dong <[e-mail]<mailto:[e-mail]>>

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

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



Working Group,



Yes this is rough consensus. I suggest that we send the text (modulo

comments) I outlined below to SG15 as a liaison.





------------------- proposed liaison  ---------------------------



Hiroshi Otha, SG15



Thank you for your liaison of 2018-11-06 on "Request for clarification concerning MPLS-TP shared ring protection".



The MPLS working group has discussed the liaison on the mailing list and reached and reached consensus that the protocol defined in RFC 8227

(RPS) is not supposed to support 2-node rings.



If there is a need to extend the protocol to work for two-node rings that work should be brought to the IETF and MPLS working group in the form of an Internet Draft.



/Loa

MPLS wg co-chair



----------------- end proposed liaison -------------------------



Comments???





/Loa



On 2019-06-14 16:16, Alexander Vainshtein wrote:

> Loa and all,

> This looks as a "rough consensus" to me.

>

> How do we proceed from this point?

>

> Thumb typed by Sasha Vainshtein

>

>

>

> From: Italo Busi

> Sent: Friday, June 14, 11:13

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

> To: [e-mail]<mailto:[e-mail]>, Ryoo, Jeong-dong, Alexander Vainshtein

> Cc: '[e-mail]'

>

>

> Hi all,

>

> I also support Sasha’s statement: “RPS, as defined today, is not

> supposed to support 2-node rings”

>

> It looks like a good technical summary of the current state of the art

>

> Although there is no plan/intention to do any work to support 2-node

> rings, I would prefer not to say anything more not to close (or give

> the impression to close) the door to anybody who thinks otherwise

>

> Italo

>

> *Italo Busi***

> Principal Optical Transport Network Research Engineer Huawei

> Technologies Co., Ltd.

> Tel : [phone]

> Email : [e-mail]<mailto:[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!

>

> *From:* Huub van Helvoort [mailto:[e-mail]]

> *Sent:* venerdì 14 giugno 2019 09:55

> *To:* Ryoo, Jeong-dong <[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)

>

> Dear Italo, all,

>

> I also agree with the proposal from Jeong-dong and Sasha:

> Use the RPS only on three or more node rings.

>

> As I mentioned before for two node link protection there is already a

> linear protection protocol. Especially if this is long lasting topology.

> In a growth scenario the topology is temporary and after adding the

> third node the ring protection protocol can be activated.

>

> Investigating a possible solution may take a lot of effort and testing

> to make sure that it is flawless. And this is only for a corner case.

> It probably even requires a new version of the protocol, which I would

> like to avoid.

>

> Best regards, Huub.

>

> ========

>> Italo and all,

>>

>> I also agree with Sasha.

>>

>> Since they are unclear on the minimum number of nodes on a ring and

>> they asked for clarification for a undirectional failure scenario

>> with a two node ring, Sasha's conclusion is simple and unambiguous.

>>

>> Best regards,

>>

>> Jeong-dong

>>

>>

>>

>>

>> *보낸 사람**: *"Alexander Vainshtein"

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

>> <mailto:[e-mail]>

>> *보낸 날짜**: *2019-06-13 21:29:11 ( +09:00 ) *받는 사람**: *Italo Busi

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

>> *참조**: *'[e-mail] <mailto:[e-mail]>' <[e-mail]<mailto:[e-mail]>>

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

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

>> <mailto:[e-mail]>, 류정동 <[e-mail]<mailto:[e-mail]>>

>> <mailto:[e-mail]>

>> *제목**: *RE: [mpls] ITU-T LS on MRPS (RFC 8227)

>>

>> Italo,

>> From my POV, we can simply say (as suggested by Jeong-dong) that the

>> RPS, as defined today, is not supposed to support 2-node rings, and

>> that we (the MPLS WG) are quite happy to live with such a limitation.

>>

>> This would be quite unambiguous IMHO and will save further discussions.

>>

>> My 2c,

>> Sasha

>>

>> Office: [phone]

>> Cell:      [phone]

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

>> <mailto:[e-mail]>

>>

>> *From:* Italo Busi <[e-mail]<mailto:[e-mail]>>

>> <mailto:[e-mail]>

>>

>> *Sent:* Thursday, June 13, 2019 3:04 PM

>>

>> *To:* Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>

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

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

>>

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

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

>> <mailto:[e-mail]>

>>

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

>>

>> Hi Sasha, Jeong-dong, Huub,

>>

>> Before discussing whether the problem to solve is worth or not the

>> effort, I would like to better understand whether we have a problem

>> to solve and what is the real problem

>>

>> My initial understanding of the ITU-T LS was that the question was on

>> how B can understand which are the short and long paths, but after

>> this discussion, I think there are two, somewhat related but

>> potentially different, questions:

>> ·         How node B can understand which are the short and long

>> paths; ·         How node B can understand which is the failed span

>>

>> In case of a ring with three or more nodes, the ring map (topology

>> information) and the received RPS message provide sufficient

>> information to node B to answer to the two questions above.

>>

>> In case of a ring with only two nodes, this information is no longer

>> sufficient to answer to any of the two questions above: can we agree

>> on this point?

>>

>> If we agree on the previous point, the next question could be whether

>> in addition to the ring map and the received RPS message, there is

>> other information available to node B that could be used to answer to

>> the two questions above or not (changing the RPS message format to

>> pass this information from node A to node B is just a possible

>> solution to pass missing information)

>>

>> I agree with Sasha that using BFD, or more in general any mechanism

>> providing RDI information, as defined in [RFC5860] and [RFC6371],

>> could help node B to answer to the two questions above

>>

>> However, there is no description about how this solution would work

>>

>> Therefore, I think that the RPS protocol defined in RFC 8227 could

>> work also for a two-nodes ring, but the description of the behavior

>> is missing from RFC 8227

>>

>> Can we agree also on this conclusion?

>>

>> If we can agree on this conclusion, I think this would be sufficient

>> for a reply to the ITU-T LS

>>

>> We can later discuss about whether we need to start new work in the

>> MPLS WG to describe how the protocol defined in RFC 8227 could work

>> in a two-nodes ring. Please note that ITU-T LS is not asking us to

>> resolve any issue but just to clarify if and how the protocol can

>> work with a two‑nodes ring

>>

>> Italo

>>

>> *Italo Busi***

>> Principal Optical Transport Network Research Engineer Huawei

>> Technologies Co., Ltd.

>> Tel : [phone]

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

>>

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

>>

>> *From:* Alexander Vainshtein

>> [mailto:[e-mail]]

>>

>> *Sent:* giovedì 13 giugno 2019 13:01

>>

>> *To:* Ryoo, Jeong-dong <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>

>>

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

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

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

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

>>

>> *Subject:* 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]<mailto:[e-mail]>

>> <mailto:[e-mail]>

>>

>> *From:* Ryoo, Jeong-dong <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>

>>

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

>>

>> *To:* Alexander Vainshtein <[e-mail]

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

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

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

>>

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

>> <mailto:[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]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>, [e-mail]<mailto:[e-mail]>

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

>> <mailto:[e-mail]>>, 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)

>>

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

>> <mailto:[e-mail]>

>>

>> *From:* Ryoo, Jeong-dong <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>

>>

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

>>

>> *To:* [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>; Alexander

>> Vainshtein <[e-mail]

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

>> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>

>>

>> *Cc:* '[e-mail] <mailto:[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]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>,

>> Alexander Vainshtein <[e-mail]

>> <mailto:[e-mail]>>, Italo Busi

>> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>

>> *참조**: *'[e-mail] <mailto:[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]>>

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

>>> *보낸 날짜**: *2019-06-12 03:27:30 ( +09:00 ) *받는 사람**: *Italo Busi

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

>>> *참조**: *'[e-mail] <mailto:[e-mail]>' <[e-mail]<mailto:[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]>> <mailto:[e-mail]>

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

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

>>>

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

>>>

>>> *To:* [e-mail]<mailto:[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]> <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.

>>

>> _____________________________________________________________________

>> ______

>>

>>

>>

>> _____________________________________________________________________

>> ______

>>

>>

>>

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

>>

>> _____________________________________________________________________

>> ______

>>

>>

>

> -- ================================================================

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

>

>

>

> ______________________________________________________________________

> _____

>

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

> ______________________________________________________________________

> _____



--





Loa Andersson                        email: [e-mail]<mailto:[e-mail]>

Senior MPLS Expert

Bronze Dragon Consulting             phone: [phone]



___________________________________________________________________________



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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mpls