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

["weiqiang cheng" <[e-mail]>]

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:[e-mail]] 
Sent: Friday, July 17, 2015 11:38 PM
To: Yimin Shen; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

 

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. 

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

 

-          More detail is needed for “ring map”.

-           

[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

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

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

 

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:[e-mail]] On Behalf Of Yimin Shen
Sent: Monday, July 13, 2015 12:44 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

 

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:[e-mail]] 
Sent: Sunday, July 12, 2015 7:01 AM
To: Yimin Shen; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

 

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:

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.

[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

 

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