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) <keyupate@cisco.com>
wrote:

> Hi Robert,
>
> Comments inlined #Keyur1
>
> From: Robert Raszuk <robert@raszuk.net>
> Date: Wednesday, May 25, 2016 at 8:54 AM
> To: Keyur Patel <keyupate@cisco.com>
> Cc: "Acee Lindem (acee)" <acee@cisco.com>, Bruno Decraene <
> bruno.decraene@orange.com>, Susan Hares <shares@ndzh.com>, "idr@ietf.org"
> <idr@ietf.org>
> 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) <
> keyupate@cisco.com> 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 <robert@raszuk.net>
>> Date: Wednesday, May 25, 2016 at 8:48 AM
>> To: Keyur Patel <keyupate@cisco.com>, "Acee Lindem (acee)" <
>> acee@cisco.com>
>> Cc: Bruno Decraene <bruno.decraene@orange.com>, "idr@ietf.org" <
>> idr@ietf.org>, Susan Hares <shares@ndzh.com>
>> 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
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>>
>