Hi Roman, Thanks for your comments. Few thoughts...
On Thu, Sep 19, 2019 at 2:31 AM Roman Danyliw via Datatracker <[email protected]> wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-pce-stateful-path-protection-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-path-protection/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** Section 3.2. It took me a bit to understand that the Path Protection > Association TLV goes in an ASSOCIATION Object per Section 6 of > [I-D.ietf-pce-association-group]. On initial reading of “[t]he Path > Protection > Association TLV is an optional TLV for use with the Path Protection > Association > Type” this relationship wasn’t clear. I’d recommend an editorial update to > make it clearer. I believe this is related Ben Kaduk’s DISCUSS #5 (which I > support). > This is updated to "The Path Protection Association TLV is an optional TLV for use in the ASSOCIATION Object with the Path Protection Association Type." > ** Section 3.2 The protection type field specifies the protection type of the > LSP. Section 1 notes that “one working LSP [can be associated with] one or > more protection LSPs using the generic association mechanism.” Assuming a > case > were multiple protection LSPs are specified, is it valid for the protections > type to be different? > An explicit error text has been added to make sure LSPs within the association group has the same Protection Type. > ** Section 4.5. For clarity, I would recommend being precise with the exact > code point names when discussing conflicting combinations of protection types. > For example, s/1+1 or 1:N/1+1 (i.e., protection type=0x08 or 0x10) or 1:N > (i.e., protection type = 0x04) with N=1 per <insert IANA registry name>/ > Based on Barry's comment this was simplified and now we have just two case 1+1 and 1:N. The protection type values could be added in brackets. > Baring these combinations, are other any other remaining combinations of > protection types legal given different protection LSPs in the same PPAG (e.g., > 0x1 + 0x2)? > As per RFC 4872, all "other" values are reserved. As per Ben's comment, this was added - "Any type already defined or that could be defined in the future for use in the RSVP-TE PROTECTION object is acceptable in this TLV unless explicitly stated otherwise." > ** Editorial Nits: > -- Section 1. s/effect/affect/ > > -- Section 1. Per “When the working LSPs are computed and controlled by the > PCE, there is benefit in a mode of operation where protection LSPs are as > well”, I couldn’t parse the second clause. > > Thanks! Dhruv _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
