Subject: [bess] PMSI Tunnel Attribute Flags

From: Eric C Rosen <[email-masked]>
Date: Thu, 6 Aug 2015 11:17:09 -0400

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?

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 6 Aug 2015 16:07:36 +0000

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-masked]> on behalf of Eric C Rosen
<[email-masked]>
Date: Thursday, August 6, 2015 at 8:17 AM
To: "[email-masked]" <[email-masked]>
Subject: [bess] PMSI Tunnel Attribute Flags

>_______________________________________________
>BESS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bess

---

From: Loa Andersson <[email-masked]>
Date: Fri, 07 Aug 2015 09:54:32 +0200

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.