Summary: Needs 7 more YES or NO OBJECTION positions to pass.
Thanks for the work on this. I have a couple of minor substantive comments and a number of editorial ones. Substantive, but minor: — Section 3.1.1 and throughout — Should the “reserved” fields, which say, “Reserved for future use,” also add the customary, “MUST be set to zero and ignored on receipt”? — Section 3.1.2 — The MESSAGE_ID object flags SHOULD be cleared when transmitted by the PLR and ignored when received at the MP. Why SHOULD and not MUST? How do things interoperate properly if this isn’t done, and what reasons might there be for not doing it? Editorial: — Section 1 — Please expand “LER”, “LSP”, and “LSR” on first use. — Section 3 — For example, in the context of GMPLS-controlled LSP(s), the object is used to associate recovery LSPs with the LSP they are protecting. There might be a number agreement problem here: as it’s written, it implies that multiple recovery LSPs might protect a single LSP, and a single ASSOCIATION object is used for all of them. If that’s the case, then no change is needed. But it’s likely that you want to make everything either singular or plural: “the objects are used to associate recovery LSPs with the LSPs they are protecting.” ...or... “the object is used to associate a recovery LSP with the LSP it is protecting.” — Sections 3.2.1 and 3.2.2 — Bypass_Group_Identifier: 32 bits The Bypass_Group_Identifier that is previously signaled by the PLR using the Extended Association object. One or more Bypass_Group_Identifiers MAY be included. 1. I would say “32 bits each”. 2. The definite article (“The Bypass_Group_Identifier”) doesn’t go with the fact that there can be more than one of them. Also “is” doesn’t go with “previously”. So, maybe: NEW Bypass_Group_Identifier: 32 bits each A Bypass_Group_Identifier that was previously signaled by the PLR using the Extended Association object. One or more Bypass_Group_Identifiers MAY be included. END — Section 3.4 — Upon detection of the fault (egress link or node failure) Was there a fault we were talking about? Or should it be “a fault”? — Section 3.4.2 — each protected LSP associated with each Bypass_Group_Identifier, as if it received an individual RSVP Path messages for that LSP. Make it, “as if it had received an individual RSVP Path message”. — Section 5 — When using procedures defined in this document, FRR (or the reroute of protected LSP(s) on to the bypass tunnel) can be activated on per group of protected LSP(s). I can’t parse “can be activated on per group”, and, hence, don’t understand it. Can you fix it?
Thank you for the work put into this document. Please find below a couple of non-blocking COMMENTs (even if non blocking, I would appreciate it if authors sent a response). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 3.1.1 and other places -- Is there any reason why the "Reserved field" does not specify "to be set to 0 when sending and ignored on received" ? -- Section 3.1 -- The flow is a little strange IMHO, there is text at the end of 3.1.2 that probably applies to the whole section 3.1. If this is the case, then may I suggest to have a subsection 3.1.3 ? -- Section 4 -- Is the number "11bbbbbb" be understood as a binary number ? Is "ignoring and passing" the object enough for backward compatibility? I am not an MPLS TE expert at all... but I find this section a little light: I assume that this object must be understand by the remote side of the "FRR tunnel".