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

["Jakob Heitz (jheitz)" <[e-mail]>]

Robert,

It looks like you don't agree to the common header, so I'll go without. My current code does not have it anyway.

Thanks,
Jakob.


On Sep 9, 2016, at 12:40 PM, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:

Oh I think where the "T" disconnect is now.

Registered type is a wide community thing only. Keep it there.

​It is not .. that is entire point.

T flag means that implementation knows what to do with the community without extra policy needed. As example - geo-stuff will be of registered type. ​Portion of wide type one will also be registered ... the other local.

Large community is a single type and its registered.

​Large is a free form agreement between parties so is it not regsistered in the sence of that flag, It is of local meaning to the agreeing parties only and requires policy for processing it.


Don't encumber large community implementations with this bit.

​That is the thing of contention. Common header means that the header is to be used not only by large community. ​


8 bits is enough size. It is unlikely to grow to more than 10 types. In the unlikely event that it grows to 256, we can define an extension type. It is vanishingly unlikely.

The common header needs no more flags. If you are desperate for flags, put them into your own header.

​Now we all know your perspective on this.

Thx,
Robert.​




Thanks,
Jakob.


On Sep 9, 2016, at 12:13 PM, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:

Jeff,

As far as common header details there were three points which privately Jakob and I were not able to solve. Hence as recommended by chairs we moved the discussion to IDR list.

1. IANA registered or private indication.

As you pointed out that can be a flag or it can be embedded within the type. I was fine with any of those - Jakob said no to both. My personal preference is a flag. Simple and non overlapping with anything - very easy to filter as well without going one level deep.

And even if implementations always go to policy processing to filter communities tools like BMP parsers or other monitoring tools may not need to. It costs nothing to have such explicit flag.

2. Size of type field

Original wide had two octets, Jakob locked his position on single octet. I offered compromize with 12 bits. The compromize was rejected. Maybe 255 is enough - maybe not ... but today we already see need for 4 or 5 (ext. comm successor). It really does not cost that much to leave extra room IMHO. Especially that tomorrow someone may come with brilliant idea to steal most significant bit or two of type field for some other use.

3. Size of flags

That one was not that much of contradiction - I guess one octet or 12 bits for extra space would be fine too.

Rest of the elements in common header are context AS - here we agreed easily that what it means is a local matter and will be described in a given type. Length of two octets (in octets) also seems fine to everyone.

As you all see we were and we still are so close to reach consensus if only one implementer would indicate willingness and flexibility to accept the compromise.

Maybe voices from the list will convince him ;-).

Cheers,
R.


On Fri, Sep 9, 2016 at 5:50 PM, Jeffrey Haas <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Sep 09, 2016 at 03:35:35PM +0000, Jakob Heitz (jheitz) wrote:
> Here is my common header

See? That wasn't so hard.

Summary of diffs from wide -03 header proposal:
- No confed bit for transitivity.
- IANA registration bit.

The confed behavior description in wide has been there for completeness.  I
don't believe the wide comm authors are strongly opinionated about it
remaining.  That said, behavior of these new community types in a
confederation needs to be specified.  (Likely, they're transitive.)

The IANA registration bit is something that requires a bit more discussion
as we began having in private thread.  The motivation of that flag in the
wide communities spec was specificall to permit *customers* to create their
own internal types without having to get a code point registered with IANA
and a format specified at IETF level.

My feedback on that point is there are two options that I believe cover that
desired behavior:
- We decide that we want to only have registered types in common headers,
  but potentially reserve a type (e.g. 255) for opaque attributes.  In that
  case, recommending that the non-transitive bits are required (or presumed)
  covers the case.
- We leave such internal format to specific formats, e.g. wide comms.

I'm fine with the second option since semantic flexibility is more something
covered by the wide case anyway and future formats can similarly make it
available as part of their specification.

Presuming the other wide comm authors agree that we don't care about the
community case and agree with the above assessment on iana registration,
we've converged on a common header.

-- Jeff

> 2.1.  BGP Community Container Header
>
>    Containers always start with the following 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    | T |          Length               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Context ASN                             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    The fields are as shown below:
>
>         Type -  The type of community following the header.  The types
>              are to be defined in companion documents.
>
>         Flags -  Sent as 0.  Ignored upon receipt.  MUST be propagated
>              to other BGP speakers unchanged.  These flags may be
>              assigned meanings by future specifications.  Thus it is
>              important that speakers that do not recognize the flags
>              propagate them unchanged.
>
>         T -  Transitivity field
>
>              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.  However, by default, every autonomous
>                   system is its own administrative region.
>
>              Value 2:  The communities in the container are transitive,
>                   but not across an AS boundary.
>
>              Value 3:  The communities in the container are not
>                   transitive.
>
>         Length -  The number of octets occupied by the communities after
>              the header.
>
>         Context ASN -  Context Autonomous System Number.
>
>              The meaning of this is defined in the specifications of
>              each container type
>
>    The Transitivity field governs how a received community is propagated
>    in a BGP UPDATE message to the next speaker.  It does not apply to
>    the originator of a community.  That means that a BGP speaker may
>    send a community over any boundary if it is configured to do so.  The
>    transitivity applies when a speaker is simply passing the community
>    on.
>
>    A BGP speaker that does not recognize a container type SHOULD ignore
>    it, but propagate it to other speakers as defined by the Transitivity
>    field.  This behavior MAY be overridden by local policy.
>
>
> Thanks,
> Jakob.
>
>
> > On Sep 9, 2016, at 11:30 AM, Jakob Heitz (jheitz) <[e-mail]<mailto:[e-mail]>> wrote:
> >
> > I had endless discussions with Robert on the format of the common header and I don't have the appetite anymore. Besides, it's not needed. Attribute exhaustion is a strawman.
> >
> > Thanks,
> > Jakob.
> >
> >
> >>> On Sep 9, 2016, at 11:24 AM, Jeffrey Haas <[e-mail]<mailto:[e-mail]>> wrote:
> >>>
> >>> On Thu, Sep 08, 2016 at 10:54:36PM +0000, Jakob Heitz (jheitz) wrote:
> >>> Jeff, you proposed to split a common header out of the wide communities draft as a separate draft and I agreed. Then Robert didn't want to do that and published -03 of the wide communities. So be it.
> >>
> >> The discussion circled around the *logistics* of the split.  Robert would
> >> prefer not to, I'm supportive of it.  John requested we take this discussion
> >> to the mail list, hence I'm doing so.
> >>
> >> Tersely, with a common header, I'm supportive of a separate 4:4 draft as
> >> long as it's built on a common header as per the other discussion.  That
> >> header can be in a separate draft; Robert has updated wide -03 in a way that
> >> shows how the split may be done.
> >>
> >> In the absence of a common header, I would not be supportive of the current
> >> proposal.
> >>
> >> -- Jeff

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr