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

From: Italo Busi <[email-masked]>
Date: Tue, 11 Jun 2019 16:41:27 +0000

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

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

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

What do you think?

Thanks, Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : [email-masked]

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 <[email-masked]>
Date: Tue, 11 Jun 2019 18:26:46 +0000

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 <[email-masked]> on behalf of Italo Busi <[email-masked]>
Sent: Tuesday, June 11, 2019 4:41:27 PM
To: [email-masked]
Subject: [mpls] ITU-T LS on MRPS (RFC 8227)

MPLS WG,

   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.

What do you think?

Thanks, Italo

Italo Busi

___________________________________________________________________________

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: 류정동 <[email-masked]>
Date: Thu, 13 Jun 2019 07:35:45 +0000

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" <[email-masked]>
보낸 날짜 : 2019-06-12 03:27:30 ( +09:00 )
받는 사람 : Italo Busi <[email-masked]>
참조 : [email-masked]' <[email-masked]>
제목 : Re: [mpls] ITU-T LS on MRPS (RFC 8227)

Italo,

My 2c

To: [email-masked]

MPLS WG,

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

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

[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

Tel : +39 345 4721946

clear="both">___________________________________________________________________________

and all copies thereof.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 13 Jun 2019 16:13:49 +0800

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.
> 
> ------------------------------------------------------------------------
> *보낸 사람 : *"Alexander Vainshtein" <[email-masked]>
> *보낸 날짜 : *2019-06-12 03:27:30 ( +09:00 )
> *받는 사람 : *Italo Busi <[email-masked]>
> *참조 : [email-masked]' <[email-masked]>
> *제목 : *Re: [mpls] ITU-T LS on MRPS (RFC 8227)
> 
> Italo,
> 
> *From:*mpls <[email-masked]> on behalf of Italo Busi 
> <[email-masked]>
> 
> *Sent:*Tuesday, June 11, 2019 4:41:27 PM
> 
> *To:[email-masked]
> 
> *Subject:*[mpls] ITU-T LS on MRPS (RFC 8227)
> 
> MPLS WG,
> 
> However, the definition of short and long path in RFC 8227 is 
> independent from the location of the unidirectional failure:
> 
> 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***
> 
> 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!
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 13 Jun 2019 10:56:59 +0200

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"
<[email-masked]>

받는 사람 : Italo Busi
<[email-masked]>

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

From: mpls <[email-masked]>
on behalf of Italo Busi
<[email-masked]>

To: [email-masked]

MPLS WG,

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

Tel : +39 345 4721946

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

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 13 Jun 2019 09:28:51 +0000

I agreed with Huub, though the definitions of short path and long path need to be enhanced to cover two node ring.

Best regards,
Yuanlong

From: mpls [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Thursday, June 13, 2019 4:57 PM
To: 류정동 <[email-masked]>; Alexander Vainshtein <[email-masked]>; Italo Busi <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: Re: [mpls] ITU-T LS on MRPS (RFC 8227)

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,

Best regards,

Jeong-dong

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

Italo,

My 2c

From: mpls <[email-masked]><mailto:[email-masked]> on behalf of Italo Busi <[email-masked]><mailto:[email-masked]>

To: [email-masked]<mailto:[email-masked]>

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

Email : [email-masked]<mailto:[email-masked]>

--

---

From: "Ryoo, Jeong-dong " <[email-masked]>
Date: Thu, 13 Jun 2019 09:31:55 +0000

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" <[email-masked]>
보낸 날짜 : 2019-06-13 17:57:15 ( +09:00 )
받는 사람 : 류정동 <[email-masked]>, Alexander Vainshtein <[email-masked]>, Italo Busi <[email-masked]>
참조 : [email-masked]' <[email-masked]>
제목 : Re: [mpls] ITU-T LS on MRPS (RFC 8227)

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 13 Jun 2019 10:03:01 +0000

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: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: Ryoo, Jeong-dong <[email-masked]>
Sent: Thursday, June 13, 2019 12:32 PM
To: [email-masked]; Alexander Vainshtein <[email-masked]>; Italo Busi <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Huub,

Best regards,

Jeong-dong

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

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

--

---

From: "Ryoo, Jeong-dong " <[email-masked]>
Date: Thu, 13 Jun 2019 10:47:43 +0000

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" <[email-masked]>
보낸 날짜 : 2019-06-13 19:03:24 ( +09:00 )
받는 사람 : 류정동 <[email-masked]>, [email-masked] <[email-masked]>, Italo Busi <[email-masked]>
참조 : [email-masked]' <[email-masked]>
제목 : RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Dear all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Huub,

Best regards,

Jeong-dong

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

--

and all copies thereof.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 13 Jun 2019 11:01:25 +0000

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: +972-39266302
Cell:      +972-549266302

From: Ryoo, Jeong-dong <[email-masked]>
Sent: Thursday, June 13, 2019 1:48 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]; Italo Busi <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Sasha and all,

Jeong-dong

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

Dear all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: Ryoo, Jeong-dong <[email-masked]<mailto:[email-masked]>>

To: [email-masked]<mailto:[email-masked]>; Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>

Cc: [email-masked]' <[email-masked]<mailto:[email-masked]>>

Huub,

Best regards,

Jeong-dong

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

--

and all copies thereof.

---

From: "Ryoo, Jeong-dong " <[email-masked]>
Date: Thu, 13 Jun 2019 11:35:39 +0000

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" <[email-masked]>
보낸 날짜 : 2019-06-13 20:01:47 ( +09:00 )
받는 사람 : 류정동 <[email-masked]>
참조 : [email-masked]' <[email-masked]>, [email-masked] <[email-masked]>, Italo Busi <[email-masked]>
제목 : RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Dear Jeong-dong,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha and all,

Jeong-dong

Dear all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Huub,

Best regards,

Jeong-dong

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

--

and all copies thereof.

and all copies thereof.

---

From: Italo Busi <[email-masked]>
Date: Thu, 13 Jun 2019 12:04:17 +0000

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

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: giovedì 13 giugno 2019 13:01
To: Ryoo, Jeong-dong <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]; Italo Busi <[email-masked]>
Subject: RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Dear Jeong-dong,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Italo Busi <[email-masked]<mailto:[email-masked]>>

Sasha and all,

Jeong-dong

Dear all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Huub,

Best regards,

Jeong-dong

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

--

and all copies thereof.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 13 Jun 2019 12:13:46 +0000

Dear Jeong-dong,
I am OK with the statement that ring protection works with 3 (or more) nodes in a ring.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Ryoo, Jeong-dong <[email-masked]>
Sent: Thursday, June 13, 2019 2:36 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]; Italo Busi <[email-masked]>
Subject: RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Sasha,

Best regards,

Jeong-dong

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

Dear Jeong-dong,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha and all,

Jeong-dong

Dear all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Huub,

Best regards,

Jeong-dong

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

--

and all copies thereof.

and all copies thereof.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 13 Jun 2019 12:28:40 +0000

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: +972-39266302
Cell:      +972-549266302

From: Italo Busi <[email-masked]>
Sent: Thursday, June 13, 2019 3:04 PM
To: Alexander Vainshtein <[email-masked]>; Ryoo, Jeong-dong <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]
Subject: RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Italo

Italo Busi

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: giovedì 13 giugno 2019 13:01
To: Ryoo, Jeong-dong <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Italo Busi <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Dear Jeong-dong,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha and all,

Jeong-dong

Dear all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Huub,

Best regards,

Jeong-dong

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

--

and all copies thereof.

---

From: "Ryoo, Jeong-dong " <[email-masked]>
Date: Fri, 14 Jun 2019 01:55:27 +0000

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" <[email-masked]>
보낸 날짜 : 2019-06-13 21:29:11 ( +09:00 )
받는 사람 : Italo Busi <[email-masked]>
참조 : [email-masked]' <[email-masked]>, [email-masked] <[email-masked]>, 류정동 <[email-masked]>
제목 : RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Italo,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Italo

Italo Busi

Dear Jeong-dong,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha and all,

Jeong-dong

Dear all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Huub,

Best regards,

Jeong-dong

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

--

and all copies thereof.

and all copies thereof.

and all copies thereof.

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 14 Jun 2019 09:55:27 +0200

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

받는 사람 : Italo Busi
<[email-masked]>

참조 : [email-masked]' <[email-masked]>,
[email-masked] <[email-masked]>, 류정동
<[email-masked]>

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: +972-39266302

Cell:      +972-549266302

Email:
[email-masked]

From: Italo Busi
<[email-masked]>

To: Alexander Vainshtein
<[email-masked]>; Ryoo,
Jeong-dong <[email-masked]>

Cc: [email-masked]' <[email-masked]>;
[email-masked]

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

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

Tel : +39 345 4721946

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:[email-masked]]

Cc: [email-masked]' <[email-masked]>;
[email-masked]; Italo Busi <[email-masked]>

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: +972-39266302

Cell:      +972-549266302

Email:
[email-masked]

From: Ryoo,
Jeong-dong <[email-masked]>

To: Alexander Vainshtein <[email-masked]>;
[email-masked];
Italo Busi <[email-masked]>

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" <[email-masked]>

보낸 날짜 :
2019-06-13
19:03:24 ( +09:00 )

받는 사람 :
류정동 <[email-masked]>,
[email-masked]
<[email-masked]>,
Italo Busi <[email-masked]>

참조 :
[email-masked]'
<[email-masked]>

제목 :
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:
+972-39266302

Cell:
+972-549266302

Email:
[email-masked]

From:
Ryoo, Jeong-dong <[email-masked]>

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

To:
[email-masked];
Alexander Vainshtein <[email-masked]>;
Italo Busi <[email-masked]>

Cc:
[email-masked]' <[email-masked]>

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" <[email-masked]>

보낸
날짜
:
2019-06-13
17:57:15 ( +09:00 )

받는
사람
:
류정동
<[email-masked]>,
Alexander Vainshtein <[email-masked]>,
Italo Busi <[email-masked]>

참조
:
[email-masked]'
<[email-masked]>

제목
:
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"

보낸 날짜
:
2019-06-12
03:27:30 (
+09:00 )

받는 사람
:
Italo Busi

<[email-masked]>

참조
:
[email-masked]'
<[email-masked]>

제목
:
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
<[email-masked]> on behalf of
Italo Busi
<[email-masked]>

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

To:
[email-masked]

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

Tel : +39 345 4721946

--

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.

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: Italo Busi <[email-masked]>
Date: Fri, 14 Jun 2019 08:12:52 +0000

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

From: Huub van Helvoort [mailto:[email-masked]]
Sent: venerdì 14 giugno 2019 09:55
To: Ryoo, Jeong-dong <[email-masked]>; Alexander Vainshtein <[email-masked]>; Italo Busi <[email-masked]>
Cc: [email-masked]' <[email-masked]>
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.

Best regards,

Jeong-dong

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

Italo,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Italo Busi <[email-masked]><mailto:[email-masked]>

To: Alexander Vainshtein <[email-masked]><mailto:[email-masked]>; Ryoo, Jeong-dong <[email-masked]><mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

•         How node B can understand which are the short and long paths;

•         How node B can understand which is the failed span

Italo

Italo Busi

Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Italo Busi <[email-masked]<mailto:[email-masked]>>

Dear Jeong-dong,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>

Sasha and all,

Jeong-dong

참조 : [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>

Dear all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>

Huub,

Best regards,

Jeong-dong

참조 : [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

--

and all copies thereof.

and all copies thereof.

and all copies thereof.

--

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 14 Jun 2019 08:16:29 +0000

Loa and all,
This looks as a "rough consensus" to me.

How do we proceed from this point?

From: Italo Busi
Sent: Friday, June 14, 11:13
Subject: RE: [mpls] ITU-T LS on MRPS (RFC 8227)
To: [email-masked], Ryoo, Jeong-dong, Alexander Vainshtein
Cc: [email-masked]'

Hi all,

Italo

Italo Busi

Dear Italo, all,

Best regards, Huub.

========
Italo and all,

I also agree with Sasha.

Best regards,

Jeong-dong

Italo,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Italo

Italo Busi

Dear Jeong-dong,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha and all,

Jeong-dong

Dear all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Huub,

Best regards,

Jeong-dong

to be determined.

Cheers, Huub.

=========

Italo and Sasha,

Best regards,

Jeong-dong

Italo,

My 2c

MPLS WG,

What do you think?

Thanks, Italo

Italo Busi

Tel : +39 345 4721946

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

and all copies thereof.

and all copies thereof.

and all copies thereof.

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

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 14 Jun 2019 10:15:37 +0200

Hey Loa,

I think there is some agreement on
responding to the liaison.

"The two node RPS is not intended to be applied on two node
rings".

Cheers, Huub.

========

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

Tel : +39 345 4721946

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:[email-masked]]

To: Ryoo, Jeong-dong <[email-masked]>;
Alexander Vainshtein
<[email-masked]>; Italo Busi
<[email-masked]>

Dear Italo, all,

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

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

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

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"

보낸 날짜
:
2019-06-13
21:29:11 ( +09:00 )

받는 사람
:
Italo
Busi
<[email-masked]>

참조
:
[email-masked]'
<[email-masked]>,

[email-masked] <[email-masked]>,
류정동 <[email-masked]>

제목
:
RE:

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:
+972-39266302

Cell:
+972-549266302

Email:

From:
Italo Busi
<[email-masked]>

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

To: Alexander
Vainshtein
<[email-masked]>;
Ryoo, Jeong-dong
<[email-masked]>

Cc: [email-masked]'
<[email-masked]>;

[email-masked]

Subject: RE: [mpls]

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

Tel : +39 345 4721946

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:[email-masked]]

Sent: giovedì 13 giugno 2019
13:01

To: Ryoo,

Cc: [email-masked]'
<[email-masked]>;
[email-masked];
Italo Busi <[email-masked]>

Subject: RE: [mpls]

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:
+972-39266302

Cell:
+972-549266302

Email:

From:

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

To: Alexander
Vainshtein <[email-masked]>;
[email-masked];
Italo Busi <[email-masked]>

Cc: [email-masked]'
<[email-masked]>

Subject: RE: [mpls]

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

보낸 날짜 :
2019-06-13
19:03:24 ( +09:00 )

받는 사람 :
류정동
<[email-masked]>,
[email-masked]
<[email-masked]>,

참조 :
[email-masked]'
<[email-masked]>

제목 :
RE:

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:
+972-39266302

Cell:
+972-549266302

Email:

From:

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

To:
[email-masked];

Cc: [email-masked]'
<[email-masked]>

Subject: RE: [mpls]

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

보낸 날짜 :
2019-06-13
17:57:15 ( +09:00 )

받는 사람 :
류정동
<[email-masked]>,
Alexander Vainshtein
<[email-masked]>, Italo
Busi <[email-masked]>

참조 :
[email-masked]'
<[email-masked]>

제목 :
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"

보낸
날짜 :
2019-06-12
03:27:30 (
+09:00 )

받는
사람 :
Italo Busi

<[email-masked]>

참조 :
[email-masked]'
<[email-masked]>

제목 :
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

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

To:
[email-masked]

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

MPLS
WG,

I
have read the
ITU-T LS 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

Tel : +39 345 4721946

--

This
e-mail message is intended for the
recipient only and contains
information which is

CONFIDENTIAL

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.

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: Loa Andersson <[email-masked]>
Date: Sun, 16 Jun 2019 11:02:52 +0800

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:
> 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***
> *From:* Huub van Helvoort [mailto:[email-masked]]
> *Sent:* venerdì 14 giugno 2019 09:55
> *To:* Ryoo, Jeong-dong <[email-masked]>; Alexander Vainshtein 
> <[email-masked]>; Italo Busi <[email-masked]>
> *Cc:* [email-masked]' <[email-masked]>
> *Subject:* Re: [mpls] ITU-T LS on MRPS (RFC 8227)
> 
> Dear Italo, all,
> 
>> 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" 
>> <mailto:[email-masked]>
>> *보낸 날짜**: *2019-06-13 21:29:11 ( +09:00 )
>> *받는 사람**: *Italo Busi <[email-masked]> 
>> <mailto:[email-masked]>
>> *참조**: [email-masked] <mailto:[email-masked]>' <[email-masked]> 
>> <mailto:[email-masked]>, [email-masked] 
>> <mailto:[email-masked]> <[email-masked]> 
>> <mailto:[email-masked]>, 류정동 <[email-masked]> 
>> <mailto:[email-masked]>
>> *제목**: *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.
>>
>> <mailto:[email-masked]>
>>
>> *From:* Italo Busi <[email-masked]> <mailto:[email-masked]>
>>
>> *Sent:* Thursday, June 13, 2019 3:04 PM
>>
>> *To:* Alexander Vainshtein <[email-masked]> 
>> <mailto:[email-masked]>; Ryoo, Jeong-dong 
>> <[email-masked]> <mailto:[email-masked]>
>>
>> *Cc:* [email-masked] <mailto:[email-masked]>' <[email-masked]> 
>> <mailto:[email-masked]>; [email-masked] 
>> <mailto:[email-masked]>
>>
>> *Subject:* RE: [mpls] ITU-T LS on MRPS (RFC 8227)
>>
>> 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 
>> 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:
>> 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
>>
>> 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
>>
>> 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***
>> Email : [email-masked] <mailto:[email-masked]>
>>
>> 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, 
>> 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:[email-masked]]
>>
>> *Sent:* giovedì 13 giugno 2019 13:01
>>
>> *To:* Ryoo, Jeong-dong <[email-masked] <mailto:[email-masked]>>
>>
>> *Cc:* [email-masked] <mailto:[email-masked]>' <[email-masked] 
>> <mailto:[email-masked]>>; [email-masked] 
>> <mailto:[email-masked]>; Italo Busi <[email-masked] 
>> <mailto:[email-masked]>>
>>
>> *Subject:* RE: [mpls] ITU-T LS on MRPS (RFC 8227)
>>
>> Dear Jeong-dong,
>> 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 
>> <mailto:[email-masked]>
>>
>> *From:* Ryoo, Jeong-dong <[email-masked] <mailto:[email-masked]>>
>>
>> *Sent:* Thursday, June 13, 2019 1:48 PM
>>
>> *To:* Alexander Vainshtein <[email-masked] 
>> <mailto:[email-masked]>>; [email-masked] 
>> <mailto:[email-masked]>; Italo Busi <[email-masked] 
>> <mailto:[email-masked]>>
>>
>> *Cc:* [email-masked] <mailto:[email-masked]>' <[email-masked] 
>> <mailto:[email-masked]>>
>>
>> *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.
>>
>> *보낸 사람**: *"Alexander Vainshtein" 
>> <[email-masked] 
>> <mailto:[email-masked]>>
>> *보낸 날짜**: *2019-06-13 19:03:24 ( +09:00 )
>> *받는 사람**: *류정동 <[email-masked] <mailto:[email-masked]>>, 
>> [email-masked] <mailto:[email-masked]> 
>> <[email-masked] <mailto:[email-masked]>>, Italo Busi 
>> <[email-masked] <mailto:[email-masked]>>
>> *참조**: [email-masked] <mailto:[email-masked]>' <[email-masked] 
>> <mailto:[email-masked]>>
>> *제목**: *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: +972-39266302
>> Cell:      +972-549266302
>> <mailto:[email-masked]>
>>
>> *From:* Ryoo, Jeong-dong <[email-masked] <mailto:[email-masked]>>
>>
>> *Sent:* Thursday, June 13, 2019 12:32 PM
>>
>> *To:* [email-masked] <mailto:[email-masked]>; Alexander 
>> Vainshtein <[email-masked] 
>> <mailto:[email-masked]>>; Italo Busi 
>> <[email-masked] <mailto:[email-masked]>>
>>
>> *Cc:* [email-masked] <mailto:[email-masked]>' <[email-masked] 
>> <mailto:[email-masked]>>
>>
>> *Subject:* RE: [mpls] ITU-T LS on MRPS (RFC 8227)
>>
>> Huub,
>>
>> 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" <[email-masked] 
>> <mailto:[email-masked]>>
>> *보낸 날짜**: *2019-06-13 17:57:15 ( +09:00 )
>> *받는 사람**: *류정동 <[email-masked] <mailto:[email-masked]>>, 
>> Alexander Vainshtein <[email-masked] 
>> <mailto:[email-masked]>>, Italo Busi 
>> <[email-masked] <mailto:[email-masked]>>
>> *참조**: [email-masked] <mailto:[email-masked]>' <[email-masked] 
>> <mailto:[email-masked]>>
>> *제목**: *Re: [mpls] ITU-T LS on MRPS (RFC 8227)
>>
>>> 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.
>>>
>>> *보낸 사람**: *"Alexander Vainshtein" 
>>> <mailto:[email-masked]>
>>> *보낸 날짜**: *2019-06-12 03:27:30 ( +09:00 )
>>> *받는 사람**: *Italo Busi <[email-masked]> 
>>> <mailto:[email-masked]>
>>> *참조**: [email-masked] <mailto:[email-masked]>' <[email-masked]> 
>>> <mailto:[email-masked]>
>>> *제목**: *Re: [mpls] ITU-T LS on MRPS (RFC 8227)
>>>
>>> Italo,
>>>
>>> *From:* mpls <[email-masked]> <mailto:[email-masked]> 
>>> on behalf of Italo Busi <[email-masked]> 
>>> <mailto:[email-masked]>
>>>
>>> *Sent:* Tuesday, June 11, 2019 4:41:27 PM
>>>
>>> *To:* [email-masked] <mailto:[email-masked]>
>>>
>>> *Subject:* [mpls] ITU-T LS on MRPS (RFC 8227)
>>>
>>> MPLS WG,
>>>
>>> I have read the ITU-T LS 1609 
>>> path.  Accordingly, when the node that detects the 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
>>>
>>> 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
>>>
>>> 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 *
>>>
>>> Email : [email-masked] <mailto:[email-masked]>
>>
>> -- ================================================================ 
>> ��
> -- ================================================================ 

--

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 16 Jun 2019 07:54:51 +0000

Loa,
Looks great!

One nit: 

s/ and reached and reached/and reached/.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: Sunday, June 16, 2019 6:03 AM
To: Alexander Vainshtein <[email-masked]>; Italo Busi <[email-masked]>; [email-masked]; Ryoo, Jeong-dong <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: Re: [mpls] ITU-T LS on MRPS (RFC 8227)

Working Group,

------------------- 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:
> 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 : +39 345 4721946
> As I mentioned before for two node link protection there is already a 
> linear protection protocol. Especially if this is long lasting topology.
>> 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
>>
>>
>>
>>
>> *보낸 날짜**: *2019-06-13 21:29:11 ( +09:00 ) *받는 사람**: *Italo Busi 
>> <[email-masked]> <mailto:[email-masked]>
>> effort, I would like to better understand whether we have a problem 
>> to solve and what is the real problem
>>
>> ·         How node B can understand which are the short and long 
>> paths; ·         How node B can understand which is the failed span
>>
>> work also for a two-nodes ring, but the description of the behavior 
>> is missing from RFC 8227
>>
>> 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 : +39 345 4721946
>> *From:* Alexander Vainshtein 
>> [mailto:[email-masked]]
>>
>> 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.
>>
>> including MPLS-TP ring protection. In G.808.2, there is text 
>> describing how many nodes on a ring can be supported at minimum.
>>
>> *보낸 날짜**: *2019-06-13 19:03:24 ( +09:00 ) *받는 사람**: *류정동 
>> <[email-masked] <mailto:[email-masked]>>, [email-masked] 
>> <mailto:[email-masked]> <[email-masked] 
>> <mailto:[email-masked]>>, Italo Busi <[email-masked] 
>> <mailto:[email-masked]>> *보낸 날짜**: *2019-06-13 17:57:15 ( 
>> +09:00 ) *받는 사람**: *류정동 <[email-masked] <mailto:[email-masked]>>, 
>> So even before the ring protection becomes active the nodes will know 
>> which of the two is the short path.
>>
>> appropriate request on the appropriate path.
>>
>>> *보낸 날짜**: *2019-06-12 03:27:30 ( +09:00 ) *받는 사람**: *Italo Busi 
>>> <[email-masked]> <mailto:[email-masked]>
>>> short path and an RPS request with the received RPS request code on    the long
>>> failures) and ignore the SF which is not received from the short 
>>> path (because of the unidirectional failure).
>>>
>>> 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
>>>
>>> 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
>>>
>>> that the RPS protocol defined in RFC 8227 will not work on a two 
>>> node ring.
>>>
>>> What do you think?
>>>
>>> Thanks, Italo
>>>
>>> *Italo Busi *
>>>
> 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: "Ryoo, Jeong-dong " <[email-masked]>
Date: Mon, 17 Jun 2019 00:48:47 +0000

Loa,

Thank you for preparing the text.

It looks great to me, too.

Best regards,

Jeong-dong

________________________________
보낸 사람 : "Alexander Vainshtein" <[email-masked]>
보낸 날짜 : 2019-06-16 16:55:31 ( +09:00 )
받는 사람 : Loa Andersson <[email-masked]>
참조 : [email-masked]' <[email-masked]>, Italo Busi <[email-masked]>, [email-masked] <[email-masked]>, 류정동 <[email-masked]>
제목 : RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Loa,

Looks great!

One nit:

Regards,

Sasha

Office: +972-39266302

Cell: +972-549266302

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

From: Loa Andersson

To: Alexander Vainshtein ; Italo Busi ; [email-masked]; Ryoo, Jeong-dong

Cc: [email-masked]'

Working Group,

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

Hiroshi Otha, SG15

/Loa

MPLS wg co-chair

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

Comments???

/Loa

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

> supposed to support 2-node rings”

> *To:* Ryoo, Jeong-dong ; Alexander Vainshtein

> ; Italo Busi

> *Cc:* [email-masked]'

>> *참조**: [email-masked] '

>> , [email-masked]

>> , 류정동

>> *From:* Italo Busi

>> *To:* Alexander Vainshtein

>> ; Ryoo, Jeong-dong

>> *Cc:* [email-masked] '

>> ; [email-masked]

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

>> for a reply to the ITU-T LS

>> *To:* Ryoo, Jeong-dong >

>> *Cc:* [email-masked] '

"">>> >; [email-masked]

>> ; Italo Busi

"">>> >

>> *From:* Ryoo, Jeong-dong >

>> *To:* Alexander Vainshtein

"">>> >; [email-masked]

>> ; Italo Busi

"">>> >

>> *Cc:* [email-masked] '

"">>> >

>> I don't think this discussion here to propose any improvements over

>> the existing RFC.

>> >, [email-masked]

"">>> >, Italo Busi

"">>> >

>> *참조**: [email-masked] '

"">>> >

>> *From:* Ryoo, Jeong-dong >

>> *To:* [email-masked] ; Alexander

>> Vainshtein

"">>> >; Italo Busi

>> *Cc:* [email-masked] '

"">>> >

>> But, the question we want to answer is if RFC 8227 will work on a

>> *보낸 사람**: *"Huub van Helvoort"

"">>> > *보낸 날짜**: *2019-06-13 17:57:15 (

>> +09:00 ) *받는 사람**: *류정동 >,

>> Alexander Vainshtein

"">>> >, Italo Busi

>> *참조**: [email-masked] '

"">>> >

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

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

>>> *참조**: [email-masked] '

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

>>> *From:* mpls

>>> *To:* [email-masked]

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

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

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

>>> receives the RPS request with RR code on the short path, then the

>> clear="both">________________________________________________________

>> ___________________

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

>> _____________________________________________________________________

>> ______

>> _____________________________________________________________________

>> ______

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

>> _____________________________________________________________________

>> ______

>> clear="both">________________________________________________________

>> ___________________

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

>> _____________________________________________________________________

>> ______

> ______________________________________________________________________

> _____

> ______________________________________________________________________

> _____

--

Senior MPLS Expert

and all copies thereof.

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 17 Jun 2019 02:26:12 +0000

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:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Sunday, June 16, 2019 3:55 PM
To: Loa Andersson <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]; Italo Busi <[email-masked]>
Subject: Re: [mpls] ITU-T LS on MRPS (RFC 8227)

Loa,

Looks great!

One nit:

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

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

From: Loa Andersson <[email-masked]<mailto:[email-masked]>>

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

Working Group,

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

Hiroshi Otha, SG15

/Loa

MPLS wg co-chair

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

Comments???

/Loa

> To: [email-masked]<mailto:[email-masked]>, Ryoo, Jeong-dong, Alexander Vainshtein

> *To:* Ryoo, Jeong-dong <[email-masked]<mailto:[email-masked]>>; Alexander Vainshtein

> <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>

> *Cc:* [email-masked]' <[email-masked]<mailto:[email-masked]>>

>> <[email-masked]<mailto:[email-masked]>>

>> <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>

>> *참조**: [email-masked] <mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>

>> <mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

>> <mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

>> <mailto:[email-masked]>, 류정동 <[email-masked]<mailto:[email-masked]>>

>> *From:* Italo Busi <[email-masked]<mailto:[email-masked]>>

>> *To:* Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>

>> <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>

>> *Cc:* [email-masked] <mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>

>> <mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

>> Email : [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

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

>> <mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

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

>> <mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

>> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>, [email-masked]<mailto:[email-masked]>

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

>> *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Alexander

>> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>> +09:00 ) *받는 사람**: *류정동 <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>,

>> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

>>> <[email-masked]<mailto:[email-masked]>>

>>> <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>

>>> *참조**: [email-masked] <mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>

>>> *From:* mpls <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>

>>> on behalf of Italo Busi <[email-masked]<mailto:[email-masked]>>

>>> *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>> Email : [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

Senior MPLS Expert

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

[email-masked]<mailto:[email-masked]>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 17 Jun 2019 10:27:38 +0200

+1

Cheers, Huub.

On 17/06/2019 02:48, Ryoo, Jeong-dong
wrote:

Loa,

Thank you
for preparing the text.

It looks
great to me, too.

Best
regards,

Jeong-dong

참조 : [email-masked]' <[email-masked]>,
Italo Busi <[email-masked]>,
[email-masked] <[email-masked]>, 류정동
<[email-masked]>

Loa,

Looks great!

One nit:

Regards,

Sasha

Office: +972-39266302

Cell: +972-549266302

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

From: Loa Andersson

To: Alexander Vainshtein ;
Italo Busi
; [email-masked]; Ryoo, Jeong-dong

Cc: [email-masked]'

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

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

8227)

Huawei

> This e-mail and its attachments contain
confidential information from

> ;
Italo Busi

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

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

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

>> *참조**:
[email-masked] '

>> ,
[email-masked]

>> ,
류정동

*제목**: *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.

2c,

Office:
+972-39266302

Cell:
+972-549266302

Email:

*From:* Italo
Busi

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

>> *To:*
Alexander
Vainshtein

>> ;
Ryoo,
Jeong-dong

>> *Cc:*
[email-masked]
'

>> ;
[email-masked]

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

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 Busi***

Huawei

Technologies Co., Ltd.

Tel : +39 345 4721946

Email :
[email-masked]

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

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

>> *To:*
Ryoo,
Jeong-dong >

>> *Cc:*
[email-masked]
'

"">>>
>;
[email-masked]

>> ;
Italo Busi
"">>>

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

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,

Office:
+972-39266302

Cell:
+972-549266302

Email:

*From:* Ryoo,
Jeong-dong >

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

>> *To:*
Alexander
Vainshtein
"">>>
>;
[email-masked]

>> ;
Italo Busi
"">>>

>> *Cc:*
[email-masked]
'

"">>>

*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"

>> *보낸
날짜**:
*2019-06-13
19:03:24 (
+09:00 ) *받는
사람**: *류정동

"">>>
>,
Italo Busi
"">>>

*참조**:
[email-masked]
'

"">>>

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

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,

Office:
+972-39266302

Cell:
+972-549266302

Email:

*From:* Ryoo,
Jeong-dong >

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

Vainshtein
"">>>
>;
Italo Busi

>> *Cc:*
[email-masked]
'

"">>>

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

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?

regards,

Jeong-dong

>> *보낸
사람**: *"Huub
van Helvoort"

"">>>
*보낸 날짜**:
*2019-06-13
17:57:15 (

+09:00 ) *받는
사람**: *류정동 >,

Alexander
Vainshtein
"">>>
>,
Italo Busi

*참조**:
[email-masked]
'

"">>>

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

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

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,

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"

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

*참조**:
[email-masked]
'

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

Italo,

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

on behalf of
Italo Busi

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

*To:*
[email-masked]

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

MPLS WG,

have read the
ITU-T LS 1609

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 *

Tel : +39 345 4721946

Email :
[email-masked]

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.

______

______

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

______

> 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:
[email-masked]

Senior MPLS
Expert

Bronze Dragon
Consulting
phone: +46 739
81 21 64

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: "Weiqiang Cheng" <[email-masked]>
Date: Mon, 17 Jun 2019 16:43:04 +0800

+1 Support！

B.R.
Weiqiang Cheng

-----邮件原件-----
发件人: mpls [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2019年6月16日 11:03
收件人: Alexander Vainshtein; Italo Busi; [email-masked]; Ryoo, Jeong-dong
抄送: [email-masked]'
主题: Re: [mpls] ITU-T LS on MRPS (RFC 8227)

Working Group,

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

Hiroshi Otha, SG15

/Loa
MPLS wg co-chair

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

Comments???

/Loa

--

---

From: Italo Busi <[email-masked]>
Date: Mon, 17 Jun 2019 09:43:34 +0000

+1 (including Sasha’s proposed changes)

Italo

Italo Busi

From: Huub van Helvoort [mailto:[email-masked]]
Sent: lunedì 17 giugno 2019 10:28
To: Ryoo, Jeong-dong <[email-masked]>; Alexander Vainshtein <[email-masked]>; Loa Andersson <[email-masked]>
Cc: [email-masked]' <[email-masked]>; Italo Busi <[email-masked]>
Subject: Re: [mpls] ITU-T LS on MRPS (RFC 8227)

+1

Cheers, Huub.

On 17/06/2019 02:48, Ryoo, Jeong-dong wrote:

Loa,

Best regards,

Jeong-dong

________________________________
보낸 사람 : "Alexander Vainshtein" <[email-masked]><mailto:[email-masked]>
보낸 날짜 : 2019-06-16 16:55:31 ( +09:00 )
받는 사람 : Loa Andersson <[email-masked]><mailto:[email-masked]>
참조 : [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>, Italo Busi <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, 류정동 <[email-masked]><mailto:[email-masked]>
제목 : RE: [mpls] ITU-T LS on MRPS (RFC 8227)

Loa,

Looks great!

One nit:

Regards,

Sasha

Office: +972-39266302

Cell: +972-549266302

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

From: Loa Andersson

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

Cc: [email-masked]<mailto:[email-masked]>'

Working Group,

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

Hiroshi Otha, SG15

/Loa

MPLS wg co-chair

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

Comments???

/Loa

> Cc: [email-masked]<mailto:[email-masked]>'

> *Cc:* [email-masked]<mailto:[email-masked]>'

>> *참조**: [email-masked]<mailto:[email-masked]> '

>> , [email-masked]<mailto:[email-masked]>

>> *Cc:* [email-masked]<mailto:[email-masked]> '

>> ; [email-masked]<mailto:[email-masked]>

>> *Cc:* [email-masked]<mailto:[email-masked]> '

  "">>> >; [email-masked]<mailto:[email-masked]>

  "">>> >

>> *To:* Alexander Vainshtein

  "">>> >; [email-masked]<mailto:[email-masked]>

  "">>> >

>> *Cc:* [email-masked]<mailto:[email-masked]> '

  "">>> >

>> <[email-masked]

>> >, [email-masked]<mailto:[email-masked]>

  "">>> >, Italo Busi

  "">>> >

>> *참조**: [email-masked]<mailto:[email-masked]> '

  "">>> >

>> *To:* [email-masked]<mailto:[email-masked]> ; Alexander

  "">>> >; Italo Busi

>> *Cc:* [email-masked]<mailto:[email-masked]> '

  "">>> >

  "">>> >, Italo Busi

>> *참조**: [email-masked]<mailto:[email-masked]> '

  "">>> >

>>> *참조**: [email-masked]<mailto:[email-masked]> '

>>> *To:* [email-masked]<mailto:[email-masked]>

--

Senior MPLS Expert

and all copies thereof.

</[email-masked]

--