Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-shared-ring-protection-05.txt> (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard

From: Italo Busi <[email-masked]>
Date: Thu, 11 May 2017 14:05:42 +0000

I think the draft is ready to be published.

I have recently discussed with some authors of the draft some questions for clarification and it might be worthwhile considering minor text changes proposed below to further improve text clarity.

1) Section 4.3.1.2 and 4.3.2.2

The text describing egress node failures imply that, also in case of wrapping and short-wrapping, the ingress node, when notified (by RPS) about egress node failure, will not send traffic to either the working or the protection tunnel (like it does with steering protection). It might be worthwhile adding some explicit text

OLD TEXT (Section 4.3.1.2)
   In one special case where node D fails, all the ring tunnels with
   node D as egress will become unusable. However, before the failure
   location information is propagated to all the ring nodes, the
   wrapping protection mechanism may cause temporary traffic loop:

NEW TEXT (Section 4.3.1.2)
   In one special case where node D fails, all the ring tunnels with
   node D as egress will become unusable. The ingress node will update its ring map according to received RPS messages and determine that the egress node is not reachable thus it will not send traffic to either the working or the protection tunnel. However, before the failure
   location information is propagated to all the ring nodes, the
   wrapping protection mechanism may cause temporary traffic loop:

OLD TEXT (Section 4.3.2.2)
   <...> When node D
   fails, traffic of LSP1 cannot be protected by any ring tunnels which
   use node D as the egress node.  However, before the failure location
   information is propagated to all the ring nodes using the RPS
   protocol, node C switches all the traffic on the working ring tunnel 
   <...>

NEW TEXT (Section 4.3.2.2)
   <...> When node D
   fails, traffic of LSP1 cannot be protected by any ring tunnels which
   use node D as the egress node. The ingress node will update its ring map according to received RPS messages and determine that the egress node is not reachable thus it will not send traffic to either the working or the protection tunnel. However, before the failure location
   information is propagated to all the ring nodes using the RPS
   protocol, node C switches all the traffic on the working ring tunnel 
   <...>

2)  Section 4.3.2

With short-wrapping the two traffic directions of protected LSPs are no longer co-routed under protection switching conditions. This should be mentioned.

OLD TEXT
   With short wrapping protection, data traffic switching is executed
   only at the node upstream to the failure, and data traffic leaves the
   ring in the protection ring tunnel at the egress node.  This scheme
   can reduce the additional latency and bandwidth consumption when
   traffic is switched to the protection path.

NEW TEXT
   With short wrapping protection, data traffic switching is executed
   only at the node upstream to the failure, and data traffic leaves the
   ring in the protection ring tunnel at the egress node.  This scheme
   can reduce the additional latency and bandwidth consumption when
   traffic is switched to the protection path. However the two directions of a protected bidirectional LSP are no longer co-routed under protection switching conditions.

3) Section 4.3.2

The difference between wrapping and short-wrapping is in the way protection tunnel is configured.

OLD TEXT
   In the traditional wrapping solution, in normal state the protection
   ring tunnel is a closed ring, while in the short wrapping solution,
   the protection ring tunnel is ended at the egress node, which is
   similar to the working ring tunnel.

NEW TEXT
   In the traditional wrapping solution, the protection
   ring tunnel is configured as a closed ring, while in the short wrapping solution,
   the protection ring tunnel is configured as ended at the egress node, which is
   similar to the working ring tunnel.

Thanks, Italo

-----Original Message-----
From: The IESG [mailto:[email-masked]] 
Sent: sabato 29 aprile 2017 00:00
To: IETF-Announce
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Eric Gray; [email-masked]
Subject: Last Call: <draft-ietf-mpls-tp-shared-ring-protection-05.txt> (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Shared-Ring protection (MSRP) mechanism for ring topology'
  <draft-ietf-mpls-tp-shared-ring-protection-05.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked] mailing lists by 2017-05-12. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

   This document describes requirements, architecture and solutions for
   MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point-
   to-point (P2P) services.  The MSRP mechanism is described to meet the
   ring protection requirements as described in RFC 5654.  This document
   defines the Ring Protection Switch (RPS) Protocol that is used to
   coordinate the protection behavior of the nodes on MPLS ring.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2680/
   https://datatracker.ietf.org/ipr/2681/
   https://datatracker.ietf.org/ipr/2682/
   https://datatracker.ietf.org/ipr/2683/

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Fri, 12 May 2017 13:06:58 +0800

Hi Italo,
Thank you very much for your detailed review and valuable comments.
We authors will make some modifications based on your comments.

B.R.
Weiqiang Cheng

-----邮件原件-----
发件人: Italo Busi [mailto:[email-masked]] 
发送时间: 2017年5月11日 22:06
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: RE: Last Call: <draft-ietf-mpls-tp-shared-ring-protection-05.txt> (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard

2)  Section 4.3.2

OLD TEXT

NEW TEXT

3) Section 4.3.2

OLD TEXT

NEW TEXT

Thanks, Italo

-----Original Message-----
From: The IESG [mailto:[email-masked]] 
Sent: sabato 29 aprile 2017 00:00
To: IETF-Announce
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Eric Gray; [email-masked]
Subject: Last Call: <draft-ietf-mpls-tp-shared-ring-protection-05.txt> (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard

Abstract

---

From: 정태식 <[email-masked]>
Date: Fri, 12 May 2017 06:18:55 +0000

Dear authors,

I have two comments on this draft.

1) Section 4.4.1 (last two paragraphs above Figure 11)

Following two sentences are duplicated in the last two paragraphs above Figure 11.

Figure 11 shows the topology of single-node interconnected
rings. Node C is the interconnection node between Ring1 and
Ring2.

Proposed change: delete the last paragraph.

2) Section 5.1.4.2 (3rd paragraph from the bottom)

The last two bullet items correspond to conditions which trigger state transition from the Switching state to the Idle state. However, current text above those bullet items is describing adversely.

Proposed change: 

OLD TEXT
In one of the following conditions, transition from the Idle state to
the Switching state MUST be triggered:

NEW TEXT
In one of the following conditions, transition from the Switching state to
the Idle state MUST be triggered:

Best regards,
Taesik

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of The IESG
Sent: Saturday, April 29, 2017 1:00 AM
To: IETF-Announce
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [mpls] Last Call: <draft-ietf-mpls-tp-shared-ring-protection-05.txt> (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard

Abstract

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 12 May 2017 10:45:06 +0200

Hello Taesik,

Thank you very much for reviewing the draft in detail
and for your valid comments.

We, the authors of the draft, will incorporate your comments.

Best regards, Huub.

---------

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