Subject: Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

From: Yimin Shen <[email-masked]>
Date: Fri, 10 Jul 2015 01:37:22 +0000

Dear authors, chairs, and WG

I've been asked by the WG chairs to review draft-cheng-mpls-tp-shared-ring-protection-05 for WG adoption. Overall, I think the draft is trying to address a valid MPLS-TP scenario by using a promising solution. However, I have the following comments and questions  for sections 1 to 4, which I would like to request the authors to answer and clarify.

[1]     Section 2.1 - Recovery of multiple failures
-       This is misleading to me. The draft seems to only be able to handle a single failure per ring, rather than multiple failures per ring. This may need some clarification.

[2]     I'd like to suggest to change term "exit node" to "egress node".

[3]     Section 4.1 - The ring tunnel layer.

-       Given a ring of N nodes, this layer would consist of 4xN ring tunnels. The draft is a little light on the provisioning and management aspects of this layer, while pushing a lot of complexity to this layer.
-       Each node is traversed by many tunnels. How does it know whether a tunnel is working or protecting,  and whether a tunnel is CW or AW ? How does it associate a working tunnel with a protecting tunnel (to the same egress node, but opposite in direction) ?
-       When an ingress node needs a working tunnel to a particular egress node, how does choose between the CW  tunnel and the AW tunnel, especially when one is significantly longer  (i.e. of higher cost) than the other ?

[4]     The draft describes 4 tunnels (CW, AW, CP, AP) per egress node ? Is it possible to use only 2 tunnels (i.e. CW and AW) and have them protect each other ?

[5]     Section 4.3.2 -- Short wrapping vs. "traditional wrapping"

-       Does "traditional wrapping" refer to the scenario in section 4.3.1 ?
-       The 4.3.2 mode seems superior to the 4.3.1 mode in all aspects. If so, would there be any value to keep 4.3.1 mode.
-       In 4.3.2 mode, CW tunnel ==CP tunnel and AW tunnel == AP tunnel in path topology, correct ? If so, you could reduce the number of tunnels per egress node from 4 to 2 (as comment [4] above), correct ?

[6]     Section 4.3.3

-       This is equivalent to "global repair" in MPLS. However, why does the ingress node switch traffic from CW tunnel to AP tunnel instead of AW tunnel ? A working tunnel should be "better" than a protecting tunnel to permanently carry traffic.

[7]     Section 4.4

-       I'm not sure how label swap would work on an interconnection node, as the draft describes it. In Fig-12, in normal state, F receives a packet from ring-1; The top label X is a tunnel to the node group; The next label Y is the service LSP. So, F pops label X, and " the label used for working ring tunnel R2cW_I will be pushed based on the inner label" (i.e. label Y). How could F have the knowledge about the service LSP, its label Y, and its egress node, etc ?
-       I may have more questions to follow after the above...

Regards,

Yimin Shen
Juniper Networks

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 12 Jul 2015 13:00:34 +0200

Hello Yimin,

Thank you for your review.

Here is our response: in-line [Huub] on behalf of the authors.

Best regards. Huub.

======

On 10-07-15 03:37, Yimin Shen wrote:

I’ve been asked by the WG chairs to review
draft-cheng-mpls-tp-shared-ring-protection-05 for WG
adoption. Overall, I think the draft is trying to address
a valid MPLS-TP scenario by using a promising solution.
However, I have the following comments and questions  for
sections 1 to 4, which I would like to request the authors
to answer and clarify.

Section 2.1 – Recovery of multiple failures

This is misleading to me. The draft seems to only be
able to handle a single failure per ring, rather than
multiple failures per ring. This may need some
clarification.

[Huub] Multiple failures means
that more than one link or node in the ring can fail.
Protection can still be performed

in the "islands" created in this way. A node failure is in
fact the same as adjacent link failures.

We can provide more clarification.

I’d like to suggest to change term “exit node” to
“egress node”.

[Huub] OK.

Section 4.1 - The ring tunnel layer.

Given a ring of N nodes, this layer would consist of
4xN ring tunnels. The draft is a little light on the
provisioning and management aspects of this layer, while
pushing a lot of complexity to this layer.

[Huub] clarifying text can be
added. We can add a section describing provisioning the
ring-nodes.

Each node is traversed by many tunnels. How does it
know whether a tunnel is working or protecting,  and
whether a tunnel is CW or AW ? How does it associate a
working tunnel with a protecting tunnel (to the same
egress node, but opposite in direction) ?

[Huub] each node knows this
because of the ring-map which contains this information.

When an ingress node needs a working tunnel to a
particular egress node, how does choose between the CW
tunnel and the AW tunnel, especially when one is
significantly longer  (i.e. of higher cost) than the
other ?

[Huub] from the ring-map the
ingress node knows what the shortest path is and then decides
to take the CW or the AW tunnel.

The draft describes 4 tunnels (CW, AW, CP, AP) per
egress node ? Is it possible to use only 2 tunnels (i.e.
CW and AW) and have them protect each other ?

[Huub] mixing working and
protecting traffic in a single tunnel would make the RPS
protocol more complex.

An egress node cannot make the distinction.

Section 4.3.2 -- Short wrapping vs. “traditional
wrapping”

Does “traditional wrapping” refer to the scenario in
section 4.3.1 ?

[Huub] No it doesn't, section
4.3.1 explains wrapping for link failure and node failure.

[Huub] the description of traditional wrapping is in the first
paragraph of section 4.3.2, more clarification can be added.

The 4.3.2 mode seems superior to the 4.3.1 mode in all
aspects. If so, would there be any value to keep 4.3.1
mode.

[Huub] 4.3.1 explains wrapping
methodology, its application is described in 4.3.2.

In 4.3.2 mode, CW tunnel ==CP tunnel and AW tunnel ==
AP tunnel in path topology, correct ? If so, you could
reduce the number of tunnels per egress node from 4 to 2
(as comment [4] above), correct ?

[Huub] No, not correct. During
a protection switch CW tunnel ==> AP tunnel and AW tunnel
==> CP tunnel.

Section 4.3.3

This is equivalent to “global repair” in MPLS.
However, why does the ingress node switch traffic from
CW tunnel to AP tunnel instead of AW tunnel ? A working
tunnel should be “better” than a protecting tunnel to
permanently carry traffic.

[Huub] to operate properly
ring protection switching has to be revertive, after repair
the traffic should be switched back to working (shortest path)

Section 4.4

I’m not sure how label swap would work on an
interconnection node, as the draft describes it. In
Fig-12, in normal state, F receives a packet from
ring-1; The top label X is a tunnel to the node group;
The next label Y is the service LSP. So, F pops label X,
and “ the label used for working ring tunnel R2cW_I will
be pushed based on the inner label” (i.e. label Y). How
could F have the knowledge about the service LSP, its
label Y, and its egress node, etc ?

[Huub] the ring-map has to
take care of this.

I may have more questions to follow after the above…

Regards,

Yimin Shen

Juniper Networks

--
*****************************************************************
请记住，你是独一无二的，就像其他每一个人一样

---

From: Yimin Shen <[email-masked]>
Date: Mon, 13 Jul 2015 16:43:49 +0000

Hi Huub,

Thanks for the response.

Yes, the ring tunnel layer should deserve a greater level of detail in this draft.

Regarding the “ring-map”… You mentioned it in answering  a few of my top questions, but didn’t elaborate to support your anwers. IMO, the ring map is an important piece of your solution as well, and should not be pushed out of scope (below). I’d like to suggest to decribe what information it contains, how it is built, how  the information is distributed and synchronized between nodes, etc.

“Each node SHOULD have a ring map containing information about the sequence of the nodes around the ring.  The method of configuring the nodes with the ring maps is out of scope of this document.”

The entire section 4.4 still remains as a problem for me. IMO, the ingress node and the egress node of a service LSP has a forwarding adjacency at the service LSP level, across the entire ring (or inter-connected rings). The LSP’s label should be transparent to intermediate ring nodes, and no intermediate ring nodes should perform forwarding based this label. Does this match the goals/requirements of this draft? There would be some problems if you want an intermediate ring node (ring interconnection node in this case) to understand a service LSP label. Also, I’m not sure how the ring map could help in this case. Therefore, until I see some clarification, I still don’t understand how section 4.4 would work in both normal forwarding and protection mode.

Thanks,

/Yimin

From: Huub van Helvoort [mailto:[email-masked]]
Sent: Sunday, July 12, 2015 7:01 AM
To: Yimin Shen; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

Hello Yimin,

Best regards. Huub.

======

I’ve been asked by the WG chairs to review draft-cheng-mpls-tp-shared-ring-protection-05 for WG adoption. Overall, I think the draft is trying to address a valid MPLS-TP scenario by using a promising solution. However, I have the following comments and questions  for sections 1 to 4, which I would like to request the authors to answer and clarify.

1.       Section 2.1 – Recovery of multiple failures
·         This is misleading to me. The draft seems to only be able to handle a single failure per ring, rather than multiple failures per ring. This may need some clarification.
[Huub] Multiple failures means that more than one link or node in the ring can fail. Protection can still be performed
in the "islands" created in this way. A node failure is in fact the same as adjacent link failures.
We can provide more clarification.

2.       I’d like to suggest to change term “exit node” to “egress node”.
[Huub] OK.

3.       Section 4.1 - The ring tunnel layer.

·         Given a ring of N nodes, this layer would consist of 4xN ring tunnels. The draft is a little light on the provisioning and management aspects of this layer, while pushing a lot of complexity to this layer.
[Huub] clarifying text can be added. We can add a section describing provisioning the ring-nodes.

·         Each node is traversed by many tunnels. How does it know whether a tunnel is working or protecting,  and whether a tunnel is CW or AW ? How does it associate a working tunnel with a protecting tunnel (to the same egress node, but opposite in direction) ?
[Huub] each node knows this because of the ring-map which contains this information.

·         When an ingress node needs a working tunnel to a particular egress node, how does choose between the CW  tunnel and the AW tunnel, especially when one is significantly longer  (i.e. of higher cost) than the other ?
[Huub] from the ring-map the ingress node knows what the shortest path is and then decides to take the CW or the AW tunnel.

4.       The draft describes 4 tunnels (CW, AW, CP, AP) per egress node ? Is it possible to use only 2 tunnels (i.e. CW and AW) and have them protect each other ?
[Huub] mixing working and protecting traffic in a single tunnel would make the RPS protocol more complex.
An egress node cannot make the distinction.

5.       Section 4.3.2 -- Short wrapping vs. “traditional wrapping”

·         Does “traditional wrapping” refer to the scenario in section 4.3.1 ?
[Huub] No it doesn't, section 4.3.1 explains wrapping for link failure and node failure.
[Huub] the description of traditional wrapping is in the first paragraph of section 4.3.2, more clarification can be added.

·         The 4.3.2 mode seems superior to the 4.3.1 mode in all aspects. If so, would there be any value to keep 4.3.1 mode.
[Huub] 4.3.1 explains wrapping methodology, its application is described in 4.3.2.

·         In 4.3.2 mode, CW tunnel ==CP tunnel and AW tunnel == AP tunnel in path topology, correct ? If so, you could reduce the number of tunnels per egress node from 4 to 2 (as comment [4] above), correct ?
[Huub] No, not correct. During a protection switch CW tunnel ==> AP tunnel and AW tunnel ==> CP tunnel.

6.       Section 4.3.3

·         This is equivalent to “global repair” in MPLS. However, why does the ingress node switch traffic from CW tunnel to AP tunnel instead of AW tunnel ? A working tunnel should be “better” than a protecting tunnel to permanently carry traffic.
[Huub] to operate properly ring protection switching has to be revertive, after repair the traffic should be switched back to working (shortest path)

7.       Section 4.4

·         I’m not sure how label swap would work on an interconnection node, as the draft describes it. In Fig-12, in normal state, F receives a packet from ring-1; The top label X is a tunnel to the node group; The next label Y is the service LSP. So, F pops label X, and “ the label used for working ring tunnel R2cW_I will be pushed based on the inner label” (i.e. label Y). How could F have the knowledge about the service LSP, its label Y, and its egress node, etc ?
[Huub] the ring-map has to take care of this.

·         I may have more questions to follow after the above…

Regards,

Yimin Shen
Juniper Networks

--

              请记住，你是独一无二的，就像其他每一个人一样

---

From: Yimin Shen <[email-masked]>
Date: Fri, 17 Jul 2015 15:37:58 +0000

Dear authors, chairs,

To summarize, I think the draft is trying to address a valid use case with a reasonable approach, but it is not ready for WG adoption at this point due to the following issues that I’ve communicated earlier.

-          More detail is needed for “ring tunnel layer” on provisioning and maintaining ring tunnels.

-          More detail is needed for “ring map”.

-          The draft currently covers only 1:1 protection scenario, and hence it requires 2 working tunnels + 2 protection tunnels per egress node. However, on a ring topology, people may naturally also ask for 1+1 protection (RFC 5654 section 2.5.6), which would need only half number of tunnels compared with 1:1 protection. Therefore, it will be very useful if the draft can also discuss 1+1 protection (or why it doesn’t work). In particular, I’d like to mention draft-kompella-mpls-rmr-00 which deals with similar ring topology for MPLS.

-          Section 4.4 (i.e. interconnected ring scenario) does not work.

The above comments are concerned with section 1 to 4 which describe the theory of operation. I think they need to be addressed before further review on other sections.

Thanks,

/Yimin

From: mpls [mailto:[email-masked]] On Behalf Of Yimin Shen
Sent: Monday, July 13, 2015 12:44 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

Hi Huub,

Thanks for the response.

Thanks,

/Yimin

From: Huub van Helvoort [mailto:[email-masked]]
Sent: Sunday, July 12, 2015 7:01 AM
To: Yimin Shen; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

Hello Yimin,

Best regards. Huub.

======

6.       Section 4.3.3

Regards,

Yimin Shen
Juniper Networks

--

              请记住，你是独一无二的，就像其他每一个人一样

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 18 Jul 2015 19:41:04 +0000

Hi Yimin,

Thanks for your comments, please see my replies inlined with [Jie].

________________________________
From: mpls [[email-masked]] on behalf of Yimin Shen [[email-masked]]
Sent: Tuesday, July 14, 2015 0:43
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

Hi Huub,

Thanks for the response.

[Jie] As shown in figure 8 and 9 of the document, the ring-map includes the ring topology and the status of the ring links.  The ring topology is configured via NMS, the state of each ring link is monitored by OAM. When there is some failure detected via OAM, such failure information is advertised via the RPS protocol. This way, each node gets the ring-map information.

[Jie] Agree that the interconnected ring operation needs more clarification . Actually on the intersection node of two rings, the inner label (LSP label) also needs to be swapped, which explains why the intersection node need to check the inner label. This is not explicitly specified in the current draft, which may cause some confusion. Some clarification will be added in next revision.

Best regards,
Jie

Thanks,

/Yimin

Hello Yimin,

Best regards. Huub.

======

*         This is misleading to me. The draft seems to only be able to handle a single failure per ring, rather than multiple failures per ring. This may need some clarification.

*         Given a ring of N nodes, this layer would consist of 4xN ring tunnels. The draft is a little light on the provisioning and management aspects of this layer, while pushing a lot of complexity to this layer.
[Huub] clarifying text can be added. We can add a section describing provisioning the ring-nodes.

*         Each node is traversed by many tunnels. How does it know whether a tunnel is working or protecting,  and whether a tunnel is CW or AW ? How does it associate a working tunnel with a protecting tunnel (to the same egress node, but opposite in direction) ?
[Huub] each node knows this because of the ring-map which contains this information.

*         When an ingress node needs a working tunnel to a particular egress node, how does choose between the CW  tunnel and the AW tunnel, especially when one is significantly longer  (i.e. of higher cost) than the other ?
[Huub] from the ring-map the ingress node knows what the shortest path is and then decides to take the CW or the AW tunnel.

*         Does “traditional wrapping” refer to the scenario in section 4.3.1 ?
[Huub] No it doesn't, section 4.3.1 explains wrapping for link failure and node failure.
[Huub] the description of traditional wrapping is in the first paragraph of section 4.3.2, more clarification can be added.

*         The 4.3.2 mode seems superior to the 4.3.1 mode in all aspects. If so, would there be any value to keep 4.3.1 mode.
[Huub] 4.3.1 explains wrapping methodology, its application is described in 4.3.2.

*         In 4.3.2 mode, CW tunnel ==CP tunnel and AW tunnel == AP tunnel in path topology, correct ? If so, you could reduce the number of tunnels per egress node from 4 to 2 (as comment [4] above), correct ?
[Huub] No, not correct. During a protection switch CW tunnel ==> AP tunnel and AW tunnel ==> CP tunnel.

6.       Section 4.3.3

*         This is equivalent to “global repair” in MPLS. However, why does the ingress node switch traffic from CW tunnel to AP tunnel instead of AW tunnel ? A working tunnel should be “better” than a protecting tunnel to permanently carry traffic.
[Huub] to operate properly ring protection switching has to be revertive, after repair the traffic should be switched back to working (shortest path)

7.       Section 4.4

*         I’m not sure how label swap would work on an interconnection node, as the draft describes it. In Fig-12, in normal state, F receives a packet from ring-1; The top label X is a tunnel to the node group; The next label Y is the service LSP. So, F pops label X, and “ the label used for working ring tunnel R2cW_I will be pushed based on the inner label” (i.e. label Y). How could F have the knowledge about the service LSP, its label Y, and its egress node, etc ?
[Huub] the ring-map has to take care of this.

*         I may have more questions to follow after the above…
Regards,

Yimin Shen
Juniper Networks

--

              请记住，你是独一无二的，就像其他每一个人一样

---

From: "weiqiang cheng" <[email-masked]>
Date: Sun, 19 Jul 2015 21:10:19 +0800

Hi Yimin, 

Thanks a lot for your comments, please see my replies in-line on behalf of authors.

B.R.

Weiqiang Cheng

From: Yimin Shen [mailto:[email-masked]] 
Sent: Friday, July 17, 2015 11:38 PM
To: Yimin Shen; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

Dear authors, chairs,

[Authors] this was already agreed. I think it is ready for WG adoption, the details are for clarification.

-           

[Authors] this was already agreed. Clarification will be added.

-          The draft currently covers only 1:1 protection scenario, and hence it requires 2 working tunnels + 2 protection tunnels per egress node. 

[Authors] the reason for using 2 W and 2 P tunnels is because the protection is bi-directional the traffic in forward and reverse direction follow the same path.
The choice for 2 W and 2 P is already explained, it reduces the complexity.

However, on a ring topology, people may naturally also ask for 1+1 protection (RFC 5654 section 2.5.6), which would need only half number of tunnels compared with 1:1 protection.

[Authors] rfc5654 section 2.5.6 requires switching time of less than 50 ms for 1+1 and 1:1 ring protection. There is no requirement that it is mandatory to support/develop 1+1. 1+1 is the same as UPSR in SONET, 1:1 is the same as BLSR in SONET. 1:1 is uses the bandwidth in the network much more efficient, and as explained above reduces complexity. For packet based technology, it is not necessary to setup a 1+1 solution.

Therefore, it will be very useful if the draft can also discuss 1+1 protection (or why it doesn’t work).

[Authors] 1+1 is just one other solution, do we need to discuss all possible solutions?
our draft is not a tutorial on ring protection.

In particular, I’d like to mention draft-kompella-mpls-rmr-00 which deals with similar ring topology for MPLS.

[Authors] we are fully aware of that draft, see message:
https://www.ietf.org/mail-archive/web/mpls/current/msg14265.html

[Authors] why does it not work? It has been deployed in operators networks.
[Authors] more details will be added regarding the forwarding in interconnection node. And we also can consider remove the part from the draft and make the part as an independent draft. Is that OK.

 

Thanks,

/Yimin

Hi Huub,

Thanks for the response. 

 

 

Thanks,

/Yimin

Hello Yimin,

Best regards. Huub.

======

[Huub] OK.

6.       Section 4.3.3

7.       Section 4.4

Regards,

Yimin Shen

Juniper Networks