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

["Keyur Patel (keyupate)" <[e-mail]>]

Hi Robert,

There are Implementations that provide an ability of selectively dropping attributes as part of error handling solution.  We could add text that suggests the same.

However, dropping optional transitive attributes (in a somewhat random fashion or based on their size) without a knowledge of network operator MAY result in partial deployment of such attributes and its features and could have other issues in itself!

Regards,
Keyur

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, May 25, 2016 at 9:04 AM
To: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Cc: "Acee Lindem (acee)" <[e-mail]<mailto:[e-mail]>>, Bruno Decraene <[e-mail]<mailto:[e-mail]>>, Susan Hares <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)


I listed 4 alternative solutions earlier in this thread already :). Dropping NLRI no matter how rear it would be is not one of them.

Your solution is not going to work in practice if extended msg is cap negotiated on by default (after upgrade) as there always be speakers which get upgraded later (if at all).

Rgs,
r.



On Wed, May 25, 2016 at 6:00 PM, Keyur Patel (keyupate) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

Comments inlined #Keyur1

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, May 25, 2016 at 8:54 AM
To: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Cc: "Acee Lindem (acee)" <[e-mail]<mailto:[e-mail]>>, Bruno Decraene <[e-mail]<mailto:[e-mail]>>, Susan Hares <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)


​You missed the scenario I am afraid :)

R1 --- RR --- R2


R1 and RR support extended message ... R2 does not.

So R1 sends to RR NLRI with attributes exceeding 4K as he has no clue who is behind RR and what they support.

How RR is supposed to pass this prefix with bunch of attributes larger then 4K to R2 ?

#Keyur1: IMHO, by enabling extended messages on R2. ;)

Whats the alternative to “enabling extended messages” so that the prefix with attribute size larger than 4K is delivered to R2? :)

Regards,
Keyur



Best,
R.
​

On Wed, May 25, 2016 at 5:51 PM, Keyur Patel (keyupate) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

I thought the context of that line “not generating single NLRI if attributes exceed 4K” was for peers not supporting extended messages.

Otherwise its a moot point. :)
Regards,
Keyur

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, May 25, 2016 at 8:48 AM
To: Keyur Patel <[e-mail]<mailto:[e-mail]>>, "Acee Lindem (acee)" <[e-mail]<mailto:[e-mail]>>
Cc: Bruno Decraene <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)


Additionally, we could discourage the generation of a single NLRI exceeding 4K.

#Keyur: Yep. I agree. :)

​The entire idea for this draft was triggered by the fear that BGPSec may not fit to 4K update msg.

The draft explicitly states so as a motivation for this work.

Section 1

   "As BGP is extended to support newer AFI/SAFIs and newer capabilities (e.g.,
   [I-D.ietf-sidr-bgpsec-overview]), there is a need to extend the maximum message
   size beyond 4096 octets."

​Now in turn the referenced draft clearly defines that NLRI will only contain single prefix:

Section 3.2

   "When a BGP speaker originates a BGPsec update message, it creates a
   BGPsec_Path attribute containing a single signature. The signature
   protects the Network Layer Reachability Information (NLRI), the AS
   number of the originating AS, and the AS number of the peer AS to
   whom the update message is being sent. Note that the NLRI in a BGPsec
   update message is restricted to contain only a single prefix."

Question:

​So what exactly are we to discourage here because clearly not "generation of single NLRI exceeding 4K" ?

Maybe deployment of BGPSec till all BGP routers in the world support this new extended message size ?

Thx,
R.
​

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