Huub, I have minor comments on some of your proposed changes below.
From: Gen-art [mailto:[email protected]] On Behalf Of Huub van Helvoort Sent: den 24 maj 2017 00:36 To: Christer Holmberg <[email protected]>; [email protected]; [email protected] Subject: Re: [Gen-art] Gen-ART review of draft-ietf-mpls-tp-shared-ring-protection-05.txt Hej Christer, As I mentioned in my previous email I have discussed your questions and comments with the co-authors of this draft. Please find our response in line [Huub]. We hope that we have provided the required clarification. Best regards, Huub. --- Between ourselves: here is my suggested reply to Christer in line [Huub] On 17/05/2017 14:49, Christer Holmberg wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> Document: draft-ietf-mpls-tp-shared-ring-protection-05.txt Reviewer: Christer Holmberg Review Date: 17 May 2017 IETF LC End Date: 12 May 2017 IETF Telechat Date: N/A Summary: The document is well written, but there are a few issues I¹d like the authors to address. Major Issues: None Minor Issues: ------------- Section 4.1.3: The text says: "When an MPLS-TP transport path, such as an LSP, enters the ring,в The ³such as an LSP² statement is confusing. Could there be something else than LSP? [Huub] the MPLS-TP transport path is an LSP. Change the text to: "when an MPLS-TP transport path, i.e. an LSP, enters..." Section 4.4: Would it be useful to say that, for a given ring, an interconnect node acts as an egress node for that ring, meaning that all LSPs using the interconnect node will use the same tunnel within the ring? [Huub] indeed useful. Change text to: "For a given ring, an interconnect node acts as an egress node for that ring, meaning that all LSPs using the interconnect node will use the same tunnel within the ring. I am not sure what text this changes. Are you proposing to add this text? If so, it is misleading without context. As I understand rings, all traffic going through the interconnect node is not necessarily using it as an egress to the interconnected ring. In this statement, you imply either that all traffic going through a ring node that is also the “interconnected node” is traffic destined to cross from one ring to another, or that an “interconnected node” comprises that part of a ring node for which this is true. I suspect you need to add “as an egress from one specific ring to another” after “using the interconnect node.” Some care needs to be used in wording this as the fact that a ring node provides an interconnect between two rings does not mean the same node cannot also provide at least one separate interconnect involving an additional ring. That is the same node might provide an interconnect between Ring A and Ring B, and between Ring A and Ring C. If this (or anything much like it) is the case, then I assume that the traffic for the first interconnect would be on one tunnel while the traffic for the second would be on another. Section 4.4.2: The text says: "The service LSPs that traverse the interconnected rings use separate ring tunnels on each ring, and the LSPs on different rings are stitched by the interconnection node.² It¹s unclear to me what ³separate tunnels² mean. As there are two different rings, there will obviously be separate tunnels. Or, do you mean to say something else? [Huub] indeed separate tunnels are used. Change the text to: "The service LSPs that traverse the interconnected rings use a ring tunnels in each ring, and the traversing LSPs are stitched in the interconnection node." I had previously read this text to have more meaning than remains in your suggested change. While it is obvious that the tunnels used in each ring are separate, I had read this to also mean that these service LSPs use a separate tunnel in a ring to allow for them to traverse from ring to ring at the interconnection node. That information may be considerably less obvious than that separate tunnels are used in separate rings. Section 5.1: The first sentence says: "The MSRP protection operation MUST be controlled with the help of the Ring Protection Switch protocol (RPS).² I think it would be good to have a few introduction sentences of the RPS protocol, before mandating the usage of it. [Huub] Understood. A short introduction of the purpose of the RPS protocol can be added. (we will try to have text ready before the IESG telechat) The text says: "The RPS protocol MUST carry the ring status information and RPS requests, either automatically initiated or externally initiated, between the ring nodes.² This text is a little confusing. Is this a protocol requirement, or a protocol usage requirement? Similar to my previous comments, a generic introduction to the protocol, and the requirements it has to fulfil, would be useful. In addition, that text should reference to section 5.3 for the justification of defining a new protocol in the first place. [Huub] text can be added for clarification. Change the text as follows: "The RPS protocol MUST distribute the ring status information and RPS requests to all the ring nodes. Changes in the ring status information and RPS requests can be initiated automatically based on link status or caused by external commands." Editorial Issues: ----------------- Generic: In the document you use both ³ring node² and ³ring-node² terminology. Unless there is a reason for that, please use consistent terminology. [Huub] can be fixed as suggested. Section 1: The text says: "As described in [RFC5654], MPLS-TP requirements, section 2.5.6.1" Šand later: "described in section 2.5.6.1 of [RFC5654]." Please use consistent wording. [Huub] can be fixed as suggested. Section 3: I like the way the section describes how the requirements have been met. As I assume most of the solutions are described more in detail elsewhere in the document, I wonder whether it would be possible to add references? Something like: "For detailed information, see section x.x.x.x." [Huub] can be fixed as suggested. Section 4.1: The text says: "A port can carry multiple ring tunnels, and a ring tunnel can carry multiple LSPs." I think it would be good to add a picture showing a port carrying multiple ring tunnels, carrying multiple LSPs. [Huub] we will add a figure showing how a port carries LSPs and ring tunnels. (we will try to have the figure ready before the IESG telechat) The figure will be based on the following: Because the LSPs on an ingress port can egress at different egress ports/nodes a port can carry multiple ring tunnels. Because separate LPSs on a ingress port can egress on the same egress port/node they are using the same ring tunnel. Because an egress port can terminate ring tunnels from different ingress ports/nodes a port can carry multiple ring tunnels. Because a ring tunnel can carry several LSPs, an egress port can carry several LSPs in the same ring tunnel. --------- Best regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else...
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
