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

From: "Susan Hares" <[email-masked]>
Date: Sun, 12 Nov 2017 17:47:38 -0500

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

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 15 Nov 2017 13:11:39 +0000

Susan Hares 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.  

looks good.  Please publish.

Nick

---

From: Job Snijders <[email-masked]>
Date: Wed, 15 Nov 2017 14:16:00 +0100

Susan Hares wrote:
> implementations.

The implementation report is available here:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

> Please comment on whether you feel this draft is ready for publication.

I support publication.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 15 Nov 2017 14:56:01 +0100

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 <[email-masked]> wrote:

> (11/12 to 11/26).  Please note this draft has at least 2 implementations.
> PS – the request for this WG LC is at:
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 15 Nov 2017 19:24:12 +0000

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:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, November 15, 2017 5:56 AM
To: Susan Hares <[email-masked]>
Cc: idr wg <[email-masked]>; [email-masked]; [email-masked]
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.

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

​"

such attribute ​

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

Thx,

R.

​

On Sun, Nov 12, 2017 at 11:47 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> 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

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

---

From: heasley <[email-masked]>
Date: Thu, 16 Nov 2017 03:43:49 +0000

> 4096 octets or less by another speaker that needs to remove the feature that requires

A feature that requires large attributes would also require extended messages
and if the capabilities do not reflect both, I expect the open would fail and
the capability would be excluded subsequently.  Are there features requiring
extended communities that are not themselves represented by a capability?
Implying that those attributes would naturally be removed, leaving the normal
reduction of NLRI to fit within the former msg limit?

not that some manner of feedback is not necessary.  a route could contain a
mix of community attributes leading it to exceed the former msg limit.  And
4271 offers no direction for that case either.  I expect the update to be
discarded and a trap and syslog is generated, but I do not know.

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 04:03:22 +0000

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

Thanks,
Jakob

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

Hi,

​"

such attribute ​

Thx,

R.

​

Susan Hares

_________________________________________________________________________________________________________________________

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 16 Nov 2017 05:44:36 +0000

Hi Bruno,

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 15, 2017 at 11:03 PM
To: "Jakob Heitz (jheitz)" <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

--

Note that Network-Byte Order is the standard for IETF documents and at least I don’t think it needs to be specified in every document with packet encodings. See section 3.1 of https://www.ietf.org/rfc/rfc2360.txt

Thanks,
Acee

Thanks,
Regards,
--Bruno

Cc: idr wg; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Thanks,
Jakob

Hi,

​"

such attribute ​

Thx,

R.

​

Susan Hares

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 05:51:48 +0000

Hi Acee

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Thursday, November 16, 2017 1:45 PM
To: DECRAENE Bruno IMT/OLN; Jakob Heitz (jheitz); Robert Raszuk; Susan Hares
Cc: idr wg; [email-masked]; [email-masked]
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Hi Bruno,

--

[Bruno] Sure, the sentence may also be removed.

Thanks
--Bruno

Thanks,
Acee

Thanks,
Regards,
--Bruno

Thanks,
Jakob

Hi,

​"

such attribute ​

Thx,

R.

​

Susan Hares

Thank you.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 16 Nov 2017 06:08:59 +0000

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

--

Thanks,
Regards,
--Bruno

Thanks,
Jakob

Hi,

​"

such attribute ​

Thx,

R.

​

Susan Hares

Thank you.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 16 Nov 2017 06:11:28 +0000

RFC 4271 does not address the issue, because at the time there were no features that required messages longer than 4096 octets. Exceeding the maximum message length just didn't happen. Now, it needs to be addressed.

Thanks,
Jakob

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Nov 2017 14:33:21 +0800

> 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.

< bitchiness, it's been two weeks in s'pore >

the original extended messages draft was restricted to update messages
for the purpose of bgpsec.  and bgpsec required it.  and when bgpsec
hits a neighbor which does not speak bgpsec, it strips all the crypto
bloat and then the update fits in 4095 as it is the same as today.  this
was not an accident.

but the idr wg, it its tradition of embellishment, asked for other
messages to be extended (some suggested open be extended too, a real
rat-hole).  well, bright folk, you want it, you figure it out.  send
text.  and small simple text, < 500 words.  if you can not keep it
simple, that should tell you something.

rndy

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Nov 2017 01:55:25 -0500

WG:
[WG chair hat on] 

+1 - to randy request to send text.  We've been through this draft before.
Positive proposals that are brief will really help move this draft forward.

[WG chair hat askew] -- it's been 7 days in Singapore with great network
connectivity..  

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Thursday, November 16, 2017 1:33 AM
To: Jakob Heitz
Cc: Interminable Discussion Room
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
(11/12 to 11/26)

the original extended messages draft was restricted to update messages for
the purpose of bgpsec.  and bgpsec required it.  and when bgpsec hits a
neighbor which does not speak bgpsec, it strips all the crypto bloat and
then the update fits in 4095 as it is the same as today.  this was not an
accident.

but the idr wg, it its tradition of embellishment, asked for other messages
to be extended (some suggested open be extended too, a real rat-hole).
well, bright folk, you want it, you figure it out.  send text.  and small
simple text, < 500 words.  if you can not keep it simple, that should tell
you something.

rndy

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Nov 2017 15:03:11 +0800

> Note that Network-Byte Order is the standard for IETF documents and at
> least I don’t think it needs to be specified in every document with
> packet encodings. See section 3.1 of
> https://www.ietf.org/rfc/rfc2360.txt

yay!  i can remove text.  ty

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 08:59:56 +0100

Indeed this is the problem.

My main concern is not about use by new attributes/apps which may not fit
4k msg and which can define what to do when mismatch occurs.

My concern is on the lack of clear definition on what a BGP speaker should
do 5 hops away from the sender when it receives say Extended Community or
Large Community attributes of the size of 6k ? Maybe due to a bug or attack
or xyz ...

Sometimes it is save to drop just such attribute sometimes it is not even
considering currently shipping attributes. And regardless if the attribute
is dropped or entire update is dropped the real sender will have no clue
about it.

As far as proposing text .. one practical option I see which will allow to
introduce extended msg without risk of breaking current networks would be
to define a new BGP message type: "BGP LARGE UPDATE MSG".

You still have the same problem there of handling support between new and
old peers, but at least you are not potentially  breaking what works today
nor are introducing new attack vectors to existing deployments.

//R.

On Nov 16, 2017 14:09, "Jakob Heitz (jheitz)" <[email-masked]> wrote:

> 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.
>
>
>
> BGP speakers that are not using features that specifically require
> extended messages MUST NOT use extended messages.
>
>
>
> Thanks,
>
> Jakob
>
>
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Wednesday, November 15, 2017 8:03 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>; Robert Raszuk <
> [email-masked]>; Susan Hares <[email-masked]>
> *Cc:* idr wg <[email-masked]>; [email-masked]; [email-masked]
> *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.
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Jakob Heitz (jheitz)
> *Sent:* Thursday, November 16, 2017 3:24 AM
> *To:* Robert Raszuk; Susan Hares
> *Cc:* idr wg; [email-masked]; [email-masked]
> *Subject:* Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Wednesday, November 15, 2017 5:56 AM
> *To:* Susan Hares <[email-masked]>
> *Cc:* idr wg <[email-masked]>; [email-masked]; [email-masked]
> *Subject:* Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> Hi,
>
>
>

---

From: Job Snijders <[email-masked]>
Date: Thu, 16 Nov 2017 13:17:15 +0100

> to define a new BGP message type: "BGP LARGE UPDATE MSG".

How is a new BGP message type any different than negotiating through a
capability whether an extended message can be handled by the peer.

> You still have the same problem there of handling support between new
> and old peers, but at least you are not potentially  breaking what
> works today nor are introducing new attack vectors to existing
> deployments.

I'm not sure I follow your reasoning. 

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 16 Nov 2017 14:09:01 +0100

On Wed, Nov 15, 2017 at 02:56:01PM +0100, Robert Raszuk wrote:
> 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.
> 
> "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 ... 
> 

Let's not forget this draft idea has been around since 2011. To prevent
path / routing failures, we'd better get a move on and start deplying.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 16 Nov 2017 14:15:11 +0100

> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations

It appears that BIRD also has an implementation. (I have not tested it,
so I won't add it myself to the implementation wiki page)

    """
    enable extended messages [switch]

    The BGP protocol uses maximum message length of 4096 bytes. This
    option provides an extension to allow extended messages with length
    up to 65535 bytes. Default: off.
    """
    http://bird.network.cz/?get_doc&f=bird-6.html#ss6.3

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Nov 2017 14:28:51 +0100

> capability whether an extended message can be handled by the peer.

​Because it is not about what your peer can handle. It is about what *all*
BGP speakers can handle and what to do when you get to narrow street with
this truck.

it is mainly about not breaking what works today as discussed already when
someone will send 5K of Large Community Attribute.
​
​Maybe rather then new message the draft could simply say that none of
existing BGP Attributes (defined before this RFC goes out) MUST ever exceed
4K in total and only the new attributes will ​be allowed to be big if they
want - then I am happy to keep all in current UPDATE msg type. And the new
fat attributes specs as Bruno suggested must describe on their own how to
handle peers with only 4K messages.

Peace ?

Cheers,
R.

PS. The fact that spec been around from 2011 and has no major
implementation (Cisco, Arista, Juniper, Nokia etc..) does not really help
...

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 16 Nov 2017 20:00:24 +0000

Yes, extended-messages was originally proposed, because bgpsec required it.
However, it doesn't anymore, because it is now using a shorter signature than before.
https://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-23.txt

There are some cases in EVPN that require lots of extended communities to be sent.
This is why in my proposed text, I said "feature" not "capability".

Thanks,
Jakob

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2017 10:33 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Interminable Discussion Room <[email-masked]>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

rndy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Nov 2017 17:04:53 +0100

Hi Jakob,

So if this is no longer needed for bgpsec perhaps you can share with IDR
what type of cargo BESS cooked for BGP transport jets to now carry ?

Millions of MAC addresses packed into extended communities ? Something
worse ?

Thanks a lot,
Robert.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 17 Nov 2017 18:22:28 +0000

The ethernet auto-discovery route carries a route target for every EVI on the ethernet segment.
There can be a lot of EVIs sharing an ethernet segment. You can get over 4000 vlans on an ethernet.
This was a few years ago. Not sure if it's been fixed.

Thanks,
Jakob

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, November 17, 2017 8:05 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Interminable Discussion Room <[email-masked]>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Hi Jakob,

So if this is no longer needed for bgpsec perhaps you can share with IDR what type of cargo BESS cooked for BGP transport jets to now carry ?

Millions of MAC addresses packed into extended communities ? Something worse ?

Thanks a lot,
Robert.

On Thu, Nov 16, 2017 at 9:00 PM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
Yes, extended-messages was originally proposed, because bgpsec required it.
However, it doesn't anymore, because it is now using a shorter signature than before.
https://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-23.txt

Thanks,
Jakob

-----Original Message-----
From: Randy Bush [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 15, 2017 10:33 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Cc: Interminable Discussion Room <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

rndy

---

From: Job Snijders <[email-masked]>
Date: Fri, 17 Nov 2017 19:55:05 +0100

Hi Robert,

On Thu, Nov 16, 2017 at 02:28:51PM +0100, Robert Raszuk wrote:
> > How is a new BGP message type any different than negotiating through
> > a capability whether an extended message can be handled by the peer.
> 
> Because it is not about what your peer can handle. It is about what
> *all* BGP speakers can handle and what to do when you get to narrow
> street with this truck.
> 
> it is mainly about not breaking what works today as discussed already
> when someone will send 5K of Large Community Attribute.
>
> Maybe rather then new message the draft could simply say that none of
> existing BGP Attributes (defined before this RFC goes out) MUST ever
> exceed 4K in total and only the new attributes will be allowed to be
> big if they want - then I am happy to keep all in current UPDATE msg
> type. And the new fat attributes specs as Bruno suggested must
> describe on their own how to handle peers with only 4K messages.
> 
> Peace ?

This is an interesting angle. Your proposal allows for the specification
(and hopefully more code) to start shipping, and at a later point the
flood gates can be opened (for 'old world' attributes) if the WG deems
tjat appropiate.

Proposed text:

----
OLD:
    A BGP announcement will, in the normal case, propagate throughout
    the BGP speaking Internet; and there will undoubtedly be BGP
    speakers which do not have the Extended Message capability.
    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.
   
NEW:
    A BGP announcement will, in the normal case, propagate throughout
    the BGP speaking Internet; and there will undoubtedly be BGP
    speakers which do not have the Extended Message capability.
    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.

    It is RECOMMENDED that BGP protocol developers and implementers are
    conservative in their application and use of Extended Messages.
    Future protocol specifications will need to describe how to handle
    peers which can only accomodate 4096 octet messages.
----

Kind regards,

Job

ps. Since I don't think we can say "we'll never need larger than 4096",
I think it is important to get this one shipped. The curious thing is
that we'll need to have code deployed in the wild, _before_ any
application can start using it. The WG LC is about a reasonable proposal
to bump the limit in a way that is incrementally deployable (e.g.
capability negotated).

---

From: Randy Bush <[email-masked]>
Date: Sun, 19 Nov 2017 08:48:43 +0700

> However, it doesn't anymore, because it is now using a shorter signature

this statement is untrue

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 19 Nov 2017 06:04:33 +0000

Look for “extended” in this diff. All references to extended messages were removed in draft 23.
https://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-23.txt

Thanks,
Jakob.

On Nov 18, 2017, at 5:48 PM, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:

Yes, extended-messages was originally proposed, because bgpsec required it.
However, it doesn't anymore, because it is now using a shorter signature
than before.

this statement is untrue

---

From: Randy Bush <[email-masked]>
Date: Sun, 19 Nov 2017 13:36:11 +0700

> https://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-23.txt

to get it past the normative ref problem as extended messages was stuck
in the idr <bleep>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 19 Nov 2017 09:03:17 +0000

As you said in an email thread entitled [Sidrops] [sidr] BGPsec draft and extended messages. However, you were overruled by reason and I quote from the thread:

BGPsec_Path attribute size does not exceed 4K.

ECDSA P-256 signature size is 64 bytes.

So, #bytes added to BGPsec_Path are about 100 bytes per AS.

Extended message was thought to be needed when RSA-2048 (256 bytes sig) was initially proposed.

With P-256, BGPsec_Path attribute does not exceed 4K up to 40 ASes in the path.

(Note: AS prepends are compressed out due to use of pCount.)

In the Internet, the observed maximum AS path length is 14 [Huston].

The maximum AS path length has remained in this ball park for many years now.

Therefore, it doesn’t appear that “dropping back to “insecure on account of

the size of the update”  would happen in practice.

Thanks,
Jakob.

On Nov 18, 2017, at 10:36 PM, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:

Look for “extended” in this diff. All references to extended messages
were removed in draft 23.
https://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-23.txt

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 19 Nov 2017 23:04:50 +0100

Hi Job,

The new proposed text is an improvement, but it still does not describe
what a BGP speaker should do when receiving any existing attribute (say
extended community) packed with RTs exceeding in total 4K and needs to send
it to "old" peer.

IMO we do need to define the recommended behavior before we progress this
to RFC. Just like we did so in migration to 4 octet AS in rfc6793.

Possible options:

1. Drop the update (bit ugly as such drop will be silent .. other then
local syslog/error report)

2. Drop the big attribute and insert defined here standard community or
some other marker indicating MSG_TRUNCATED info.

More ?

Thx,
R.

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 21 Nov 2017 10:26:35 +0000

Hello Everyone,

I support the draft; and I therefore implemented it on ExaBGP master.

I am will keep an eye on the discussion regarding the potential issue transiting messages with larger than 4k total attributes size could cause. 

I would have no objection myself on seeing an arbitrary limit on the Total Path Attribute set to prevent backward compatibility as the most likely quick win is going to be on packing more NLRI ATM.

That said, I am not aware of any guideline in previous RFC to cover this issue and it is already possible to encounter this problem today. So while the draft make the issue more likely, it does not make things worse from a specification POV.

I am therefore wondering if this should not be covered by another unrelated RFC as it can affect current speakers and is not specific to this draft.

Sincerely,

Thomas

> On 12 Nov 2017, at 22:47, Susan Hares <[email-masked]> wrote:
> 
> https://www.ietf.org/mail-archive/web/idr/current/msg18801.html <https://www.ietf.org/mail-archive/web/idr/current/msg18801.html>
>  
>  
>  
>  
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Nov 2017 15:22:48 +0100

Hi Thomas,

Great that you implemented it in ExaBGP. Is it on by default or do you need
a global/per peer knob ?

- - -

As to your point that even today you may have the same problem ... well if
you consider the problem to be interworking between peers when one is
already receiving 4K update and want to add more stuff ... you are right it
can fail today.

But this is not the main problem I am pointing out. The problem is that in
the above case the local guy who is adding stuff to existing update will
locally and immediately know that it failed.

In the new model it is nodes far far away who happily injected larger then
4K update messages will never know that their updates never made it through
as they intended.

And since IDR and community failed to progress OPERATIONAL MSG in BGP
providing a bit of a ops feedback between peers and perhaps beyond we are
where we are. https://goo.gl/JTpQDc

Best,
Robert.

On Tue, Nov 21, 2017 at 11:26 AM, Thomas Mangin <[email-masked]>
wrote:

> I am will keep an eye on the discussion regarding the potential issue
> transiting messages with larger than 4k total attributes size could cause.
>
> I would have no objection myself on seeing an arbitrary limit on the Total
> Path Attribute set to prevent backward compatibility as the most likely
> quick win is going to be on packing more NLRI ATM.
>
> That said, I am not aware of any guideline in previous RFC to cover this
> issue and it is already possible to encounter this problem today. So while
> the draft make the issue more likely, it does not make things worse from a
> specification POV.
>
> I am therefore wondering if this should not be covered by another
> unrelated RFC as it can affect current speakers and is not specific to this
> draft.
>
> Sincerely,
>
> Thomas
>

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 21 Nov 2017 14:56:45 +0000

Hello Robert,

As this is a capability, it is an option to be enabled per neighbour.

I thought it made sense to give the user control of this option: one may not want to enable the feature - and therefore they should be able to do so IMHO.

Thomas

> On 21 Nov 2017, at 14:22, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Thomas,
> 
> Great that you implemented it in ExaBGP. Is it on by default or do you need a global/per peer knob ? 
> 
> - - - 
> 
> As to your point that even today you may have the same problem ... well if you consider the problem to be interworking between peers when one is already receiving 4K update and want to add more stuff ... you are right it can fail today. 
> 
> But this is not the main problem I am pointing out. The problem is that in the above case the local guy who is adding stuff to existing update will locally and immediately know that it failed. 
> 
> In the new model it is nodes far far away who happily injected larger then 4K update messages will never know that their updates never made it through as they intended.
> 
> And since IDR and community failed to progress OPERATIONAL MSG in BGP providing a bit of a ops feedback between peers and perhaps beyond we are where we are. https://goo.gl/JTpQDc <https://goo.gl/JTpQDc>
> 
> Best,
> Robert.
> 
> 
> On Tue, Nov 21, 2017 at 11:26 AM, Thomas Mangin <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Everyone,
> 
>> On 12 Nov 2017, at 22:47, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Nov 2017 16:03:32 +0100

My take would be to make it enabled by default (potentially with a knob to
disable it if needed) .. otherwise we are creating even worse swiss cheese
even among those implementations which do support it.

Thx,
R.

On Tue, Nov 21, 2017 at 3:56 PM, Thomas Mangin <[email-masked]>
wrote:

> I thought it made sense to give the user control of this option: one may
> not want to enable the feature - and therefore they should be able to do so
> IMHO.
>
> Thomas
>
>> I would have no objection myself on seeing an arbitrary limit on the
>> Total Path Attribute set to prevent backward compatibility as the most
>> likely quick win is going to be on packing more NLRI ATM.
>>

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 21 Nov 2017 15:09:55 +0000

Hello Robert,

> But this is not the main problem I am pointing out. The problem is that in the above case the local guy who is adding stuff to existing update will locally and immediately know that it failed. 

I understand this is the same transitive issue we saw with ASN4 in the past where the failure is occurring a few routers away. 

That said should I send a peer an update of exactly 4096 bytes, how would they propagate it to its peers / transit and prepend their own ASN without breaking their session ? So I think that the issue is still not limited to this draft.

As the behaviour can happen without the draft - to be honest my own code suffers from this bug and I will be fixing it today -  it would cause the same remote flapping as seen with ASN.

This case is not covered by RFC 7606 for “thread-as-withdraw” ? Perhaps time for some code audit by everyone ...

> And since IDR and community failed to progress OPERATIONAL MSG in BGP providing a bit of a ops feedback between peers and perhaps beyond we are where we are. https://goo.gl/JTpQDc <https://goo.gl/J…
I agree that having way to share implementation limitation (like max rib size, etc.) is something that should perhaps be discussed again .. 
Different thread for a different day :-)

Thomas

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 21 Nov 2017 15:21:47 +0000

Your wish is my command: done !
https://github.com/Exa-Networks/exabgp/commit/80612f0cef940d8f8b03b16f543c9173615188c5 <https://github.com/Exa-Networks/exabgp/commit/80612f0cef940d8f8b03b16f543c9173615188c5>

Thomas

> On 21 Nov 2017, at 15:03, Robert Raszuk <[email-masked]> wrote:
> 
> 
> My take would be to make it enabled by default (potentially with a knob to disable it if needed) .. otherwise we are creating even worse swiss cheese even among those implementations which do support it. 
> 
> Thx,
> R.
> 
> On Tue, Nov 21, 2017 at 3:56 PM, Thomas Mangin <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Robert,
> 
>> On 21 Nov 2017, at 14:22, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Thomas,
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Nov 2017 16:25:25 +0100

Cool :)

Care to add ExaBGP to the wiki ?

Thx,
R.

On Tue, Nov 21, 2017 at 4:21 PM, Thomas Mangin <[email-masked]>
wrote:

> https://github.com/Exa-Networks/exabgp/commit/
> 80612f0cef940d8f8b03b16f543c9173615188c5
>
>
> Thomas
>
>> As to your point that even today you may have the same problem ... well
>> if you consider the problem to be interworking between peers when one is
>> But this is not the main problem I am pointing out. The problem is that
>> in the above case the local guy who is adding stuff to existing update will
>> In the new model it is nodes far far away who happily injected larger
>> then 4K update messages will never know that their updates never made it
>> through as they intended.
>>
>> On Tue, Nov 21, 2017 at 11:26 AM, Thomas Mangin <[email-masked]
>> > wrote:
>>
>>> Hello Everyone,
>>>

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 21 Nov 2017 16:03:04 +0000

Robert,

I do not have a login

1	Yes
2	Yes
3	Yes
4a	Yes
4b	Yes
5a	You can send extended UPDATE . So No ?
5b	Yes

Thomas

> On 21 Nov 2017, at 15:25, Robert Raszuk <[email-masked]> wrote:
> 
> Cool :) 
> 
> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations <https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations>
> 
> Thx,
> R.
> 
> On Tue, Nov 21, 2017 at 4:21 PM, Thomas Mangin <[email-masked] <mailto:[email-masked]>> wrote:
>> On 21 Nov 2017, at 15:03, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Nov 2017 17:16:38 +0100

Done ! I filled the report for you :).

5a is answering the question in 5 so I said Yes - Clearly if there is no
support no capability will be sent :) Confusing a bit ...

Cheers,
R.

On Tue, Nov 21, 2017 at 5:03 PM, Thomas Mangin <[email-masked]>
wrote:

>> https://github.com/Exa-Networks/exabgp/commit/80612f0cef940d
>> 8f8b03b16f543c9173615188c5
>>
>>
>> Thomas
>>
>> My take would be to make it enabled by default (potentially with a knob
>> to disable it if needed) .. otherwise we are creating even worse swiss
>> cheese even among those implementations which do support it.
>>
>> Thx,
>> R.
>>
>>> On Tue, Nov 21, 2017 at 11:26 AM, Thomas Mangin <
>>> [email-masked]> wrote:
>>>
>>>> Hello Everyone,
>>>>
>>>> That said, I am not aware of any guideline in previous RFC to cover
>>>> this issue and it is already possible to encounter this problem today. So
>>>> while the draft make the issue more likely, it does not make things worse
>>>> from a specification POV.
>>>>

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 21 Nov 2017 16:21:16 +0000

> On 21 Nov 2017, at 15:09, Thomas Mangin <[email-masked]> wrote:
> 
> This case is not covered by RFC 7606 for “thread-as-withdraw” ? Perhaps time for some code audit by everyone …

Oh crap !
https://github.com/Exa-Networks/exabgp/commit/68e719ce821f075c3d80de085e920e37a0c25bdf <https://github.com/Exa-Networks/exabgp/commit/68e719ce821f075c3d80de085e920e37a0c25bdf>

Thomas

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Nov 2017 16:21:22 +0000

> even among those implementations which do support it.

+ 1 to this.

I’m working on another open source implementation that will have this
enabled by default as well.

Seems sensible if all vendors would take that approach.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Nov 2017 17:23:13 +0100

I don't know why this is not spelled out in the draft ....

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Nov 2017 17:35:30 +0000

Robert/Randy,

About this being a default:

Old (Section 4):

A BGP speaker that is willing to send and receive BGP Extended Messages
with a peer SHOULD advertise the BGP Extended Message Capability to the
peer using BGP Capabilities Advertisement RFC5492].

New (Section 4)

A BGP speaker that is capable to send and receive BGP Extended Messages
with a peer SHOULD advertise the BGP Extended Message Capability to the
peer using BGP Capabilities Advertisement [RFC5492].

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Nov 2017 19:40:43 +0100

Great !

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 21 Nov 2017 22:38:54 +0000

The new update message size requires support for:
16375 communities
8187 extended communities
5458 large communities
I have not changed the as-path length, because it is already ridiculously high.
If anyone wants to talk about a maximum as-path length, please speak up.

I have added tests to the implementation report
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations
to ensure full compliance with the consequences of the draft.

Implementers, please update your compliance.

Thanks,
Jakob

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, November 21, 2017 10:41 AM
To: Job Snijders <[email-masked]>
Cc: idr wg <[email-masked]>; [email-masked]; Idr <[email-masked]>; Thomas Mangin <[email-masked]>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Great !

On Tue, Nov 21, 2017 at 6:35 PM, Job Snijders <[email-masked]<mailto:[email-masked]>> wrote:
Robert/Randy,

Old (Section 4):

A BGP speaker that is willing to send and receive BGP Extended Messages with a peer SHOULD advertise the BGP Extended Message Capability to the peer using BGP Capabilities Advertisement RFC5492].

New (Section 4)

A BGP speaker that is capable to send and receive BGP Extended Messages with a peer SHOULD advertise the BGP Extended Message Capability to the peer using BGP Capabilities Advertisement [RFC5492].

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Nov 2017 23:54:57 +0100

Hi Jakob,

I think what you added is fine, but requires a time limit.

Statement that implementation can receive, parse/validate, display in CLI
or match in the policy 16K of communities all actions taking 1h each is
rather not that interesting isn't it ?

Or is the indicator of spec compliance a statement that it just does not
crash regardless of time it takes for execution of each stated action :) ?

Thx,
//R.

On Tue, Nov 21, 2017 at 11:38 PM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, November 21, 2017 10:41 AM
> *To:* Job Snijders <[email-masked]>
> *Cc:* idr wg <[email-masked]>; [email-masked]; Idr <[email-masked]>;
> Thomas Mangin <[email-masked]>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 21 Nov 2017 22:58:03 +0000

Just that it does it without error.
If the numbers are too large, we should discuss reasonable limits.

Thanks,
Jakob

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, November 21, 2017 2:55 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Job Snijders <[email-masked]>; idr wg <[email-masked]>; [email-masked]; Idr <[email-masked]>; Thomas Mangin <[email-masked]>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Hi Jakob,

Statement that implementation can receive, parse/validate, display in CLI or match in the policy 16K of communities all actions taking 1h each is rather not that interesting isn't it ?

Or is the indicator of spec compliance a statement that it just does not crash regardless of time it takes for execution of each stated action :) ?

Thx,
//R.

On Tue, Nov 21, 2017 at 11:38 PM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Jakob

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Tuesday, November 21, 2017 10:41 AM
To: Job Snijders <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Idr <[email-masked]<mailto:[email-masked]>>; Thomas Mangin <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Great !

Old (Section 4):

New (Section 4)

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 21 Nov 2017 23:12:55 +0000

1 hour ??
When I tested my large community code, I tested at the limit and over it.
There was no perceptible time for the operations.
16 times imperceptible would be a blip at the most.
The only operations that take a worrisome amount of time are regexp matches with nested wildcards.
Hmm, I should add regexp matches explicitly, because that requires to expand the communities into ascii representation in the matching engine.

Thanks,
Jakob

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, November 21, 2017 2:58 PM
To: Robert Raszuk <[email-masked]>
Cc: idr wg <[email-masked]>; [email-masked]; Thomas Mangin <[email-masked]>; Idr <[email-masked]>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Thanks,
Jakob

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, November 21, 2017 2:55 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Cc: Job Snijders <[email-masked]<mailto:[email-masked]>>; idr wg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Idr <[email-masked]<mailto:[email-masked]>>; Thomas Mangin <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Hi Jakob,

Thx,
//R.

Thanks,
Jakob

Great !

Old (Section 4):

New (Section 4)

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Nov 2017 08:29:56 +0900

> A BGP speaker that is capable to send and receive BGP Extended
> Messages with a peer SHOULD advertise the BGP Extended Message
> Capability to the peer using BGP Capabilities Advertisement [RFC5492].

   A BGP speaker that is capable of sending and receiving BGP Extended
   Messages SHOULD advertise the BGP Extended Message Capability to the
   peer using BGP Capabilities Advertisement [RFC5492].  A BGP speaker
   MAY send Extended Messages to its peer only if it has received the
   Extended Message Capability from that peer.

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 22 Nov 2017 15:10:28 +0000

Jakob,

I looked into the added questions for the compliance report you added on the wiki.
I am not quite sure that these added questions do apply for a compliance of the requested draft. These do more apply to features used within BGP that might result in larger BGP messages.
And here the draft has a clear message in the last paragraph of section 3:

“It is RECOMMENDED that BGP protocol developers and implementers are
  conservative in their application and use of Extended Messages.”

Therefore, they would more apply to proper functioning of implemented BGP features rather than the extended message itself. I do not believe that these new questions do apply here.

Said that, BGPSEC-IO is a traffic generator that mainly focusses on BGPSEC updates. We did not add communities to the generated traffic and I do not intent to do so in the near future (though community contributions are welcome) – in this sense, for sending my answer is NA.
On the receiving side, as long as the BGP update in itself is well formed and within its length boundaries (4K or < 64K) there is no issue. We just dump the update either on the “floor” or screen.

With QuaggaSRx, as long as Quagga can process communities of that length, QuaggaSRx can as well. QuaggaSRx same as BGPSEC-IO do comply with the draft itself when it comes to accepting and generating > 4K updates as specified in the draft and we tested the processing and memory usage using BGPsec traffic of little less than 64 K.

Oliver

From: Idr <[email-masked]> on behalf of "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tuesday, November 21, 2017 at 6:13 PM
To: Robert Raszuk <[email-masked]>
Cc: idr wg <[email-masked]>, "[email-masked]" <[email-masked]>, Idr <[email-masked]>, Thomas Mangin <[email-masked]>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

1 hour ??

Thanks,
Jakob

Thanks,
Jakob

Hi Jakob,

Thx,
//R.

I have added tests to the implementation report
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-extended-implementations<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7Cc29658d9c708468b0ccd08d5313576ee%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636469028063383089&sdata=zRFsa6v%2BqWcQo44fTcKtmbmqmFZicA495i%2BZfcA4ZSg%3D&reserved=0>
to ensure full compliance with the consequences of the draft.

Thanks,
Jakob

Great !

Old (Section 4):

New (Section 4)

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Coliver.borchert%40nist.gov%7Cc29658d9c708468b0ccd08d5313576ee%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636469028063383089&sdata=Bt6F5N6zA5v7GCXm7peFu06uK1TCD3sRHIVPffp%2F0O0%3D&reserved=0>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 22 Nov 2017 17:15:48 +0000

Larger message implies larger path attributes. You may answer “no” for the parts with which you do not comply.

If the implied path attribute sizes are too large, then we need to be explicit about the maximum sizes for each attribute in the draft. Please suggest reasonable maximum sizes.

Thanks,
Jakob.

On Nov 22, 2017, at 7:10 AM, Borchert, Oliver (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

Jakob,

Oliver

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of "Jakob Heitz (jheitz)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 21, 2017 at 6:13 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Idr <[email-masked]<mailto:[email-masked]>>, Thomas Mangin <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

1 hour ??

Thanks,
Jakob

From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, November 21, 2017 2:58 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Thomas Mangin <[email-masked]<mailto:[email-masked]>>; Idr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Thanks,
Jakob

Hi Jakob,

Thx,
//R.

Thanks,
Jakob

Great !

Old (Section 4):

New (Section 4)

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 22 Nov 2017 19:58:16 +0000

To my understanding the wiki should state compliance with the draft in question and not particular BGP attributes.

The draft is about the capability of sending and receiving updates larger than 4K and how to handle if the capability is not propagated, as well as the “5 mile view” on what to do if an update would exceed the newly proposed max length of 64K, it is not about performance issues etc.

To me the added questions in the wiki are more about the capability to process individual attributes that might become large. This is outside the scope of the draft in question.

It seems to me that what you try to solve is not compliance with the draft, it is more about the capability of particular implementations on how to deal with larger updates and this might change with memory, CPU, quality of implementation, etc. but has nothing to do with the draft in question.

In case there are issues with attributes getting too large and therefore causing issues to BGP itself, then I believe the RFC’s dealing with these attributes should be updated.

Again, I believe this is out of scope of this draft and I do not see any need to have these questions in the wiki.

Oliver

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wednesday, November 22, 2017 at 12:16 PM
To: Oliver Borchert <[email-masked]>
Cc: Robert Raszuk <[email-masked]>, idr wg <[email-masked]>, "[email-masked]" <[email-masked]>, Idr <[email-masked]>, Thomas Mangin <[email-masked]>, Randy Bush <[email-masked]>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Oliver

1 hour ??

Thanks,
Jakob

Thanks,
Jakob

Hi Jakob,

Thx,
//R.

Thanks,
Jakob

Great !

Old (Section 4):

New (Section 4)

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 22 Nov 2017 21:10:01 +0100

Hi Olivier,

The larger updates will contain larger attributes and I think Jakob's point
of those questions was to make sure that what actually creates the extended
size BGP UPDATE MSGs can be handled by the implementations who claim
support for it.

However I must agree with you that implementation report draft or wiki is
really not the right place for those questions. It merely is there to
indicate if the draft has been implemented and what parts of the draft got
implemented.

Those questions are perfect for customer evaluation of given bgp
implementation though, but I am afraid we do not have within IETF a room
for such efforts :)

Best,
R.

On Wed, Nov 22, 2017 at 8:58 PM, Borchert, Oliver (Fed) <
[email-masked]> wrote:

> To my understanding the wiki should state compliance with the draft in
> question and not particular BGP attributes.
>
>
>
> The draft is about the capability of sending and receiving updates larger
> than 4K and how to handle if the capability is not propagated, as well as
> the “5 mile view” on what to do if an update would exceed the newly
> proposed max length of 64K, it is not about performance issues etc.
>
>
>
> To me the added questions in the wiki are more about the capability to
> process individual attributes that might become large. This is outside the
> scope of the draft in question.
>
>
>
> It seems to me that what you try to solve is not compliance with the
> draft, it is more about the capability of particular implementations on how
> to deal with larger updates and this might change with memory, CPU, quality
> of implementation, etc. but has nothing to do with the draft in question.
>
>
>
> In case there are issues with attributes getting too large and therefore
> causing issues to BGP itself, then I believe the RFC’s dealing with these
> attributes should be updated.
>
>
>
> Again, I believe this is out of scope of this draft and I do not see any
> need to have these questions in the wiki.
>
>
>
> Oliver
>
>
>
> *From: *"Jakob Heitz (jheitz)" <[email-masked]>
> *Date: *Wednesday, November 22, 2017 at 12:16 PM
> *To: *Oliver Borchert <[email-masked]>
> *Cc: *Robert Raszuk <[email-masked]>, idr wg <[email-masked]>, "
> [email-masked]" <[email-masked]>, Idr <[email-masked]>, Thomas
> Mangin <[email-masked]>, Randy Bush <[email-masked]>
>
> *Subject: *Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> If the implied path attribute sizes are too large, then we need to be
> explicit about the maximum sizes for each attribute in the draft. Please
> suggest reasonable maximum sizes.
>
> Thanks,
>
> Jakob.
>
>
> On Nov 22, 2017, at 7:10 AM, Borchert, Oliver (Fed) <
> [email-masked]> wrote:
>
> Jakob,
>
>
>
> I am not quite sure that these added questions do apply for a compliance
> of the requested draft. These do more apply to features used within BGP
> that might result in larger BGP messages.
>
> Therefore, they would more apply to proper functioning of implemented BGP
> features rather than the extended message itself. I do not believe that
> these new questions do apply here.
>
>
>
> Said that, BGPSEC-IO is a traffic generator that mainly focusses on BGPSEC
> updates. We did not add communities to the generated traffic and I do not
> intent to do so in the near future (though community contributions are
> welcome) – in this sense, for sending my answer is NA.
>
> On the receiving side, as long as the BGP update in itself is well formed
> and within its length boundaries (4K or < 64K) there is no issue. We just
> dump the update either on the “floor” or screen.
>
>
>
> With QuaggaSRx, as long as Quagga can process communities of that length,
> QuaggaSRx can as well. QuaggaSRx same as BGPSEC-IO do comply with the draft
> itself when it comes to accepting and generating > 4K updates as specified
> in the draft and we tested the processing and memory usage using BGPsec
> traffic of little less than 64 K.
>
>
>
> Oliver
>
>
>
> *From: *Idr <[email-masked]> on behalf of "Jakob Heitz (jheitz)" <
> [email-masked]>
> *Date: *Tuesday, November 21, 2017 at 6:13 PM
> *To: *Robert Raszuk <[email-masked]>
> *Cc: *idr wg <[email-masked]>, "[email-masked]" <[email-masked]>, Idr <
> [email-masked]>, Thomas Mangin <[email-masked]>
> *Subject: *Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages
> (11/12 to 11/26)
>
>
>
> 1 hour ??
>
> Hmm, I should add regexp matches explicitly, because that requires to
> expand the communities into ascii representation in the matching engine.
>
>
>
> Thanks,
>
> Jakob
>
>
>
> *Sent:* Tuesday, November 21, 2017 2:58 PM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* idr wg <[email-masked]>; [email-masked]; Thomas Mangin <
> [email-masked]>; Idr <[email-masked]>
> *From:* [email-masked] [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Tuesday, November 21, 2017 2:55 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* Job Snijders <[email-masked]>; idr wg <[email-masked]>; [email-masked];
> Idr <[email-masked]>; Thomas Mangin <[email-masked]>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-extended-implementations&data=02%7C01%7Coliver.borchert%40nist.gov%7Cc29658d9c708468b0ccd08d5313576ee%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636469028063383089&sdata=zRFsa6v%2BqWcQo44fTcKtmbmqmFZicA495i%2BZfcA4ZSg%3D&reserved=0>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Coliver.borchert%40nist.gov%7Cc29658d9c708468b0ccd08d5313576ee%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636469028063383089&sdata=Bt6F5N6zA5v7GCXm7peFu06uK1TCD3sRHIVPffp%2F0O0%3D&reserved=0>
>
>
>
>

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 22 Nov 2017 20:29:54 +0000

Agreed,

Oliver

From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Wednesday, November 22, 2017 at 3:10 PM
To: Oliver Borchert <[email-masked]>
Cc: "Jakob Heitz (jheitz)" <[email-masked]>, idr wg <[email-masked]>, "[email-masked]" <[email-masked]>, Idr <[email-masked]>, Thomas Mangin <[email-masked]>, Randy Bush <[email-masked]>
Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26)

Hi Olivier,

The larger updates will contain larger attributes and I think Jakob's point of those questions was to make sure that what actually creates the extended size BGP UPDATE MSGs can be handled by the implementations who claim support for it.

However I must agree with you that implementation report draft or wiki is really not the right place for those questions. It merely is there to indicate if the draft has been implemented and what parts of the draft got implemented.

Those questions are perfect for customer evaluation of given bgp implementation though, but I am afraid we do not have within IETF a room for such efforts :)

Best,
R.

On Wed, Nov 22, 2017 at 8:58 PM, Borchert, Oliver (Fed) <[email-masked]<mailto:[email-masked]>> wrote:
To my understanding the wiki should state compliance with the draft in question and not particular BGP attributes.

Oliver

From: "Jakob Heitz (jheitz)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 22, 2017 at 12:16 PM
To: Oliver Borchert <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, idr wg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Idr <[email-masked]<mailto:[email-masked]>>, Thomas Mangin <[email-masked]<mailto:[email-masked]>>, Randy Bush <[email-masked]<mailto:[email-masked]>>

Oliver

1 hour ??

Thanks,
Jakob

Thanks,
Jakob

Hi Jakob,

Thx,
//R.

Thanks,
Jakob

Great !

Old (Section 4):

New (Section 4)

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 22 Nov 2017 23:26:32 +0000

If router A follows this draft, then it can quite legitimately send an update with 16000 communities. If router B cannot receive and process it, then it’s broken.

If path attribute size is not addressed, then this draft will cause inoperable implementations. As such, it is not fit for standardization. Either we assume the maximum possible size for all attributes or specify shorter maximum sizes. Anything less leads to failure to interoperate.

Oliver, what maximum sizes does your implementation support?
You can put those sizes into the wiki.

Thanks,
Jakob.

On Nov 22, 2017, at 11:58 AM, Borchert, Oliver (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

Oliver

Oliver

1 hour ??

Thanks,
Jakob

Thanks,
Jakob

Hi Jakob,

Thx,
//R.

Thanks,
Jakob

Great !

Old (Section 4):

New (Section 4)

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Nov 2017 00:36:19 +0100

Hi Jakob,

You are very correct. But the way to address this point (and yes it would
be great to address it) is to include in this current draft (a WG document
after all) sections pertaining to each current BGP Attribute and its
maximum size in the extended message. I think this is what was also
Olivier's main point - not that your observations were wrong - they just
did not fit with the current way documents are progressed.

Or as I suggested add one line to the current spec stating that current
attributes MUST not be extended in size unless a new specific RFC will
allow for it as provide interop between 4k/65K boundary rules for each such
attribute.

Just placing those on implementation report wiki (while not being part of
the document) is not part of the IDR process I am afraid. Besides even if
someone reports it works today you have zero guarantees that it will work
the same way tomorrow unless it is clearly spelled out in the RFC given
implementation claims to support.

Thx,
R.

On Thu, Nov 23, 2017 at 12:26 AM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> If router A follows this draft, then it can quite legitimately send an
> update with 16000 communities. If router B cannot receive and process it,
> then it’s broken.
>
> If path attribute size is not addressed, then this draft will cause
> inoperable implementations. As such, it is not fit for standardization.
> Either we assume the maximum possible size for all attributes or specify
> shorter maximum sizes. Anything less leads to failure to interoperate.
>
> On Nov 22, 2017, at 11:58 AM, Borchert, Oliver (Fed) <

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 23 Nov 2017 01:05:02 +0000

I’m happy to add a sentence to the effect of:
The size of individual BGP path attributes MUST be small enough that they can fit into a BGP UPDATE message of 4096 octets. If a BGP feature requires a path attribute to be longer, then the required size of the path attribute MUST be specified in the RFC of the feature requiring it.

Thanks,
Jakob.

On Nov 22, 2017, at 3:36 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakob,

You are very correct. But the way to address this point (and yes it would be great to address it) is to include in this current draft (a WG document after all) sections pertaining to each current BGP Attribute and its maximum size in the extended message. I think this is what was also Olivier's main point - not that your observations were wrong - they just did not fit with the current way documents are progressed.

Or as I suggested add one line to the current spec stating that current attributes MUST not be extended in size unless a new specific RFC will allow for it as provide interop between 4k/65K boundary rules for each such attribute.

Just placing those on implementation report wiki (while not being part of the document) is not part of the IDR process I am afraid. Besides even if someone reports it works today you have zero guarantees that it will work the same way tomorrow unless it is clearly spelled out in the RFC given implementation claims to support.

Thx,
R.

On Thu, Nov 23, 2017 at 12:26 AM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
If router A follows this draft, then it can quite legitimately send an update with 16000 communities. If router B cannot receive and process it, then it’s broken.

Thanks,
Jakob.

Oliver

Oliver

1 hour ??

Thanks,
Jakob

Thanks,
Jakob

Hi Jakob,

Thx,
//R.

Thanks,
Jakob

Great !

Old (Section 4):

New (Section 4)

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Nov 2017 10:17:54 +0100

Yes the proposed text addresses my concerns. I would only to it one more
sentence:

"​
The size of individual BGP path attributes MUST be small enough that they
can fit into a BGP UPDATE message of 4096 octets. If a BGP feature requires
a path attribute to be longer, then the required size of the path attribute
MUST be specified in the RFC of the feature requiring it. *Such RFC MUST
also specify the expected behavior on the boundary between peers which do
support extended message size and those which do not."*

Thx,
Robert Raszuk.

On Thu, Nov 23, 2017 at 2:05 AM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> ​​
> The size of individual BGP path attributes MUST be small enough that they
> can fit into a BGP UPDATE message of 4096 octets. If a BGP feature requires
> a path attribute to be longer, then the required size of the path attribute
> MUST be specified in the RFC of the feature requiring it.
>
> Thanks,
> Jakob.
>
>
> On Nov 22, 2017, at 3:36 PM, Robert Raszuk <[email-masked]> wrote:
>
> Hi Jakob,
>
>> Said that, BGPSEC-IO is a traffic generator that mainly focusses on
>> BGPSEC updates. We did not add communities to the generated traffic and I
>> do not intent to do so in the near future (though community contributions
>> are welcome) – in this sense, for sending my answer is NA.
>>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 28 Nov 2017 13:33:13 -0500

[I'm choosing this message as my response point, but not intending to
suggest that other bits of the thread weren't relevant.]

> If path attribute size is not addressed, then this draft will cause inoperable implementations. As such, it is not fit for standardization. Either we assume the maximum possible size for all attrib…

BGP has always had an issue with features that had the risk of overflowing
the Path Attributes.  I've seen this (as likely have others supporting
implementations) with odd combinations of AS_PATH, communities, etc.
Extended communities and new features simply make this more likely.

My take on the issue is this:
- If you've selected a route and are attempting to send it to a neighbor and
  you are unable to format a valid BGP PDU containing only a single NLRI,
  you MUST NOT try to send it.
- If you previously sent reachability for that NLRI, and are unable to send
  it as above, you MUST withdraw it.  Otherwise you run the risk of
  improper reachability or forwarding.

Basically, "treat as withdraw" applies here.

IMO, it's no different for extended messsages.  If I receive a > 4k message
and I can't format it for a subsequent peer, treat as withdraw for those
peers.

Where we've had good room for discussion has been what to do in order to
avoid these sort of things:
- Are there circumstances where we might be able to drop an optional
  attribute?  Maybe.  This seems messy to me.
- Are there circumstances where we might be able to limit the size of large
  attributes?  (E.g. communities.)  Possibly.  But this may be unsafe and
  would be highly circumstantial.  Whose route-target do you drop from a VPN
  route as an example?
- Is there wisdom in suggesting "old world" path attributes shouldn't be
  allowed to overflow the 4k limit?  Possibly.  Then you start getting into
  interesting mixes of combinatorics.  For example, long AS_PATH and a long
  community list together.  Implementations already do things like limit
  maximum AS_PATH length.

My personal opinion on the mitigations is that we shouldn't try to be
normative about them in the spec.  As noted in the AS_PATH example, vendors
already limit some attributes to be shorter than what the protocol might
maximally allow.  Leave it to the implementations to provide knobs
appropriate to those implementations.  There may be room in the spec
suggesting that such things are possible.

We *MUST* be normative about the treat as withdraw behavior.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Nov 2017 20:02:32 +0100

Hi Jeff,

> We *MUST* be normative about the treat as withdraw behavior.

This does provide one way to address my main point that the draft MUST be
updated to define what to do when you get to a bottleneck. Otherwise each
implementation will try to do their own thing which will be a disaster.

However your suggestion creates troubleshooting nightmare. How does a
sender is to know that some routers 3 ASes away did not get his prefix ?
How does the receiver is to know that because he is running older device
with no software upgrade possible he will be potentially missing some
routes ?

Do we no longer care that any BGP4 proposal no matter how great and useful
it is MUST be incrementally deployable ?

Thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 28 Nov 2017 14:14:58 -0500

Robert,

> with no software upgrade possible he will be potentially missing some

We don't know this today.

I don't believe trying to solve it in this document helps.

> it is MUST be incrementally deployable ?

I do not see this as world ending. :-)

The original scenario for bgpsec is one where we had significant concerns
about too-small UPDATE messages causing issues.  We had to address the
issues there.  And we already know that as a feature it has incremental
deployment challenges.

For everything else, the cases I'm currently familiar with that are likely
to cause quasi-legitimate overflows are mostly VPN scenarios.  The "blast
radius" is thus somewhat local.  I'm curious about other known scenarios.

There is likely good room for GROW to pick up the topic of how to mitigate
overflows.  I think the IDR audience is somewhat too narrow.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Nov 2017 20:25:35 +0100

Never suggested that.

> issues there.  And we already know that as a feature it has incremental

Well if this is still for BGPSEC I think your suggestion to
treat-as-withdraw is not
that good. I do prefer to get unsecured reachability then no reachability
at all.

And if you make it treat-as-withdraw as MUST even if BGSEC itself says to
drop
crypto when it does not fit it is quite unlikely that anyone will even try
to secure
BGP UPDATES any time soon.

Cheers,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 28 Nov 2017 14:40:48 -0500

Robert,

> that good. I do prefer to get unsecured reachability then no reachability

If a bgpsec speaker chooses to "downgrade" its reachability, that's its
choice.  In such a case, it would no longer be trying to overflow the 4k
PDU.

Similarly, routers that limit AS_PATH length choosing to not propagate (and
treat as withdraw) an AS_PATH that exceeds its local limit is a local
choice.

> BGP UPDATES any time soon.

bgpsec implementations are likely to deploy extended messages in tandem.  I
don't find the argument you seem to be making compelling.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Nov 2017 20:40:49 +0100

> bgpsec implementations are likely to deploy extended messages in tandem.

Is this just your assumption or is this enforced in any IETF document ?

This is important news no one earlier mentioned in this entire thread.

Thx