Working Group,
I agree that this is important and well executed - please let us
progress this draft in a timely fashion.
Also, I can't help wondering if there are some general lessons to draw
from this, e.g. make flag fields larger than what you imagine will be
ever used and in flag fields always reserve an escape bit.
/Loa
PS
Note the difference between a "reerved" bit and an "unassigned" bit.
On 2015-08-06 18:07, Rabadan, Jorge (Jorge) wrote:
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 <[email protected]> on behalf of Eric C Rosen
<[email protected]>
Date: Thursday, August 6, 2015 at 8:17 AM
To: "[email protected]" <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
