Hi Eric and Thomas, Thanks for this. This work is important. Although I was still leaning towards a registry per tunnel-type or at least per SAFI (since it would save the use of a new EC) I think at this moment it is even more important to close on this as soon as possible to avoid issues.
My only other comment is that it would seem 'cleaner' to use the most significant bit to indicate the existence of the EC instead of bit 1. If would be good to confirm that the rumor about the use of bit 0 is an existing implementation, in which case I agree it can’t be used. If that is the case, it would be good if the relevant people document that somewhere. We can't break existing implementations, however we don’t want to keep defining bits in additional ECs if there are bits available in the existing PTA flags either. My two cents.. Thanks. Jorge -----Original Message----- From: BESS <bess-boun...@ietf.org> on behalf of Eric C Rosen <ero...@juniper.net> Date: Thursday, August 6, 2015 at 8:17 AM To: "bess@ietf.org" <bess@ietf.org> Subject: [bess] PMSI Tunnel Attribute Flags >Thomas and I have just posted draft-ietf-bess-pta-flags-01. This rev >introduces a new proposal for making the PMSI Tunnel attribute's Flags >Field extensible. It defines a new opaque extended community that can >be used to carry up to 48 new flags, and uses one of the bits in the >existing Flags Field to mean that additional flags are set in the >extended community. The draft also establishes an IANA registry for the >existing Flags Field and for the flags in the extended community. > >The draft registers two bits in the existing Flags Field; > >- Bit 7 (least significant): the LIR bit defined in RFC6514 > >- Bit 1: Extension bit. If this bit is set, there are additional flags >in the new extended community. > >Although not mentioned in the draft, bits 3-6 are given defined uses in >draft-rabadan-bess-evpn-optimized-ir. >Draft-dolganow-bess-mvpn-expl-track defines another bit, LIR-pF, for >which we will likely request Bit 2. I have heard a rumor that Bit 0 >(most significant) is also in use, though not documented in an >internet-draft. So all 8 bits are now used. If the WG agrees to >advance draft-ietf-bess, additional flags would have to come from the >new opaque extended community. > >This proposal seems like a good way to preserve the existing uses of the >flags field, to discourage "squatting", and to allow additional flags to >be defined. > >The proposed registration policy for both the existing flags field and >for flags in the new extended community is "Standards Action", which >implies the possibilty of "early allocation". > >Comments? > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
