Subject: [Idr] draft-ymbk-bgp-extended-messages-01

From: Robert Raszuk <[email-masked]>
Date: Tue, 15 Mar 2011 09:36:55 +0100

Hi,

I would like to propose an amendment to the below document:

Title : Extended Message support for BGP
http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01

The document increases the max message size of BGP from 4096 octets to 
65535 octets. I agree that this is a good general idea.

However it follows the same notion as base spec and defines single max 
message size for all possible types of BGP messages.

As it has been previously recognized during WG meetings as well as on 
the list there are number of legitimate cases where during an error 
condition (for example: malformed UPDATE Msg, malformed BGP Attribute 
within UPDATE Msg etc ...) we should maintain a session's liveness while 
in the same time report the error condition to a peer.

Within the BGP build-in reporting facilities some operators found it 
valuable to be able to include the entire malformed UPDATE message to 
the peer who generated it to increase the awareness of the problem at 
hand as well as speed up the troubleshooting process.

This will be only possible if we differentiate maximum size of BGP 
UPDATE Massage to be less then any other BGP message's maximum size to 
allow room for a new message header. For all practical purposes it seems 
sufficient to allow the header size of 128 octets.

I welcome comments and opinions on the proposed above BGP messages size 
differentiation.

Best regards,
R.

---

From: "iLya" <[email-masked]>
Date: Thu, 17 Mar 2011 13:28:58 +0100

--------------------------------------------------
> 65535 octets. I agree that this is a good general idea.
[...]
> This will be only possible if we differentiate maximum size of BGP UPDATE 
> Massage to be less then any other BGP message's maximum size to allow room 
> for a new message header. For all practical purposes it seems sufficient 
> to allow the header size of 128 octets.
>

>From operator's perspective ability to return complete UPDATE message inside 
a diagnostic message is essential. So I support the proposal of limiting 
UPDATE Message length to something smaller than general MAX_SIZE. Whether it 
should be less by 128 octects or by some other value I'm not yet sure.

Kind regards,
iLya

---

From: "iLya" <[email-masked]>
Date: Thu, 17 Mar 2011 13:34:26 +0100

> http://tools.ietf.org/html/draft-ymbk-bgp-extended-messages-01

Section 2 reads: "...This is an asymmetric capability.  I.e. one speaker 
could signal the capability and the other not..".

If one side does not signal capability then it may not prepared to receive 
messages longer than original specification dictates. In other words, even 
for asymmetric flow of big (>4096) messages both sides need to have support 
and announce that. Perhaps having 'receive' and 'send' flags in capability 
value and requiring each side to advertise new capability would be better 
approach than sending big messages to a speaker that didn't advertise 
'extended messages' capability.

Kind regards,
iLya

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 17 Mar 2011 09:40:03 -0400

if one speaker can send long, but the peer can not, then that peer can not include the (long) malformed update in his (short) notification. 

--
Jakob Heitz.

On Mar 17, 2011, at 5:34 AM, "iLya" <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "iLya" <[email-masked]>
Date: Thu, 17 Mar 2011 15:00:31 +0100

> if one speaker can send long, but the peer can not, then that peer can not 
> include the (long) malformed update in his (short) notification.
>

indeed, so it makes asymmetric case kind of impossible.

Cheers,
iLya

---

From: Jie Dong <[email-masked]>
Date: Fri, 18 Mar 2011 01:19:56 +0000

Hi iLya, 

Section 2 says: 
"By advertising the BGP Extended message Capability to a peer, a BGP speaker conveys to that peer that the speaker is capable of receiving and properly handling BGP Extended Messages."
Hence the big messages would only be sent to peers which advertised this capability.

To my understanding, this asymmetric capability negotiation implicates that a speaker which did not advertise this capability could encapsulate and send big messages to peers which advertised this capability, while itself is not willing to receive big messages. 

Agree that using 'receive' and 'send' flags may make this negotiation clearer.

Regards,
Jie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of iLya
> Sent: Thursday, March 17, 2011 8:34 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code)
>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 18 Mar 2011 03:22:22 -0400

That's why capability split to send/receive would make sense

Regards,
Jeff  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jakob Heitz
Sent: Thursday, March 17, 2011 06:40
To: iLya
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code)

--
Jakob Heitz.

---

From: Keyur Patel <[email-masked]>
Date: Fri, 18 Mar 2011 08:04:22 -0700

Ilya,

I am not sure what we would gain by having "send" and "receive" flags. All
you need to know is if your peer is capable of receiving longer messages or
not so as to not drop the session!

Regards,
Keyur

---

From: Enke Chen <[email-masked]>
Date: Fri, 18 Mar 2011 14:35:41 -0700

Hi, folks:

How about adding the some text to reconcile the possible size 
differences between an original message and any feedback messages:

----------------------------------
In order for a BGP speaker to be able to receive a notification or some 
other diagnostic message
containing an original BGP message sent by the speaker, it is RECOMMEND 
that a BGP speaker
limit the size to (65535 - 4096) for messages that it sends to a peer 
that has advertised the capability.
---------------------------------

Regards,   -- Enke

On 3/18/11 8:04 AM, Keyur Patel wrote:
> On 3/17/11 4:34 AM, "iLya"<[email-masked]>  wrote:
>
>

---

From: Keyur Patel <[email-masked]>
Date: Fri, 18 Mar 2011 14:47:57 -0700

Enke,

Most definitely! This should cover Diagnostic message and any other message
types that would require some kind of feedback mechanism back to the BGP
speaker that originated the message.

Regards,
Keyur

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 18 Mar 2011 18:10:04 -0400

+1

Regards,
Jeff  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Enke Chen
Sent: Friday, March 18, 2011 14:36
To: Keyur Patel
Cc: [email-masked]
Subject: Re: [Idr] draft-ymbk-bgp-extended-messages-01 (capability code)

Hi, folks:

Regards,   -- Enke