Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

[Robert Raszuk <[e-mail]>]

Jared,


> > So I support both yourself and Jeff to have two octet type in common
> header and have few more bits for flags. I was also thinking about adding
> versioning to the common header but I have not even got there with current
> private dialogue with Jakob.
>
> Could you perhaps have some of that on-list?  I believe Jakob e-mailed his
> proposal for that header, I think constructive feedback would be welcome.
>

​Oh sorry. Jeff and I pointed already twice to it in the public WG
document. But I am more then happy to copy and paste it to the list as you
wish :) The C flag is agreed  to be removed so do not consider that one as
a problem.

Type and flags fields below are shorter then they should be as were really
trying to get consensus with large folks.


3.1 <https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-03#section-3.1>.
Wide BGP Community Attribute Common Container Header

   Containers always start with the following common header:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |  Flags  |R|C|T|            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Context AS Number                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This document defines Types 1,2,3 and 4.  See the Section 14
<https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-03#section-14>
for
   information on additional type registration policies.

   +------+-------+----------------------------------------------------+
   | Bit  | Value | Meaning                                            |
   +------+-------+----------------------------------------------------+
   |  0   |   0   | Transitive across AS boundary                      |
   |      |   1   | Not Transitive across AS boundary                  |
   |  1   |   0   | Transitive across confederation boundaries         |
   |      |   1   | Not transitive across confederation boundaries     |
   |  2   |   0   | Local community value.                             |
   |      |   1   | IANA Registered community type or value.           |
   | 3..7 |   -   | RESERVED - MUST be zero when sent and ignored upon |
   |      |       | receipt.                                           |
   +------+-------+----------------------------------------------------+

   Flags are defined globally, to apply to all wide community container
                                  types.

                              Table 1: Flags

   Bit 0 (aka T bit) Transitivity bit: Value 0: The communities in the
   container are transitive across all ASes.  Value 1: The communities
   in the container are transitive across AS boundaries, but not across
   an administration boundary.  An administration in this sense is an
   arbitrary set of connected ASes, possibly owned by a single
   administration.  How such an administration boundary is determined is
   out of scope of this document.
Raszuk, et al.            Expires March 6, 2017                 [Page 6]

------------------------------

  <https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-03#page-7>Internet-Draft
           wide-bgp-communities            September 2016


   Bit 1 (aka C bit) Confederation bit: Is used to manage the
   propagation scope of a given Wide BGP Community across confederation
   boundaries.  When not set (value of 0) indicates that communities in
   a given container are transitive across confederation boundary.  When
   set (value 1) communities are not transitive across confederation
   sub-AS boundary.

   Bit 2 (aka R bit) Registered bit: When set (value 1) indicates that
   the given container carries a Wide BGP Community which is registered
   with IANA.  When not set (value 0) it indicates that community value
   which follows is locally assigned with a local only meaning and local
   behaviour.

   The Length field represents the total length of a given container in
   octets.

   Context Autonomous System Number: 4 octets

   This identifies the AS that is to interpret the community container.
   For example, an ISP may publish a set of community specifications.  A
   customer of the ISP will use those specifications to formulate the
   communities.  The ISP will read the communities and perform the
   instructions encoded as per the specifications.  The Context ASN is
   the ASN of the ISP.  The ISP is usually directly connected to the
   customer, but if not, then the intervening network has the
   opportunity to pass the routes to the Context ASN if it chooses to do
   so.




There are those of us who care less about the wire format and more about
> the usability/existence in running code.  I’ve got some goals here that I
> think are reasonable and attainable, expect some nudges (or pushes) if
> you’ve chimed in.
>

I am all to help here. You know IETF for me is more of the hobby rather
then day job :)

Cheers,
R.
​