Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

["Jakob Heitz (jheitz)" <[e-mail]>]

The reason I went further than that is that with extended messages, it's not just about a speaker and its neighbor anymore, it's about a whole BGP space.

We should probably go further still and say:

BGP speakers that are not using features that specifically require extended messages MUST NOT use extended messages.

Thanks,
Jakob

From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, November 15, 2017 8:03 PM
To: Jakob Heitz (jheitz) <[e-mail]>; Robert Raszuk <[e-mail]>; Susan Hares <[e-mail]>
Cc: idr wg <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

I was thinking of something more along the lines of https://tools.ietf.org/html/rfc7606#section-8 e.g.

§ Guidance for Authors of BGP Specifications

   A document that specifies a new BGP attribute that may not fit in a 4096-octet limit MUST provide specifics

   regarding how to advertise a BGP message larger than 4096 octets to a speaker that does not support Extended Messages. In particular whether the removal of the attribute is allowed/advertised or not. Trade-offs are likely similar to the ones discussed in RFC 7606. In particular, if the
   attribute in question has or may have an effect on route selection or
   installation, the presumption is that removing it is unsafe unless
   careful analysis proves otherwise.

--

“Multi-octet fields MUST be in network byte order.”

Possibly a reference could be added, specifying this “network byte order”. (especially for a MUST)

Thanks,
Regards,
--Bruno

From: Idr [mailto:[e-mail]] On Behalf Of Jakob Heitz (jheitz)
Sent: Thursday, November 16, 2017 3:24 AM
To: Robert Raszuk; Susan Hares
Cc: idr wg; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Good point Robert. How about adding something like:

Certain features used by some BGP speakers require the use of extended messages.
Such features are indicated with a BGP capability.
If a BGP speaker sends an extended message to a second speaker, but that message
does not use a feature that requires extended messages, then the contents of that
message may not be distributed correctly throughout the BGP space to which that content is targeted.
This is because while the immediate neighbor speaker may support extended messages, every
BGP speaker within the said BGP space might not support extended messages.

For example, a certain BGP feature requires the use of a large BGP attribute.
This feature is not supported by every BGP speaker within a BGP space.
BGP updates with the large attribute removed might be acceptable to speakers
that do not support the feature, even though functionality is reduced without the feature.
If such a BGP update is longer than 4096 octets when the
large attribute is removed, then it cannot be distributed to those speakers.

To prevent the failures outlined above, a BGP speaker SHOULD not generate a message
that is longer than 4096 octets if a feature that requires extended messages is not used.
Furthermore, a BGP speaker SHOULD not generate a message that cannot be reduced to
4096 octets or less by another speaker that needs to remove the feature that requires
extended messages.

Thanks,
Jakob

From: Idr [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Wednesday, November 15, 2017 5:56 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: idr wg <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Hi,

I am concerned with the lack of clear description of what router which supports extended msg should do
when on one side he receives an attribute bigger then 4K and not of all it's peers can handle it.

IMO the below statement is true but a bit too vague:

"Therefore putting an attribute which can not be decomposed to 4096 octets or less in an

   Extended Message is a likely path to routing failure.

​"



​And the worst part is that the BGP speaker which in fact generated

such attribute ​

be it on purpose or by error will not find out that its propagation has

failed one or N hops away.



​Today when one is trying to inject msg over 4K (say due to a bug) it will fail locally,

generate syslog etc ... ​





Any comments from authors and WG on that ?



Thx,

R.









​

On Sun, Nov 12, 2017 at 11:47 PM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
This begins a 2 week WG LC for draft-ietf-idr-bgp-extended-messages (11/12 to 11/26).  Please note this draft has at least 2 implementations.    Please comment on whether you feel this draft is ready for publication.

Susan Hares

PS – the request for this WG LC is at:
https://www.ietf.org/mail-archive/web/idr/current/msg18801.html







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


_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.