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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Yimin,



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





________________________________
From: mpls [[e-mail]] on behalf of Yimin Shen [[e-mail]]
Sent: Tuesday, July 14, 2015 0:43
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.

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



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

[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


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



--

*****************************************************************

              Çë¼Çס£¬ÄãÊǶÀÒ»ÎÞ¶þµÄ£¬¾ÍÏñÆäËûÿһ¸öÈËÒ»Ñù