Subject: [Idr] draft-decraene-idr-reserved-extended-communities-00

From: John Scudder <[email-masked]>
Date: Sat, 13 Nov 2010 07:36:31 -0800

Folks,

There was a certain lack of clarity during the discussion of draft-decraene-idr-reserved-extended-communities-00 at the wg meeting -- we got sidetracked into a tangential discussion of draft-ietf-grow-bgp-gshut-02 instead.  So instead of simply asking about wg adoption of the draft, I would like to remind people of the request the draft makes, and then ask. 

Simply put, the draft asks for the following:

- to allocate a code point from the registry "BGP Extended Communities Type - extended, transitive"
- to allocate a code point from the registry "BGP Extended Communities Type - extended, non-transitive"
- to establish a pair of registries for values to be carried in the data portion of extended communities using respectively, either of those two code points. 

This seems to Sue and me to be a modest and reasonable request to the WG. The debate in our limited Q&A time revolved around the related gshut draft. Much as with other recent drafts, we think the conversation should be divided into two pieces:

- mechanics, in this case extended community allocation and registry establishment. That is what the draft and this message relate to. 
- details of related applications. There seems to be a healthy conversation already taking place related to gshut, within GROW and in hallway conversations. 

The proposal on the table is that the extended community type codes be allocated and the requested registry established. If folks have objections to those specific work items please send them to the list. If adopted, we're basically done by the way -- there is really no further work for the WG, just a little for the chairs.

In closing I will point out that although draft-decraene-idr-reserved-extended-communities-00 makes its request from the Standards Action portion of the two registries, it need not -- the authors could have requested an FCFS code point instead in which case this discussion would have been moot.  They could still do this.  

Please send any objections to allocating the type codes and establishing the registry before November 29. If you do object, please provide justification for your position.

Thanks,

--John and Sue

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 13 Nov 2010 16:56:57 +0100

Hi John,

Before we start the discussion on this one should we first not conclude 
what is the WG consensus reg draft-decraene-idr-rfc4360-clarification-00 
document ?

Main purpose for draft-decraene-idr-reserved-extended-communities-00 is 
that standard communities where GSHUT is already registered by IANA 
(0xFFFF0000) do not have a way to limit propagation across AS boundaries.

Therefor I think to proceed formally further WG should agree or disagree 
on the former draft defining how implementations should handle AS 
transitiveness of extended communities.

Many thx,
R.

> Folks,
>
> There was a certain lack of clarity during the discussion of
> draft-decraene-idr-reserved-extended-communities-00 at the wg meeting
> -- we got sidetracked into a tangential discussion of
> draft-ietf-grow-bgp-gshut-02 instead.  So instead of simply asking
> about wg adoption of the draft, I would like to remind people of the
> request the draft makes, and then ask.
>
> - to allocate a code point from the registry "BGP Extended
> Communities Type - extended, transitive" - to allocate a code point
> from the registry "BGP Extended Communities Type - extended,
> non-transitive" - to establish a pair of registries for values to be
> carried in the data portion of extended communities using
> respectively, either of those two code points.
>
> This seems to Sue and me to be a modest and reasonable request to the
> WG. The debate in our limited Q&A time revolved around the related
> gshut draft. Much as with other recent drafts, we think the
> conversation should be divided into two pieces:
>
> - mechanics, in this case extended community allocation and registry
> establishment. That is what the draft and this message relate to. -
> details of related applications. There seems to be a healthy
> conversation already taking place related to gshut, within GROW and
> in hallway conversations.
>
> The proposal on the table is that the extended community type codes
> be allocated and the requested registry established. If folks have
> objections to those specific work items please send them to the list.
> If adopted, we're basically done by the way -- there is really no
> further work for the WG, just a little for the chairs.
>
> In closing I will point out that although
> draft-decraene-idr-reserved-extended-communities-00 makes its request
> from the Standards Action portion of the two registries, it need not
> -- the authors could have requested an FCFS code point instead in
> which case this discussion would have been moot.  They could still do
> this.
>
> Please send any objections to allocating the type codes and
> establishing the registry before November 29. If you do object,
> please provide justification for your position.
>
> Thanks,
>
> --John and Sue _______________________________________________ Idr
> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/idr
>

---

From: John Scudder <[email-masked]>
Date: Sat, 13 Nov 2010 08:32:22 -0800

Robert,

Briefly put, I don't think this is necessary.  While RFC 4360 could be Even Clearer regarding the semantics of extended community transitivity, there isn't any fundamental disagreement I'm aware of.  Furthermore, as I indicated in my previous message, we would like to separate questions of mechanics (draft-decraene-idr-reserved-extended-communities-00) from applications (gshut).

Given that transitive/non-transitive registries already exist, there seems to be no difficulty in allocating a code point from each, regardless of the observations made in draft-decraene-idr-rfc4360-clarification-00.  Any clarifications that might be made would indeed apply to such code points, and that's fine.

If you or the authors would like to further pursue draft-decraene-idr-rfc4360-clarification-00 in addition, that is fine.

--John

---

From: Tony Li <[email-masked]>
Date: Sun, 14 Nov 2010 08:46:02 +0900

I have no problem allocating code points and new registries once we have consensus on the draft.

However, I think reversing the process creates a suboptimal situation, wherein we could end up allocating code points and registries for drafts that we then decide to abandon.  This seems like a dangerous precedent.

I would propose that we discuss the draft first.

Tony

On Nov 14, 2010, at 12:36 AM, John Scudder wrote:

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

---

From: Pierre Francois <[email-masked]>
Date: Sun, 14 Nov 2010 18:33:31 +0100

Robert,

On 13/11/10 16:56, Robert Raszuk wrote:
> Hi John,
>
> Before we start the discussion on this one should we first not conclude what is
> the WG consensus reg draft-decraene-idr-rfc4360-clarification-00 document ?

 From the discussions we had after the 
draft-decraene-idr-rfc4360-clarification-00 talk, I had the feeling that an 
implementation of 4360 would have to

- Accept non transitive communities received over an eBGP session
- Remove such communities when propagating paths from iBGP to eBGP

That is: You can send non transitive communities out of your AS, and your 
neighbor will accept them. When propagating a path over eBGP, you're not allowed 
to leave a community that was tagged by the neighboring AS which propagated that 
path to you.

This is basically doing on communities what you do on paths tagged with NO_EXPORT.

We were expecting this when we were testing g-shut based on these communities. 
We found 2 implementations which were not.

This was the whole point of the clarification draft. I let it die because I 
thought it was made clear that what we found were bugs. If this is not the case, 
I'm okay to refresh the draft that would lead to an addendum to 4360 or whatever 
the IETF process recommends for such small contributions.

Pierre.

> Main purpose for draft-decraene-idr-reserved-extended-communities-00 is that
> standard communities where GSHUT is already registered by IANA (0xFFFF0000) do
> not have a way to limit propagation across AS boundaries.
>
> Therefor I think to proceed formally further WG should agree or disagree on the
> former draft defining how implementations should handle AS transitiveness of
> extended communities.
>
> Many thx,
> R.
>
>
>> Folks,
>>

---

From: <[email-masked]>
Date: Mon, 15 Nov 2010 09:55:31 +0100

Robert,

> what is the WG consensus reg
draft-decraene-idr-rfc4360-clarification-00
> transitiveness of extended communities.

Unless you specifically target
draft-decraene-idr-reserved-extended-communities-00 for an unstated
reason, it's seems to me that what you're asking for is that the WG
should not do any work related to non transitive community until there
is consensus on draft-decraene-idr-rfc4360-clarification-00. If the WG
were to follow your request, there could be other casualties. E.g.
draft-ietf-idr-link-bandwidth-01. And to be fully consistent, that would
mean requesting the IANA to stop allocating any non transitive community
types.

On a side note, Robert, you were at the IDR meeting when
draft-decraene-idr-rfc4360-clarification-00 was discussed. You did not
brought this above point that the draft was so much important. Quite the
contrary in fact. What made you change your mind?

Bruno

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Nov 2010 10:11:37 +0100

Hi Bruno,

Nope I am not proposing to stop any work which would include allocating 
a code point to non transitive extended communities.

But I do think that in the event of any clarity required for g-shut it 
could be a good opportunity to make that happen now while we are at it.

Or perhaps we are all clear now and no further clarification is needed ?
If so then we don't need to worry about this.

Cheers,
R.

---

From: <[email-masked]>
Date: Mon, 15 Nov 2010 10:27:01 +0100

Tony,

> I have no problem allocating code points and new registries once we
have
> consensus on the draft.

I assume you mean draft-ietf-grow-bgp-gshut-02 (i.e. not
draft-decraene-idr-reserved-extended-communities-00)

> However, I think reversing the process creates a suboptimal situation,
wherein
> we could end up allocating code points and registries for drafts that
we then
> decide to abandon.  This seems like a dangerous precedent.

- Regarding the code point (extended community type), allocating it is
not the issue here. They are FCFS. This point can be removed from the
draft if this is the point you have an issue with.

- Regarding registry, if people can't get a community, they will get a
full type instead. This seems much more suboptimal to me.

- Regarding the draft draft-ietf-grow-bgp-gshut-02 that people could
"decide to abandon":

	- I see a circular reference here:
		- draft-ietf-grow-bgp-gshut cannot progress because it
cannot allocate a non transitive extended community (i.e. waiting for
draft-decraene-idr-reserved-extended-communities)
		- you propose that
draft-decraene-idr-reserved-extended-communities should not progress
while there is no consensus on draft-ietf-grow-bgp-gshut.
	How do you propose that we break that circle? And what do you
mean by "consensus" on draft-ietf-grow-bgp-gshut which is already a WG
doc?

	- even if draft-ietf-grow-bgp-gshut-02 were abandoned, what
exactly would be the issue? Remember that the alternative for
draft-decraene-idr-reserved-extended-communities is that anyone needing
a community will get a full type. (and you won't have the opportunity to
give your opinion on that since its FCFS)

> I would propose that we discuss the draft first.

You're very welcomed to discuss draft-ietf-grow-bgp-gshut-02 in GROW. 

Bruno

> > There was a certain lack of clarity during the discussion of
draft-decraene-
> idr-reserved-extended-communities-00 at the wg meeting -- we got
sidetracked
> into a tangential discussion of draft-ietf-grow-bgp-gshut-02 instead.
So
> instead of simply asking about wg adoption of the draft, I would like
to
> remind people of the request the draft makes, and then ask.
> >
Communities Type
> - extended, transitive"
Communities Type
> - extended, non-transitive"
> > - to establish a pair of registries for values to be carried in the
data
> portion of extended communities using respectively, either of those
two code
> points.
> >
> > This seems to Sue and me to be a modest and reasonable request to
the WG.
> The debate in our limited Q&A time revolved around the related gshut
draft.
> Much as with other recent drafts, we think the conversation should be
divided
> into two pieces:
> establishment. That is what the draft and this message relate to.
> > - details of related applications. There seems to be a healthy
conversation
> already taking place related to gshut, within GROW and in hallway
> conversations.
> >
be
> allocated and the requested registry established. If folks have
objections to
> those specific work items please send them to the list. If adopted,
we're
> basically done by the way -- there is really no further work for the
WG, just
> a little for the chairs.
draft-decraene-idr-reserved-
> extended-communities-00 makes its request from the Standards Action
portion of
> the two registries, it need not -- the authors could have requested an
FCFS
> code point instead in which case this discussion would have been moot.
They
> could still do this.
establishing the
> registry before November 29. If you do object, please provide
justification
> for your position.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 15 Nov 2010 12:21:39 -0500

John> although draft-decraene-idr-reserved-extended-communities-00 makes its
John> request from the Standards Action portion of the two registries, it
John> need not -- the authors could have requested an FCFS code point
John> instead in which case this discussion would have been moot.  They
John> could still do this.

The discussion about the allocation of the codepoint would be moot, but I
don't think there's a FCFS procedure for the creation of IANA registries.
So I don't really think this draft could go forward without WG discussion
even if FCFS codepoints were requested.

I think it's a valid question to ask why this new registry is actually
needed.  The draft offers two justifications:

   "one needing to reserve a single non-transitive extended community
   would need to reserve an extended subtype which represents 2^48
   communities.  This would both waste the resources"

I don't really see what the resource is that's being wasted.  Are we worried
about running out of extended type codepoints?

   "and disable the ability to define global policies on reserved
   communities, such as to filter them out."

The proposal is to have a big chunk of FCFS space in the new registry.  This
means that anyone can use it for anything.  That makes it hard to see how
there could be a useful global policy to filter them all out.

I'm having trouble seeing what value is provided by this new registry.

Bruno> if people can't get a community, they will get a full type
Bruno> instead. This seems much more suboptimal to me.

I'm not sure what "much more suboptimal" means in this context.  

I also think it's confusing to call these extended communities "reserved",
as RFC 5226 ("Guidelines for Writing IANA Considerations") defines the term
"reserved" as meaning "not to be assigned".

---

From: <[email-masked]>
Date: Mon, 15 Nov 2010 19:05:26 +0100

Eric,

> about running out of extended type codepoints?

Reserving 2^48 = 2.8 10^14 = two hundreds thousand billions communities
while a single is required, I call this wasting resources.

The number of code points is limited. If we use it, what ever the rate
of use, one day there won't be any. We ran out of class B, AS number, IP
addresses, optional parameter length... How can you be certain that we
will never run out extended types?

> there could be a useful global policy to filter them all out.

For example, if _you_ believe these are evil, you will be able to remove
or not interpret them.
On the contrary, one could this type to allow them on PE-CE eBGP session
(within a VRF) while filtering out RT or others extended community
types.

> I'm having trouble seeing what value is provided by this new registry.

The value is the ability to get and use non-transitive reserved/well
known/std action extended community.

As for myself, I'm having trouble understanding your concern with this. 
A registry for reserved/well known/std action community do exist. Do you
have a concern with it? If not, don't you think that non transitive ones
would be as useful as the transitive ones?
 
> I'm not sure what "much more suboptimal" means in this context.

It's suboptimal to waste 2.8 10^14 when allocating a single value.
That's a 3.10E-13 % efficiency.
 
> "reserved" as meaning "not to be assigned".

We can use a different name. Would you have any proposition?

---

From: Eric Rosen <[email-masked]>
Date: Mon, 15 Nov 2010 14:37:35 -0500

> while a single is required, I call this wasting resources.

The resource being wasted is the 2^48 potential values of the low order six
bytes of the extended community??  I.e., there are 2^48 values that could
have been used for codepoints but are instead going wasted?

How many codepoint values do you expect IANA to assign from this registry?
Even if they assign, say, a billion, the resource utilization will still be
pretty close to zero.

> We ran out of class B, AS number, IP addresses, optional parameter
> length... How can you be certain that we will never run out of extended
> types?

I don't think the proposed registry is a very good hedge against running out
of extended types, as it essentially creates an extended community that
consists of eight bytes of type field and zero bytes of value field.  If we
use up all the two-byte extended type values, we will probably still want
some value field bytes.

> if _you_ believe these are evil, you will be able to remove or not
> interpret them.

It's hard to imagine that all 2^48 codepoints will be evil.

> have a concern with it?

Yes, I don't think it makes any sense to have a registry for communities
that "have global significance and their operations shall be implemented in
any community-attribute-aware BGP speaker"; obviously one can't allocate a
new codepoint from that registry without throwing all existing
implementations out of compliance.

---

From: Jie Dong <[email-masked]>
Date: Tue, 16 Nov 2010 11:27:14 +0800

Hi Eric,

> implementations out of compliance.

As extended communities is an optional transitive attribute, and some of
which may have a limited propagation scope (non-transitive across AS ), a
new codepoint may not have such great impact on the network.

Best regards,
Jie

---

From: <[email-masked]>
Date: Tue, 16 Nov 2010 10:15:04 +0100

> Even if they assign, say, a billion, the resource utilization will
still be

True. (I could argue that 8 octets are still reserved and could be
further used, but I don't think it's really the main point)
Yet under your hypothesis, it would be much better than the alternative
(using a billion community types).

> use up all the two-byte extended type values, we will probably still
want

It's a small contribution. It's effective in the case where more people
want to get a non transitive community. (or a block of communities).
Given that the cost of this proposition is very low, it seems to me that
potential gains are greater than the cost.
 
> implementations out of compliance.

- You are quoting RFC 1997 (BGP Communities Attribute) which has defined
such "Well-known Communities". Discussion on
draft-decraene-idr-reserved-extended-communities-00 will not improve
your concern on RFC 1997 well-known community. (And BTW this registry is
not anymore about "Well-Known Communities", but about "reserved BGP
communities" so there is no such concern
http://www.ietf.org/mail-archive/web/idr/current/msg03002.html  ) 

- We are _not_ proposing to create a registry for communities that "have
global significance and their operations shall be implemented in any
community-attribute-aware BGP speaker". We are proposing to create a
registry to allocate values which are globally unique.