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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
