Eric, Thanks for this. It is very much needed.
About this: "It might also be worth thinking about whether the interpretation of the flags octet should be dependent on the type of route to which the PMSI Tunnel attribute is attached. However, that complication is not currently suggested in the draft." As you say, given the small number of possible allocations I think we should make the allocation specific to the type of route and Tunnel Type. This is what we added in draft-rabadan-bess-evpn-optimized-ir: "The definition of the "Flags" octect is specific to PTAs with Tunnel Types IR (0x06) and AR (TBD). The use of the described flags for other Tunnel Types is out of the scope of this document." Thanks. Jorge -----Original Message----- From: Eric C Rosen <[email protected]> Date: Wednesday, February 11, 2015 at 12:27 PM To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [bess] draft-rosen-bess-pta-flags >The PMSI Tunnel attribute defined in RFC6514 contains a "flags" octet. >RFC 6514 only defines a single one-bit flag, "Leaf Information >Required". However, the next revision of >draft-dolganow-l3vpn-mvpn-expl-track is probably going to specify the >use of a second bit from the flags octet. And >draft-rabadan-bess-evpn-optimized-ir specifies the use of 4 bits from >the flags octet. Since this particular octet only contains eight bits, >it is probably a good idea to have an IANA registry for it, to minimize >the chance that two different drafts will try to allocate the same bit >for different purposes. > >Thus the trivial draft draft-rosen-bess-pta-flags, which, if progressed >to RFC, would establish this registry. > >Given the small number of possible allocations, the proposed >registration procedure is "Standards Action", which automatically >includes the possibility of "early allocation". > >It might also be worth thinking about whether the interpretation of the >flags octet should be dependent on the type of route to which the PMSI >Tunnel attribute is attached. However, that complication is not >currently suggested in the draft. > >Comments? > >_______________________________________________ >BESS mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
