Subject: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt

From: Robert Raszuk <[email-masked]>
Date: Sun, 8 Mar 2015 00:08:45 +0100

A new version of I-D, draft-raszuk-wide-bgp-communities-05.txt
has been successfully submitted by Robert Raszuk and posted to the
IETF repository.

Name:           draft-raszuk-wide-bgp-communities
Revision:       05
Title:          Wide BGP Communities Attribute
Document date:  2015-03-06
Group:          Individual Submission
Pages:          23
URL:
http://www.ietf.org/internet-drafts/draft-raszuk-wide-bgp-communities-05.txt
Status:
https://datatracker.ietf.org/doc/draft-raszuk-wide-bgp-communities/
Htmlized:
http://tools.ietf.org/html/draft-raszuk-wide-bgp-communities-05
Diff:
http://www.ietf.org/rfcdiff?url2=draft-raszuk-wide-bgp-communities-05

Abstract:
   Route tagging plays an important role in external BGP [RFC4271]
   relations, in communicating various routing policies between peers.
   It is also a very common best practice among operators to propagate
   various additional information about routes intra-domain.  The most
   common tool used today to attach various information about routes is
   through the use of BGP communities [RFC1997].

   Such information is important to allow BGP speakers to perform some
   mutually agreed actions without the need to maintain a separate
   offline database for each tuple of prefix and associated set of
   action entries.

   This document defines a new encoding which will enhance and simplify
   what can be accomplished today with the use of BGP communities.  The
   most important addition this specification makes over currently
   defined BGP communities is the ability to specify, carry as well as
   use for execution an operator's defined set of parameters.  It also
   provides an extensible platform for any new community encoding needs
   in the future.

The IETF Secretariat

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 09 Mar 2015 14:18:22 +0000

Hi Robert,

> Title:          Wide BGP Communities Attribute

thanks for picking this up.

The operational community desperately needs support for a minimum of
32b:32b communities as there is a dwindling supply of 16 bit ASNs and
running a functional network using the current bgp community mechanisms
(all of which have 48 bits of community space) is not feasible at this time.

I've tried this on a production network; it doesn't work.  The network I
set up had to be renumbered to an ASN16.

wide-bgp-communities is a great idea in theory, but it's far too
complicated in practice.  This means that it will be difficult to code, to
debug and to get good quality vendor interoperability. It also presents the
operator with a bewildering range of options, many of which are unlikely to
ever be used.

The complication in the specification also creates a secondary problem for
router vendors in updating their policy languages so that they can
interpret wide bgp communities.

Overall, this is not compatible with the engineering principal of "keep
things as simple as possible - but no simpler".

Suggestions:

1. Would it be possible to ditch:

>      Type  5: IEEE Floating Point Number list
>      Type  6: Neighbor Class list
>      Type  7: User-defined Class list

2. Simplify, or at least explain why this needs needs to be so complicated:

> 4. Container Type 1: Wide Community

3. provide some guidance about deletion or modification of parts of the
community attribute entries, particularly in the context of:

>    The Wide BGP Community Attribute is an optional, transitive BGP
>    attribute, and may be present only once in the BGP UPDATE message.

4. discussion of how implementing this is going to shake out structural
problems in vendors' routing policy grammars, with associated security
implications if the grammars are incapable of handling the complication
that this draft introduces.

5. I love the idea of UTF8 communities.  On smaller network, these could be
a real win.

6. I'm guessing that the structure of container type 1 is designed to
accommodate the <prepend X times Y ASN at location Z> construction that's
widely used on the internet.  This requires a pretty serious grammar to
allow for proper parameter checking.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 9 Mar 2015 11:16:17 -0400

Nick,

> (all of which have 48 bits of community space) is not feasible at this time.

Much as I'm obviously a fan of wide communities, there's a different draft
covering this much more simple use case:

http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-07

> operator with a bewildering range of options, many of which are unlikely to

Operators are already using this bewildering set of options: Complex Policy to
implement common use cases.  The goal for this proposal is to unroll some of
that policy from the policy engine and put it more into the signaling.

> 5. I love the idea of UTF8 communities.  On smaller network, these could be

This is actually the piece I like the least. :-)

> allow for proper parameter checking.

That's actually the best and most common use case.  If we get this simple
policy algebra deployable and nothing else, it's still a win.

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 09 Mar 2015 15:41:01 +0000

> http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-07

yep, this has come up before on idr@.  This is 32b:16b, which doesn't
provide enough space in the local administrator field for production networks.

> that policy from the policy engine and put it more into the signaling.

Which is reasonable, but it's going to cause severe indigestion for some
router vendor grammars which don't have the structural hooks necessary to
be able to handle this sensibly.

> This is actually the piece I like the least. :-)

Indeed.  I configure routers for a living, whereas you design them.  We all
have our own angles on stuff.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Mar 2015 22:42:12 +0100

Hi Nick,

> operator with a bewildering range of options, many of which are unlikely to

​Well we have tried to make it to include build in algebra for the last few
years .. finally we reverted to original basic encoding idea.

I think at this stage the encoding proposed is pretty easy to code.

However the policy of any implementation needs to be able to handle local
actions as well as registered and private types/definitions.

If this it too complicated in practice I do not know. Many people says BGP
is complicated, but for me it is as simple or as complex as one makes it to
be.

But we are open for comments and contributions from everyone here.

> interpret wide bgp communities.

​Indeed .. just like I mentioned above. The use flexibility is in the
policy language and parser. Good news is that current version seems to get
thumbs up from many vendors. ​

> things as simple as possible - but no simpler".

​Not sure I get that one. Are you saying if we follow what you suggest
below it will meet such criteria or regardless it will stay incompatible ?

I do encourage to read the companion draft showing registered types for the
use cases. I am not sure how much simplere those could be ...​

> >      Type  7: User-defined Class list

​Well if you ask me I am all for it. No issue.

​That is also the reason why we demux at the types below the attribute. If
tomorrow someone comes and says I must have floating atoms there is no need
to define new Wide BGP Community attribute with those.

> > 4. Container Type 1: Wide Community

​Just explained above. ​

> >    attribute, and may be present only once in the BGP UPDATE message.

​Not sure what you mean by "parts". The deletion at least the way I see it
should be per type (registered or private) or per attribute. ​

> that this draft introduces.

​Indeed this is vendor dependent.

But should we stop propose anything in BGP if anyone would have a problem
implementing it ? I was under impression that two implementations are
enough for IDR to progress the doc to last call. ​

> 5. I love the idea of UTF8 communities.  On smaller network, these could be

​Yup.​

> allow for proper parameter checking.
​I think you did not read the companion draft :) Please do.

Yes this is one very fundamental use cases here.

Many thx for your comments,
r.​

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 26 Mar 2015 12:33:07 +0000

Hi Robert,

I have a comment to the example in this document:

>9.2.  Example Wide Community Encoding

>     AS_PATH prepend 4 TIMES TO AS 2424, AS 8888, to peers marked as
>     Amsterdam (100) or to peers marked Moscow (104), but not to peers
>     in New York (101).

If  AS 64496 has another peer AS (e.g., AS 10000),  AS 10000 not containing in Target TLV, and also not containing in Exclude Target TLV.
When AS 64496 sends a bgp route to AS 10000, what a policy it will be executed ?
Prepend or not prepend 4 TIMES to peer as 10000?

Maybe I misunderstand the case?

--Shunwan

发件人: Idr [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2015年3月8日 7:09
收件人: idr wg
主题: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt

Name:           draft-raszuk-wide-bgp-communities
Revision:       05
Title:          Wide BGP Communities Attribute
Document date:  2015-03-06
Group:          Individual Submission
Pages:          23
URL:            http://www.ietf.org/internet-drafts/draft-raszuk-wide-bgp-communities-05.txt
Status:         https://datatracker.ietf.org/doc/draft-raszuk-wide-bgp-communities/
Htmlized:       http://tools.ietf.org/html/draft-raszuk-wide-bgp-communities-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-raszuk-wide-bgp-communities-05

Abstract:

The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 26 Mar 2015 16:39:32 +0100

Hello Shunwan,

The expected behaviour when processing such wide community would be not to
execute the prepend to AS 10000.

Of course if you already have other policy permitting such append it will
be executed, but this is outside of the scope.

Cheers,
r.

On Thu, Mar 26, 2015 at 1:33 PM, Zhuangshunwan <[email-masked]>
wrote:

> If  AS 64496 has another peer AS (e.g., AS 10000),  AS 10000 not
> containing in Target TLV, and also not containing in Exclude Target TLV.
>
> *发件人:* Idr [mailto:[email-masked]] *代表 *Robert Raszuk
> *发送时间:* 2015年3月8日 7:09
> *收件人:* idr wg
> *主题:* [Idr] Fwd: New Version Notification for
> draft-raszuk-wide-bgp-communities-05.txt
>
>
>
>
>