Indeed, thank you Elwyn! And thank you for the changes! jari
On 16 Sep 2015, at 06:40, IJsbrand Wijnands <[email protected]> wrote: > Thanks Elwyn! > > Ice. > >> On 16 Sep 2015, at 15:32, Elwyn Davies <[email protected]> wrote: >> >> Hi Ice. >> >> I had a quick look through the updates in -07 and that has addressed all the >> points below. Definitely good to go now. >> >> Cheers, >> Elwyn >> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please wait for direction from your >>> document shepherd or AD before posting a new version of the draft. >>> >>> For more information, please see the FAQ at >>> >>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> >>> Document: draft-ietf-mpls-mldp-node-protection-06.txt >>> Reviewer: Elwyn Davies >>> Review Date: 2015/09/15 >>> IETF LC End Date: 2015/09/08 >>> IESG Telechat date: 2015/09/17 >>> >>> Summary: Ready for publication on standards track. Thanks for your generous >>> comments on my review and the updated version -06 which fixes almost all of >>> the issues. The nits below are mostly suggestions related to the updated >>> text apart from the last one on s2.3 which got missed. >>> >>> Major issues: >>> None >>> >>> Minor issues: >>> None >>> >>> Nits/editorial comments: >>> s1: The new text referring to the need for capability negotiation is not >>> easy to parse. Suggested alternative: >>> OLD: >>> In order for a node to be protected, the protecterd node, the PLR and >>> the MPT MUST support the procedures as described in this draft. >>> Detecting the protected node, PLR and MPT support these procedures is >>> done using [RFC5561]. >>> NEW: >>> In order to allow a node to be protected against failure, the LSRs providing >>> the PLR and the MPT functionality as well as the protected node MUST >>> support the functionality described in this document. RSVP capability >>> negotiation [RFC5561] is used to signal the availability of the >>> functionality >>> between the participating nodes; these nodes MUST support capability >>> negotiation. >>> END >>> >>> s2, last para: s/This because/This is because/ >>> >>> s2.1, last para; s2.2, last para: s/Procedures how to setup/The procedures >>> for setting up/ >>> >>> s2, s2.2 and s3: s/this draft/this document/ (3 places) [A 4th instance is >>> replaced in the suggested text for s1 above.] >>> >>>>> s2.2: If I understand correctly, the bypass LSPs have to be >>>>> bidirectional (or they could be two unidirectional ones) unlike those in >>>>> s2.1 which will be unidirectional. I think this ought to be mentioned, >>>>> assuming I am right - and presumably one could do a bit of optimisation >>>>> in setup. This has some knock-on effects as regards what happens when >>>>> the node fails. I wonder if there should be some explanation of what >>>>> happens in an extra sub-section in s4 - just that the various LSRs need >>>>> to think about what role they are playing depending on where the incoming >>>>> packets are coming from, I guess. >>>> Ice: Yes, that is a good observation about unidirectional and >>>> bidirectional LSPs. I’ll add a node to make that clear. >>> The fixes for that are fine and helpful IMO. >>>> Since the MPT will receive packets with the MPLS label it originally >>>> expected, it does not really care where the packets are coming from. So >>>> I’m not sure anything else needs to be added here. >>>> >>> Probably right. Actually the fact that the bypass LSPs are bidirectional >>> does sort out the differentiation of roles anyway. Incoming = MPT, Outgoing >>> = PLR. The note could be extended to mention this. >>> >>> s2.3: >>>> Num PLR entry: Element as an unsigned, ***non-zero*** integer followed >>>> by that number of "PLR entry" fields in the format specified >>>> below. >>> Per the discussion of my last call comments, the Num PLR entry can be zero. >>> >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
