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

[Robert Raszuk <[e-mail]>]

Hi Nick,

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.
>

​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.


> 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.
>

​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. ​


> Overall, this is not compatible with the engineering principal of "keep
> 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 ...​

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
>

​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.


> 2. Simplify, or at least explain why this needs needs to be so complicated:
>
> > 4. Container Type 1: Wide Community
>

​Just explained above. ​


> 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.
>

​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. ​

> 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.
>

​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
> a real win.
>

​Yup.​

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.
>
>
​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.​







> Nick
>