Hi Dhruv/Pete, Thanks for the review, new version handles the comments.
FYI: New Version: https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-path-protection Diff : https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-path-protection-09 Thanks, Mahendra On Thu, Aug 29, 2019 at 3:47 PM Dhruv Dhody <[email protected]> wrote: > Hi Pete, > > Thanks for your review and nits. Just snipping to two points... > > > OLD > > | PT | Path Protection Association Flags |S|P| > > NEW > > | PT | Unassigned |S|P| > > > > I feel it is important to keep the name "flags" in the figure to match > with the text following the figure. Also this seems to be our usual > practice in past documents as well. We can change to just "flags" if > you would prefer that? > > For context -> > > The format of the Path Protection Association TLV (Figure 1) is as > follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBD2 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PT | Path Protection Association Flags |S|P| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: Path Protection Association TLV format > > Path Protection Association Flags (32 bits) - The following flags are > currently defined - > > Protecting (P): 1 bit - This bit is as defined in Section 14.1 of > [RFC4872] to indicate if the LSP is working or protection LSP. > > Secondary (S): 1 bit - This bit is as defined in Section 14.1 of > [RFC4872] to indicate if the LSP is primary or secondary LSP. The > S flag is ignored if the P flag is not set. > > Protection Type (PT): 6 bits - This field is as defined in > Section 14.1 of [RFC4872] to indicate the LSP protection type in > use. > > Unassigned bits are considered reserved. They MUST be set to 0 on > transmission and MUST be ignored on receipt. > > > > Section 6: > > > > At the top of the section, I suggest putting in the following: > > > > [Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1" > through > > "TBD5" those should be replaced by the values that IANA assigns. Also, > Section > > 4.5 includes several occurrences of the phrase "(Early allocation by > IANA)"; > > please confirm that the value mentioned there is correct and delete that > phrase > > from the document before publication.] > > > > I would suggest the authors to remove the phrase "(Early allocation by > IANA)" in the document now as the referenced draft is in RFC-EDITOR > queue and the early allocation tag is removed in the IANA page - > https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects > > Thanks! > Dhruv >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
