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

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

More on transitivity.

Transitivity is just a request by the sender to transit unknown types. A receiver is fully within its rights to refuse transit. That's why we have attribute filtering. We will need to extend attribute filtering into community types.

An administrative region is defined by the operator. By default, every AS is its own administrative region. To create an administrative region of multiple ASes will require extra configuration on the routers involved. In this way, someone who has no interest in administrative regions need do nothing.

Transitivity across confederation member ASes was considered, but it would require another bit and no real need for it was seen.

Thanks,
Jakob.


> On Sep 9, 2016, at 11:49 AM, Jeffrey Haas <[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]> 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]> 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