Subject: [Idr] draft-heitz-idr-large-community

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Sep 2016 11:03:01 +0200

/* Renaming this conversation as this is no longer about accepting it as WG
doc, but rather general discussion about this proposal. */

​
Q2. If your ISP offers the service to transit communities,

The point was that we have learned since RFC1997 published 10 years back
that there is no trust in the Internet any longer. But this is perhaps more
of an SIDR issue so let's talk about it when this draft becomes WG doc.

But how to assure integrity and correctness of originating AS intention via
untrusted transit ASes ...

The security aspect of wide communities have been discussed in the past. I
am interested in this as will be very glad to use the same solution as we
accept for large communities in the wide community document. Both are
transitive via multiple ASes hence the issue.

> Q3. The spec must not enforce any stripping.

I respectfully disagree.

Sending community containing in the first 4 octets of an AS outside of a
given AS over eBGP session to me is a clear and direct indication that such
community is meaningless any longer. If so why then to allow to send it ?

Local policy of send-all would not help. Would we need soon another draft
along the lines of draft-mauch-bgp-reject to deal with large community
default pollution ?

If you rename this entire text into 4:4:4 all being of mutual agreement
between parties then my point is gone ... but till that happen I am willing
to understand the rationale.

> ​
BTW, this all works the same way as it does with regular communities.

Is that supposed to be a feature or a bug ? ;-)

Cheers,
R.

On Thu, Sep 8, 2016 at 3:08 AM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> Q1. My implementation as it stands uses ios-regex to filter, so you can
> filter whatever you want. I have an optimization in mind that will make it
> easier to match on each field individually, but it's not done yet.
> Your example: delete largecommunity not in (ios-regex '^2914:')
>
> ​​
> Q2. If your ISP offers the service to transit communities, then that ISP
> will be able to transmit the large communities unchanged with my
> implementation.
>
> Q3. The spec must not enforce any stripping. It is up to a receiver to
> strip whatever it does not want to receive. In my implementation, large
> communities are dropped by default by EBGP senders. You must
> configure send-community-ebgp if you want it to send large communities. You
> can use the delete statement of Q1 in a neighbor outbound route-policy if
> you want to selectively remove large communities.
>
> ​​
> BTW, this all works the same way as it does with regular communities.
>
> Thanks,
> Jakob.
>

---

From: "Dickinson, Ian" <[email-masked]>
Date: Thu, 8 Sep 2016 10:36:51 +0000

I respectfully disagree.

Sending community containing in the first 4 octets of an AS outside of a given AS over eBGP session to me is a clear and direct indication that such community is meaningless any longer. If so why then to allow to send it ?

Again mapping to current community usage, these communities will almost definitely also be used to signal information to peers.
E.g. “Learnt from customer of <ASNX>”, “Learnt from peer of <ASNX>”, “Has been inspected by service <Y>”, etc
But perhaps expanded with additional information compared to the current use of RFC1997.
So, not meaningless IMHO.

In my experience, it has always been the receivers choice to filter or not, and largely on whatever basis they choose.

Thanks,

Ian
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

---

From: Job Snijders <[email-masked]>
Date: Thu, 8 Sep 2016 12:43:04 +0200

Dear Ian,

On Thu, Sep 08, 2016 at 10:36:51AM +0000, Dickinson, Ian wrote:
> Sending community containing in the first 4 octets of an AS outside of
> a given AS over eBGP session to me is a clear and direct indication
> that such community is meaningless any longer. If so why then to allow
> to send it ?
>
> <snip>
>
> In my experience, it has always been the receivers choice to filter or
> not, and largely on whatever basis they choose.

exactly.

To align with how RFC 1997 commmunities are used today. If _you_ find
them meaningless, please delete them, that is your choice. The technical
specification should not _enforce_ stripping.

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 08 Sep 2016 11:49:53 +0100

Robert Raszuk wrote:
> given AS over eBGP session to me is a clear and direct indication that
> such community is meaningless any longer. If so why then to allow to
> send it ? 

It would be better to leave this up to operators to decide what's best
for their requirements rather than removing the option.  In this
situation, I don't think it's useful to be too over-prescriptive.

Nick

---

From: Jared Mauch <[email-masked]>
Date: Thu, 8 Sep 2016 07:21:51 -0400

> On Sep 8, 2016, at 5:03 AM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> /* Renaming this conversation as this is no longer about accepting it as WG doc, but rather general discussion about this proposal. */
> 
> 
> > ​Q2. If your ISP offers the service to transit communities,
> 
> The point was that we have learned since RFC1997 published 10 years back that there is no trust in the Internet any longer. But this is perhaps more of an SIDR issue so let's talk about it when this draft becomes WG doc. 

There isn’t really anything to talk about, communities are additive, and any relationship with SIDR should happen in that WG or in the follow-up activities if it’s merged.

> But how to assure integrity and correctness of originating AS intention via untrusted transit ASes … 

As i’ve said to others, things like AS_PATH are a bit-string, a malicious actor can stuff whatever they want in it.  There is no new risk here unless you process these communities, and having no well-known attributes makes the risk nearly zero.

> The security aspect of wide communities have been discussed in the past. I am interested in this as will be very glad to use the same solution as we accept for large communities in the wide community document. Both are transitive via multiple ASes hence the issue. 

This isn’t about the current wide-communities draft that seems to have low traction in the WG.  Sorry.  Your draft is trying to normalize the values operators have already defined to meet their needs, this is not always universally helpful.  I understand the motive, but I’ve failed to see the consensus with the existing draft coalesce and there are no implementations I’m aware of, while this seems to be making steady progress to resolve the very real issues we as operators face.

> > Q3. The spec must not enforce any stripping.

The good new is you are wrong. :-)

> Local policy of send-all would not help. Would we need soon another draft along the lines of draft-mauch-bgp-reject to deal with large community default pollution ? 

I’m confused as, communities are not sent by default, making them part of being conservative in what is sent, eg: cisco requires you to configure send-community which requires session tear-down to initalize.  I’ve seen no proposal in GROW or IDR to change this, nor recommendation.  

Also the proper version of the draft is https://tools.ietf.org/html/draft-ietf-grow-bgp-reject.  Feedback on that draft is much appreciated.  Let me know if I missed your e-mail.

> If you rename this entire text into 4:4:4 all being of mutual agreement between parties then my point is gone ... but till that happen I am willing to understand the rationale. 
> 
> > ​BTW, this all works the same way as it does with regular communities.
> 

The fact the communities have no defined structure is a feature and why there have been interesting innovations which did not require the IETF to standardize things.  We lack the proper size canvas in a rfc4893 world, this was an oversight which must be corrected.  There are reasons it’s not been critical along the way, but this is the tipping point where IDR must take action.

> Cheers,
> R.
> 
> 
> On Thu, Sep 8, 2016 at 3:08 AM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> Q1. My implementation as it stands uses ios-regex to filter, so you can filter whatever you want. I have an optimization in mind that will make it easier to match on each field individually, but it's not done yet.
> ​​Q2. If your ISP offers the service to transit communities, then that ISP will be able to transmit the large communities unchanged with my implementation.
> 
> Q3. The spec must not enforce any stripping. It is up to a receiver to strip whatever it does not want to receive. In my implementation, large communities are dropped by default by EBGP senders. You must configure send-community-ebgp if you want it to send large communities. You can use the delete statement of Q1 in a neighbor outbound route-policy if you want to selectively remove large communities.
> 
> ​​BTW, this all works the same way as it does with regular communities.
> 
> Thanks,
> Jakob.
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Sep 2016 13:25:11 +0200

Hi,

> Sending community containing in the first 4 octets of an AS outside of a given AS over eBGP session to me is a clear and direct indication that such community is meaningless any longer. If so why t…

No, why?  If one of my customers wants to achieve a certain effect in
one of my upstreams, they are free to send $upstream:xxx to us, which
I'll forward to AS $upstream.

Upstream/Customer hierarchies can be deeper than "one".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Jared Mauch <[email-masked]>
Date: Thu, 8 Sep 2016 07:27:33 -0400

> Upstream/Customer hierarchies can be deeper than "one".

	yes, and we see this today.  The same could be said for
inter and intra-datacenter networks using confeds or similar.  right now
operators have commented on-list about the existing problems they have
with the private namespace collissions.  Happy to point you at the message
in private if you missed it in the thread.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Sep 2016 13:44:20 +0200

Hi Ian

By meaningless I considered the explanation as provided by authors that
meaning of community is only in the AS as indicated in its first 4 octets.

Based on that once the community leaves such AS I see no longer use for it
hence my comment.

​If folks think we should count on manual filtering inbound or outbound or
both so be it. How easy or how hard it will turn out in practice will be
fully dependent on given implementation's policy language/rules.

​Best,

R.​
​

On Sep 8, 2016 12:36 PM, "Dickinson, Ian" <[email-masked]> wrote:

> Again mapping to current community usage, these communities will almost
> definitely also be used to signal information to peers.
>
> Information in this email including any attachments may be privileged,
> confidential and is intended exclusively for the addressee. The views
> expressed may not be official policy, but the personal views of the
> originator. If you have received it in error, please notify the sender by
> return e-mail and delete it from your system. You should not reproduce,
> distribute, store, retransmit, use or disclose its contents to anyone.
> Please note we reserve the right to monitor all e-mail communication
> through our internal and external networks. SKY and the SKY marks are
> trademarks of Sky plc and Sky International AG and are used under licence.
>
> Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited
> (Registration No. 2067075) and Sky Subscribers Services Limited
> (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc
> (Registration No. 2247735). All of the companies mentioned in this
> paragraph are incorporated in England and Wales and share the same
> registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Sep 2016 13:52:47 +0200

Hi,

On Thu, Sep 08, 2016 at 01:44:20PM +0200, Robert Raszuk wrote:
> ???If folks think we should count on manual filtering inbound or outbound or
> both so be it. 

This.

> How easy or how hard it will turn out in practice will be

Vendors have provided halfway workable languages to do so for the existing
32bit communities, so I'd expect them to learn from that, and provide
appropriate filtering for 4+4+4.

Gert Doering
        -- NetMaster

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Sep 2016 13:54:26 +0200

Gert/Jared,

It is not about you propagating it or not. It is about a question if your
deeper then one $upstream does what he promised to do with that why to send
this any further.

And no structure means 4:4:4 ... if this is in the spec - case solved - no
questions. But as of today in the protocol spec there is AS number and if
so the spec should IMO elaborate a bit more on that. That was my question.

As far as wide community is concerned it is already a WG document so all
traction needed is really about implementations. But this is not about
that.

Cheers,
R.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 8 Sep 2016 08:08:48 -0400

Robert,

First can you fix the font size on your e-mail client?  We keep getting some sentences in quite small fonts while others are larger.  If you’re unable, please send in text/plain.

> On Sep 8, 2016, at 7:54 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Gert/Jared,
> 
> It is not about you propagating it or not. It is about a question if your deeper then one $upstream does what he promised to do with that why to send this any further. 

It’s the internet, there are no guarantees unless you are under contract.  Contract law is outside IDR.  Some providers propagate it, others do not.  This depends on that provider and style.  

> And no structure means 4:4:4 ... if this is in the spec - case solved - no questions. But as of today in the protocol spec there is AS number and if so the spec should IMO elaborate a bit more on that. That was my question. 

While the first ASN may specify relevance, like any other routing manipulation/tricks I expect it to be used in ways to solve problems we don’t anticipate currently.  It’s common for people to inject the ASN they don’t want their routes to be propagated to into the AS_PATH and has been observable for over a decade (for example).

> As far as wide community is concerned it is already a WG document so all traction needed is really about implementations. But this is not about that. 

The absence of an implementation of wide speaks volumes to me personally and is the reason for this draft in IDR.

- Jared

---

From: Jared Mauch <[email-masked]>
Date: Thu, 8 Sep 2016 08:29:09 -0400

> On Sep 8, 2016, at 7:52 AM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

Yes, the existing explicit match and regex based systems, eg:

JunOS:

    community comm-type-wild members "^2914:3..$”;

XR:

community-set comm-peers-wild
  ios-regex '2914:39.$'
end-set

If you refer to the previous mail from Jakob on how this is implemented in XR
it looks essentially the same.  There are also variable based methods
for interacting with communities, eg:

route-policy peer-prepend-ext($asn)
  if community matches-any (65410:$asn) then
    pass
  elseif community matches-any (65401:$asn) then
    prepend as-path 2914 1
. . .

- Jared

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Sep 2016 14:33:56 +0200

Jared,

First can you fix the font size on your e-mail client?  We keep getting
> some sentences in quite small fonts while others are larger.  If you’re
> unable, please send in text/plain.
>

​Hope this helps.​

> > It is not about you propagating it or not. It is about a question if
> your deeper then one $upstream does what he promised to do with that why to
> send this any further.
>
> It’s the internet, there are no guarantees unless you are under contract.
> Contract law is outside IDR.  Some providers propagate it, others do not.
> This depends on that provider and style.
>

​It is not about propagating it before it is used. It is about propagating
it after it is used.

It's about either discarding an empty coke can when you are done with it or
passing it along to others hoping someone else will trash it or if not the
can will stay on the bus.

​If it is not empty by design - read it is 4:4:4 - of course pass it along
as much as ​you like.

> While the first ASN may specify relevance, like any other routing
> manipulation/tricks I expect it to be used in ways to solve problems we
> don’t anticipate currently.  It’s common for people to inject the ASN they
> don’t want their routes to be propagated to into the AS_PATH and has been
> observable for over a decade (for example).
>

​Correct. And how is this relevant to this thread ? ​

> traction needed is really about implementations. But this is not about that.
>

​The reasons for this draft is that no one either read or were too keen on
asking vendors to implement type 2 or type 3 or type 4 of wide community
draft which provides exactly the same functionality of large communities
with (type 3 & 4) being more flexible in the community size one wishes to
attach.

Type 1 ​had two goals:

#1  - predefine some of the collected from various operational communities
practices and encode it as registered to simplify and unify it's use

#2 - provide flexible encoding for your own policies in more then just 4
octet integers.

Btw type 1 is optional. And type 2-4 does not require any hard policy code
by implementations.

So large community is effectively taken one specific registered community
and attempted to be standardized on its own. If this is what IDR WG prefers
let's do it. Let's just keep in mind that one size does not fit all - even
if it can be very useful for many.

And clearly my mistake was that I did not advertised wide communities
proposal on any *NOGs - I was hoping IETF process is sufficient to get new
encoding going.

Thx,
R.

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Sep 2016 14:39:53 +0200

Hi,

On Thu, Sep 08, 2016 at 02:33:56PM +0200, Robert Raszuk wrote:
> ???The reasons for this draft is that no one either read or were too keen on

Typical IETF overengineering: too complex, too many options, no traction
at vendors to implement yet another bag of "type x or type y or type z"
thing.

This draft, OTOH, is *simple* (no variants!) and follows the mantra of 
"... and running code" - with two implementations already there.  Good!

Gert Doering
        -- NetMaster

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 8 Sep 2016 12:41:17 +0000

My implementation can match the peer AS with the keyword "peeras". For example, to not send any communities to your neighbor that do not have his ASN in the first 4 octets, you would put the following statement into your neighbor outbound route-policy:
delete largecommunity not in (peeras:*:*)

Thanks,
Jakob.

On Sep 8, 2016, at 7:54 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Gert/Jared,

Cheers,
R.

On Thu, Sep 8, 2016 at 1:25 PM, Gert Doering <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Gert Doering
        -- NetMaster

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444<tel:%2B49%20%280%2989%2F32356-444>           USt-IdNr.: DE813185279

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Sep 2016 14:45:40 +0200

That is very true Gert - thx for feedback.

But how complex is to have a community not fixed 4:4:4, but of flexible
size Nx4 ?

Is this so hard indeed that implementors can't manage and that operators
can't use ?

//R

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Sep 2016 14:46:48 +0200

Hi,

> Is this so hard indeed that implementors can't manage and that operators

Dunno.  Why are there two implementations of this, and no implementations
of the other draft?

Gert Doering
        -- NetMaster

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Sep 2016 15:15:54 +0200

Gert, All,

The wide-communities draft per IDR recommendation got splitted into
encoding and registered types quite some time back.

Originally the idea was to list and keep by IANA most operationally needed
communites as registered yet as mentioned to Jared allowing also local
communities without having to go via any IETF process.

For quite a long time authors of wide communities were discussing adding
more flexibility to it including quite involved agebra, but this was
thought as hard to use so we went back to only propose in type 1 few other
then integer fields and define those as "atoms".

After discussions during last IETF in Berlin it was obvious that encoding
of more flexibility of type 1 scares folks even without any build in
algebra.

Wih that authors of wide community rewrote the document into version -03
took three specific registered communities and defined it under separate
types to separate it from need to encode rest of type 1 elements:

Current version is here:
https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-03

Today it has:

type 1 - original proposal without any algebra
type 2 - AS:4:4 (exactly the same as large) with the exception of flags in
the header
type 3 - Nx4
type 4 - 16+ Nx4 (as some folks asked to be able to stuff v6 address there

So type 2 is effectively equivalent of large communities, and type 3 and 4
provide flexible size - no extra policy community containers.

All types are optional by definition.

Some folks expressed the worry that if we implement type 2 the draft will
not progress.  Authors of large and wide comms discussed this with IDR WG
chairs and AD and it is in fact a grey area in IETF. Looking at Extended
Community RFC4360 as example only subset of defined community types ever
got implemented and the draft moved forward to RFC without any issues.

So now it seems we have in the area of communities number of options on the
table:

*A* Proceed with each type as separate draft and call for separate BGP
attribute

*B* Define common single attribute, define common header as separate
document and then cut all needed types including large into separate drafts.

/* Note option *B* was tried among authors of large and wide communities
for a month before this adoption request. However Jakob did not agree on
structure of universal common community header which would be useful to all
types. The disagreement was mainly about having registered vs local flag as
well as size of type and flag fields - we were close .... */

*C* Achieve WG consensus that demonstrating implementation of say 2 out of
current 4 optional types of wide communities is enough to progress the
single and consistent document.

*D* Merge large with wide types 2, 3, and 4 leaving type 1 as a separate
document ...

etc ....

For me personally really does not matter which option WG decides to go
with. Currently it looks like *A*. But what matters is that everyone is
aware about full story behind this topic.

Many thx,
Robert.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 8 Sep 2016 13:32:05 +0000

On 9/8/16, 8:46 AM, "Idr on behalf of Gert Doering" <[email-masked]

>Dunno.  Why are there two implementations of this, and no implementations

There is considerable more gorp in draft-ietf-idr-wide-bgp-communities
then just the Nx4 wide community container…

Thanks,
Acee

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 08 Sep 2016 14:58:53 +0100

> *A* Proceed with each type as separate draft and call for separate
[...]
> For me personally really does not matter which option WG decides to
> go with. Currently it looks like *A*.

The idealogical differences between -large- and -wide- are sufficiently
big that trying to merge them will leave both parties unsatisfied.  One
aims for simplicity, the other for completeness.

Option A works for me.  I don't see any problem having each proceeding
separately through the ietf.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Sep 2016 16:15:40 +0200

> aims for simplicity, the other for completeness.

​Very well said Nick !​

> separately through the ietf.

​I also see no problem to proceed separately say for each type 1-4 as
described.

However if folks would like to proceed separately for each of the 23
registered communities and ask for separate attribute is that really a good
direction ?

Ref:
https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02

And all of those registered communities came directly from operators
keyboards.

Best,
R.

P
​S.

If there is "gorp" in current wide comms WG document as Acee alluded to
maybe it is productive to discuss specifics of such "gorp" at some point ?
Authors and many folks who contributed to those documents would be very
interested to listen to recommendations how to make the document easier to
implement and easier to use.

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Sep 2016 16:24:49 +0200

Hi,

> https://tools.ietf.org/html/draft-ietf-idr-registered-wide-bgp-communities-02

This would make a nice informational RFC "look, this is the way you
*could* organize your 4:4:4 schema".

Having this as "standard track / mandatory to implement" makes my skin crawl.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 08 Sep 2016 15:25:32 +0100

Robert Raszuk wrote:
> > Option A works for me.  I don't see any problem having each
> > proceeding separately through the ietf.
> 

I think we might have misinterpreted each other.  I'm happy for -large-
and -wide- to proceed separately through the ietf on their own merits.

If you want to discuss what to do with -wide-, then that should be
discussed with a separate Subject: line so that it's clear that we're
not talking about anything to do with -large-.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Sep 2016 16:36:56 +0200

Hi Gert,

Good suggestion to turn this into informational or BCP.

The only reason for standards track was not to force an implementation of
all of this - sorry if anyone had such impression - but to have IANA to
maintain the registry for it.

Signalling who supports what would be just like today it will be with large
or is with RFC1997.

Since we are talking about large comms here as far as fitting all of this
to 4:4:4 - it just does not fit with the current encoding. Each registered
type is anywhere from 18 to 26 octets.

Some of them could be reformatted with loss of flexibility and universal
envelope to fit but is this a good thing to first make a small fixed size
bag then try to use it both for one day trips to adjacent city as well as
for month long excursions into jungle ?

Cheers,
Robert.

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Sep 2016 16:40:01 +0200

Hi,

> for month long excursions into jungle ?

If people are in need for a small standard-size bag, it's a mistake to
make them wait for the variable-sized bag that might eventually also
solve their shopping needs, years after the shopping excursion was due.

As Nick said: proceed -wide, see if it has traction, if anyone wants 
to implement it.  In the meantime, let's get -large *out*, so people
can go shopping.

Gert Doering
        -- NetMaster

---

From: heasley <[email-masked]>
Date: Thu, 8 Sep 2016 15:34:32 +0000

> transitive via multiple ASes hence the issue.

Please refer to the discussion over draft-ietf-grow-blackholing for ways
to filter/ignore/etc communities.

> community is meaningless any longer. If so why then to allow to send it ?

There are use-cases where the customer of a customer [of ...] may send a
community for any AS appearing in that chain.  eg: in a path of NTT -> custA
-> custB, custB might wish to send a community to NTT that affects their
routing preference.  or, as Jared described - route origin markers, business
relationship, etc.

> along the lines of draft-mauch-bgp-reject to deal with large community

This passing is already done with rfc1997 communities and no well-knowns are
defined in this draft that any vendor will act upon by default.  The network
admin of any given AS must define policy to take action.

---

From: heasley <[email-masked]>
Date: Thu, 8 Sep 2016 15:57:55 +0000

> Based on that once the community leaves such AS I see no longer use for it

maybe - that is for the AS to decide, not for you or idr to dictate.  the
value portion (8 lsb octets) are a marker that may indicate something
useful to other ASes about routing through that AS or about that specific
route (eg: its a customer route, its a more specific that you could filter,
etc).  the document does not define the values in the 8 lsbs.

> fully dependent on given implementation's policy language/rules.

there is no intrinsic need to filter.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 8 Sep 2016 16:34:39 +0000

If anyone knows how to write a Wireshark dissector, please teach me. I'm tired of reading hex in my unknown attribute. Contact me offline.

Thanks,
Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 8 Sep 2016 19:57:23 +0000

You cannot progress a draft to RFC without interoperable implementations of ALL of the features in it.

It does not matter that some of the features are optional. Optional just means that some implementations may not include it. It does not mean that you can sneak a feature in with zero implementations.

Optional means that implementations MUST work and interoperate with AND without the optional parts. For that reason, optional is harder than mandatory.

Thanks,
Jakob.

On Sep 8, 2016, at 9:27 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Gert, All,

The wide-communities draft per IDR recommendation got splitted into encoding and registered types quite some time back.

Originally the idea was to list and keep by IANA most operationally needed communites as registered yet as mentioned to Jared allowing also local communities without having to go via any IETF process.

For quite a long time authors of wide communities were discussing adding more flexibility to it including quite involved agebra, but this was thought as hard to use so we went back to only propose in type 1 few other then integer fields and define those as "atoms".

After discussions during last IETF in Berlin it was obvious that encoding of more flexibility of type 1 scares folks even without any build in algebra.

Wih that authors of wide community rewrote the document into version -03 took three specific registered communities and defined it under separate types to separate it from need to encode rest of type 1 elements:

Current version is here: https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-03

Today it has:

type 1 - original proposal without any algebra
type 2 - AS:4:4 (exactly the same as large) with the exception of flags in the header
type 3 - Nx4
type 4 - 16+ Nx4 (as some folks asked to be able to stuff v6 address there

So type 2 is effectively equivalent of large communities, and type 3 and 4 provide flexible size - no extra policy community containers.

Some folks expressed the worry that if we implement type 2 the draft will not progress.  Authors of large and wide comms discussed this with IDR WG chairs and AD and it is in fact a grey area in IETF. Looking at Extended Community RFC4360 as example only subset of defined community types ever got implemented and the draft moved forward to RFC without any issues.

So now it seems we have in the area of communities number of options on the table:

*A* Proceed with each type as separate draft and call for separate BGP attribute

*B* Define common single attribute, define common header as separate document and then cut all needed types including large into separate drafts.

/* Note option *B* was tried among authors of large and wide communities for a month before this adoption request. However Jakob did not agree on structure of universal common community header which would be useful to all types. The disagreement was mainly about having registered vs local flag as well as size of type and flag fields - we were close .... */

*C* Achieve WG consensus that demonstrating implementation of say 2 out of current 4 optional types of wide communities is enough to progress the single and consistent document.

*D* Merge large with wide types 2, 3, and 4 leaving type 1 as a separate document ...

etc ....

For me personally really does not matter which option WG decides to go with. Currently it looks like *A*. But what matters is that everyone is aware about full story behind this topic.

Many thx,
Robert.

On Thu, Sep 8, 2016 at 2:46 PM, Gert Doering <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Gert Doering
        -- NetMaster

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Sep 2016 22:09:37 +0200

Jakob,

Unless you show me the official IETF rule which says so I will treat it as
your personal opinion.

Meanwhile I will follow advice from chairs and area directors as well
historical facts of other RFCs which progressed via WGLC with optional
parts never implemented.

Ideally I may agree with you ... practically that has never been a
requirement, If it was we would see tons of -bis RFCs adding types one
after another.

Kind regards,
R.

On Thu, Sep 8, 2016 at 9:57 PM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> It does not matter that some of the features are optional. Optional just
> means that some implementations may not include it. It does not mean that
> you can sneak a feature in with zero implementations.
>
> Optional means that implementations MUST work and interoperate with AND
> without the optional parts. For that reason, optional is harder than
> mandatory.
>
> Thanks,
> Jakob.
>
>
> On Sep 8, 2016, at 9:27 AM, Robert Raszuk <[email-masked]> wrote:
>
> Gert, All,
>
> Current version is here: https://tools.ietf.org/
> html/draft-ietf-idr-wide-bgp-communities-03
>
> Today it has:
>