Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

[Robert Raszuk <[e-mail]>]

Hi Sriram,

Well there are other uses for larger BGP message size.

Some claim that very long AS_PATH prepend happens today.

Yet some other folks would like to use flow spec with a lot of policy to be
pushed around (for example some ACLs can be very very long today).

So once we open this road and let large tracks on it we can't have pieces
of it to remain narrow (unless those wide roads are under private walls)
and gateways out of those private ASes can handle it.

Best,
R.





On Wed, May 25, 2016 at 10:21 PM, Sriram, Kotikalapudi (Fed) <
[e-mail]> wrote:

> Robert,
>
> >I listed 4 alternative solutions earlier in this thread already :).
> >Dropping NLRI no matter how rare it would be is not one of them.
>
> I don't know what other BGP protocol enhancements would
> ever need to use extended message;
> but so far we know that BGPsec "may" need to use it
> (though very rarely, if ever) -- see note below**.
> And it seems clear that BGPsec would never need to drop the NLRI
> (including when the peer has not negotiated extended message capability).
> This is because it is designed so that a BGPsec speaker can convert a
> BGPsec
> update with path signatures to an unsigned BGP message (for forwarding).
> BGPsec speaker can/will certainly do this conversion under these
> two circumstances that matter for this discussion:
> 1. The BGPsec message (that is being forwarded) has a size larger than
> 4096,
> and the peer has not negotiated extended message capability.
> 2.  The peer has negotiated BGP capability but not BGPsec capability.
>
>
> **Note about BGPsec update size: A BGPsec message size
> can exceed 4096 octets if there are 40 or more unique ASes
> in the AS path (given that each AS's signature size is no more than
> 72 octets with the ECDSA P-256 algorithm).
> The currently seen Maximum AS Path Length (eliminating prepends) is 15
> http://bgp.potaroo.net/as6447/
>
> Sriram
>