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

From: "Susan Hares" <[email-masked]>
Date: Tue, 24 May 2016 16:42:11 -0400

This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to
6/7). The draft can be found at: 

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

In your comments please provide the following information: 

1)      Support/"no-support" of this draft being ready for publication,

2)      You know of an implementation for this draft, please report the
implementation to the IDR Wiki

https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-bgp-extended-imp
lementations 

3)      Do you have any concerns about extending the BGP messages. 

Sue Hares and John Scudder

---

From: Job Snijders <[email-masked]>
Date: Tue, 24 May 2016 22:50:36 +0200

> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

I support publication.

Kind regards,

Job

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 May 2016 01:20:21 +0000

I have read the document and support publication.
Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 24, 2016 at 4:42 PM
To: IDR List <[email-masked]<mailto:[email-masked]>>
Cc: "Keyur Patel (keyupate)" <[email-masked]<mailto:[email-masked]>>, "David Ward (wardd)" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages (5/24 to 6/7). The draft can be found at:

1)      Support/”no-support” of this draft being ready for publication,

2)      You know of an implementation for this draft, please report the implementation to the IDR Wiki

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

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 24 May 2016 23:57:12 -0400

On Tue, May 24, 2016 at 9:20 PM, Acee Lindem (acee) <[email-masked]> wrote:
> From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]
>
> To: IDR List <[email-masked]>
> Cc: "Keyur Patel (keyupate)" <[email-masked]>, "David Ward (wardd)" <
[email-masked]>
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

​I too enjoyed reading this document, and support it's publication.​

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

---

From: heasley <[email-masked]>
Date: Wed, 25 May 2016 04:06:02 +0000

> ​I too enjoyed reading this document, and support it's publication.​

enjoyed?

I too support publication.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 24 May 2016 22:46:36 -0700

Support the publication 

From:  Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date:  Tuesday, May 24, 2016 at 1:42 PM
To:  <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, "David Ward (wardd)" <[email-masked]>
Subject:  [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

Sue Hares and John Scudder 
_______________________________________________ Idr mailing list [email-masked] https://www.ietf.org/mailman/listinfo/idr

---

From: Randy Bush <[email-masked]>
Date: Wed, 25 May 2016 09:13:55 +0200

> This begins a 2 week WG LC on draft-ietf-idr-bgp-extended-messages
> (5/24 to 6/7).

as the new fasion seems to require [co-]authors to 'vote', as a
co-author i support this going to rfc.

randy

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Wed, 25 May 2016 07:59:26 +0000

1)       Support, while making the following observations:

Section 4 – par1: is there a reason why the first ‘should’ is not a SHOULD? Same for the ‘may’?
Section 5 – par1: When using the more liberal policy, I believe it would make sense to indicate a message that an extended message was received while it was not expected at all
 G/

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Tuesday 24 May 2016 at 22:42
To: "[email-masked]" <[email-masked]>
Cc: "'Keyur Patel (keyupate)'" <[email-masked]>, 'David Ward' <[email-masked]>
Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

---

From: Randy Bush <[email-masked]>
Date: Wed, 25 May 2016 11:18:46 +0200

> SHOULD? Same for the ‘may’? 

a matter of style.  i don't care; maybe wg will converge on an opinion.

> Section 5 – par1: When using the more liberal policy, I believe it
> would make sense to indicate a message that an extended message was
> received while it was not expected at all

please be specific.  by "indicate a message" are you suggesting a new
"you sent a surprise" response message?

randy

---

From: Gunter Van De Velde <[email-masked]>
Date: Wed, 25 May 2016 11:27:57 +0200

inline: GV>

> On 25 May 2016, at 11:18, Randy Bush <[email-masked]> wrote:
> 

GV> Yes, indeed… something in a syslog or so that the peer sent some unexpected packet to alert the ops team to look into it.

G/

---

From: Randy Bush <[email-masked]>
Date: Wed, 25 May 2016 11:45:38 +0200

> Yes, indeed… something in a syslog or so that the peer sent some
> unexpected packet to alert the ops team to look into it.

so you do not mean a bgp message, but rather that errors should be
logged and maybe an snmp trap raised.  so, if we start to add a short
sentence or paragraph on this to the end of section 5, how far do you
want to go?  is there something to which we could point?

randy

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Wed, 25 May 2016 10:04:29 +0000

Indeed, nothing on protocol level. Apologies for the confusion.

I was thinking about an operational message and something similar as last paragraph of chapter 4.1 from draft-ietf-grow-ops-reqs-for-bgp-error-handling-07… 

“”
Since the Non-Critical error handling required within this section
   results in no NOTIFICATION message being transmitted, the fact that
   an error has occurred, and there may be inconsistency between the
   local and remote BGP speaker MUST be flagged to the network operator
   through standard operational interfaces (e.g., SNMP, syslog).  The
   information highlighted MUST include the NLRI identified to be
   contained within the error message, and SHOULD contain a exact copy
   of the received message for further analysis.

“”

G/

---

From: <[email-masked]>
Date: Wed, 25 May 2016 10:04:34 +0000

Hi,

1)      Support.

2)      Question, for my own information: why does the capability mean that the BGP speaker is capable of _both_  receiving _and sending_ extend message? (vs capable of receiving (only)). IOTW, what is the motivation to advertise the capacity to send extended message?

3)      Please find below some possible comments:

"4.  Operation"

Suppose that I receive an extended BGP message (e.g. update) that I can't relay to some peers because they don't support such extension, while I "should" have relayed it. Is there an expected behavior? Should it be standardized? Can this create issues (e.g. inconsistent routing with an AS)? Should this be considered in the security considerations? (e.g. I deliberately send an extended message, and benefit from its/the NLRI not being propagated as expected. e.g. to influence routing policy)

--

"A BGP speaker may send extended messages to its peer only if it has received the Extended Message Capability from its peer."

May be :s/received/sent and received
---

"   A BGP speaker that has the ability to use extended messages but has

   not advertised the BGP Extended Messages capability, presumably due

   to configuration, SHOULD NOT accept an extended message.  A speaker

   MAY implement a more liberal policy and accept extended messages even

   from a peer that has not advertised the capability."

I would a priori have assumed that both sentences be related. But in fact they are not since the first sentence only refers to the sending of the capability, while the second only refers to the reception of the capability. Shouldn't both sentences be extended to cover both the sending and the receiving?
--

"A speaker that treats an improper extended message as a

   fatal error, as described in the preceding paragraph, MUST do

   likewise. >
I'm sorry but I don't understand this sentence. What does that mean to "treat an improper extended message as a fatal error"? e.g. If I receive an extended message with a syntax error requiring to send an NOTIFICATION (e.g. more than one MP_REACH_NLRI)  is this considered an improper extended message with a fatal error? If so the text seems wrong as bgp speaker must not do "likewise" (seems to refer to "reset the session   with a Bad Message Length NOTIFICATION")

Also "as described in the preceding paragraph, MUST do likewise" seems not precise enough to me (at least as a non-native English speaker). Which exactly is this preceding paragraph describing this "treats an improper extended message as a fatal error"

---

7.  IANA Considerations

"The IANA is requested to register a new BGP Capability Code to be named BGP Extended Message Capability >

I'm not sure about the formulation since IANA has already registered this capability as TEMPORARY.

"TBD      BGP-Extended Message"

At least I would expect that the document ask for the _same_ value (6) rather than TBD.

Thanks,

Regards,

Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, May 24, 2016 10:42 PM
To: [email-masked]
Cc: 'Keyur Patel (keyupate)'; 'David Ward'
Subject: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

_________________________________________________________________________________________________________________________

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: Randy Bush <[email-masked]>
Date: Wed, 25 May 2016 12:08:48 +0200

>    of the received message for further analysis.

so, to remove all the flowery language, a third para in sec 5,

     The inconsistency between the local and remote BGP speakers MUST be
     reported via syslog and/or SNMP.

randy

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Wed, 25 May 2016 10:10:12 +0000

Works for me.
Thanks.

G/

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 May 2016 12:34:57 +0200

Hi Bruno,

Suppose that I receive an extended BGP message (e.g. update) that I can’t relay
>
> to some peers because they don’t support such extension, while I “should” have
>
> relayed it.
>
>
​BGP does not "relay" messages .. do you have some new BGP draft in mind
which would work as BGP "repeater" ? While I recall we discussed it in the
past that work were pretty much abandoned :)

BGP generates messages at each BGP speaker so the above seems like non
issue to me for this draft.

​
​Best,
R.

For the draft itself: Support ​from me.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 May 2016 11:30:48 +0000

On 5/25/16, 5:45 AM, "Idr on behalf of Randy Bush" <[email-masked]

>want to go?  is there something to which we could point?

FWIW - In RFC 7684, we merely added the following text for unexpected
OSPFv2 encodings: 

    This situation SHOULD be logged as an error.
or:
    This situation SHOULD be looked as a warning.

We intentionally left out the details on the mechanisms used for logging
or how the messages should be used.

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 May 2016 11:41:59 +0000

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 25, 2016 at 6:34 AM
To: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Cc: "Keyur Patel (keyupate)" <[email-masked]<mailto:[email-masked]>>, IDR List <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

Hi Bruno,

relayed it.

​BGP does not "relay" messages .. do you have some new BGP draft in mind which would work as BGP "repeater" ? While I recall we discussed it in the past that work were pretty much abandoned :)

BGP generates messages at each BGP speaker so the above seems like non issue to me for this draft.

A non-issue unless the size of a single NLRI and its attributes exceeds 4K.
Thanks,
Acee

​
​Best,
R.

---

From: <[email-masked]>
Date: Wed, 25 May 2016 11:46:04 +0000

Hi Robert,

From: Robert Raszuk
Sent: Wednesday, May 25, 2016 12:35 PM

Hi Bruno,

relayed it.

​BGP does not "relay" messages ..

My mistake. Would “propagate” or “re-advertise” or “reflect” be a better term for you?

do you have some new BGP draft in mind which would work as BGP "repeater" ?

Let’s consider RFC 4456 (BGP Route Reflection). If some iBGP clients do not advertise this behavior, they will not receive the internal routes advertised by the iBGP clients sending extended messages. Hence, all iBGP routers do not have a consistent knowledge of the internal routers.

--Bruno

While I recall we discussed it in the past that work were pretty much abandoned :)

​
​Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 May 2016 13:50:11 +0200

Hi AC,

Yes indeed - you are right - I was a bit hit with "relay" term :).

And since this entire work started with the assumption that packing per
NLRI will be broken anyway one could expect this to be always the case.

So it does look like a bit of show stopper to me unless we enforce that if
there is at least one BGP peer on given BGP speaker not supporting 64K all
sessions will get reset to 4K max. Ugly but not sure what other options can
address it. Perhaps authors will come up with better one.

Thx,
R.

On Wed, May 25, 2016 at 1:41 PM, Acee Lindem (acee) <[email-masked]> wrote:

>
>
> From: Idr <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> To: Bruno Decraene <[email-masked]>
> Cc: "Keyur Patel (keyupate)" <[email-masked]>, IDR List <[email-masked]>,
> Susan Hares <[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 May 2016 13:53:53 +0200

> My mistake. Would “propagate” or “re-advertise” or “reflect” be a better

​Yup.​

> Let’s consider RFC 4456 (BGP Route Reflection). If some iBGP clients do
> not advertise this behavior, they will not receive the internal routes
> advertised by the iBGP clients sending extended messages. Hence, all iBGP
> routers do not have a consistent knowledge of the internal routers.
>

​Well that would be drastic. Perhaps lighter option would be to drop
largest optional attributes, but I am not sure if I like such swiss cheese
solution.

Yes another option would be to have this knobbed for few years and enable
only by NOC when all routers support it. ​

Automatic incremental deployment ​is bit hard in network wide enhancements
:))

Thx,
r.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 May 2016 14:29:18 +0000

Hi Robert,

From: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 25, 2016 at 7:50 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Bruno Decraene <[email-masked]<mailto:[email-masked]>>, "Keyur Patel (keyupate)" <[email-masked]<mailto:[email-masked]>>, IDR List <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

Hi AC,

And since this entire work started with the assumption that packing per NLRI will be broken anyway one could expect this to be always the case.

So it does look like a bit of show stopper to me unless we enforce that if there is at least one BGP peer on given BGP speaker not supporting 64K all sessions will get reset to 4K max. Ugly but not sure what other options can address it. Perhaps authors will come up with better one.

Since this is likely to be an extremely rare occurrence, I’d simply not advertise the NLRI to a peer not supporting extended messages and log the error.

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

Thanks,
Acee

Thx,
R.

On Wed, May 25, 2016 at 1:41 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bruno,

relayed it.

​
​Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 May 2016 17:14:42 +0200

​It will result in a permanent control plane loop ​if such dropped NLRI on
IBGP is a more specific entry.

Even if according to your judgement it may be classified as "extremely
rare" I do not think IETF spec should take such risk.

Best,
R.

On Wed, May 25, 2016 at 4:29 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
> From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
> To: Acee Lindem <[email-masked]>
> Cc: Bruno Decraene <[email-masked]>, "Keyur Patel (keyupate)" <
> [email-masked]>, IDR List <[email-masked]>, Susan Hares <[email-masked]
> >
> Since this is likely to be an extremely rare occurrence, I’d simply not
> advertise the NLRI to a peer not supporting extended messages and log the
> error.
>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 25 May 2016 15:29:58 +0000

+1. Support as a co-author.

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 25 May 2016 15:34:24 +0000

Comments inlined #Keyur.

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

​Yup.​

​Well that would be drastic. Perhaps lighter option would be to drop largest optional attributes, but I am not sure if I like such swiss cheese solution.

Yes another option would be to have this knobbed for few years and enable only by NOC when all routers support it. ​

Automatic incremental deployment ​is bit hard in network wide enhancements :))

#Keyur:  Clients would receive internal routes as long as a RR can announce prefixes using existing message length (of 4K). If the attribute size is such that the message length does get exceeded then the Prefix SHOULD not be announced and an error should be logged (existing case).

Regards,
Keyur

Thx,
r.

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 25 May 2016 15:35:01 +0000

Comments inlined #Keyur

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

Hi Robert,

Hi AC,

#Keyur: Yep. I agree. :)

Regards,
Keyur

Thanks,
Acee

Thx,
R.

Hi Bruno,

relayed it.

​
​Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 May 2016 17:48:13 +0200

> Additionally, we could discourage the generation of a single NLRI

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

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 25 May 2016 15:51:01 +0000

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

#Keyur: Yep. I agree. :)

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

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 May 2016 17:54:45 +0200

​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 ?

Best,
R.
​

On Wed, May 25, 2016 at 5:51 PM, Keyur Patel (keyupate) <[email-masked]>
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.
>
> From: Robert Raszuk <[email-masked]>
> To: Keyur Patel <[email-masked]>, "Acee Lindem (acee)" <[email-masked]
> >
> Cc: Bruno Decraene <[email-masked]>, "[email-masked]" <
> [email-masked]>, Susan Hares <[email-masked]>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 25 May 2016 15:57:32 +0000

Hi Bruno,

Many thanks for the review. Comments inlined #Keyur

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 25, 2016 at 3:04 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>, Keyur Patel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

Hi,

1)      Support.

“4.  Operation”

Suppose that I receive an extended BGP message (e.g. update) that I can’t relay to some peers because they don’t support such extension, while I “should” have relayed it. Is there an expected behavior? Should it be standardized? Can this create issues (e.g. inconsistent routing with an AS)? Should this be considered in the security considerations? (e.g. I deliberately send an extended message, and benefit from its/the NLRI not being propagated as expected. e.g. to influence routing policy)

#Keyur: Clients would receive internal routes as long as a RR can announce prefixes using existing message length (of 4K). It would be using multiple messages limited to 4K length.  Alternatively, if the attribute size is such that the message length does get exceeded then the Prefix SHOULD not be announced and an error should be logged (existing case).

--

“A BGP speaker may send extended messages to its peer only if it has received the Extended Message Capability from its peer.”

May be :s/received/sent and received
---
#Keyur: A capability announcement indicates an ability to "receive and parse" extended messages. In that context “receive” is good enough?

“   A BGP speaker that has the ability to use extended messages but has

   from a peer that has not advertised the capability.”

I would a priori have assumed that both sentences be related. But in fact they are not since the first sentence only refers to the sending of the capability, while the second only refers to the reception of the capability. Shouldn’t both sentences be extended to cover both the sending and the receiving?
--
#Keyur: We wanted to be explicit in error handling section. :) Again, the capability meaning is to be able to “receive and parse”.

“A speaker that treats an improper extended message as a

   likewise. »
I’m sorry but I don’t understand this sentence. What does that mean to “treat an improper extended message as a fatal error”? e.g. If I receive an extended message with a syntax error requiring to send an NOTIFICATION (e.g. more than one MP_REACH_NLRI)  is this considered an improper extended message with a fatal error? If so the text seems wrong as bgp speaker must not do “likewise” (seems to refer to “reset the session   with a Bad Message Length NOTIFICATION”)

Also “as described in the preceding paragraph, MUST do likewise” seems not precise enough to me (at least as a non-native English speaker). Which exactly is this preceding paragraph describing this “treats an improper extended message as a fatal error”

---

#Keyur:  The text is meant for a BGP speaker that doesn’t announce extended message capability AND doesn’t support extended messages implementation (old style peer). Such a peer would consider a receipt of an extended message as a malformed message.

7.  IANA Considerations

“The IANA is requested to register a new BGP Capability Code to be named BGP Extended Message Capability »

I’m not sure about the formulation since IANA has already registered this capability as TEMPORARY.

“TBD      BGP-Extended Message”

#Keyur: Ack.

Regards,
Keyur

Thanks,

Regards,

Bruno

To: [email-masked]<mailto:[email-masked]>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 25 May 2016 16:00:36 +0000

Hi Robert,

Comments inlined #Keyur1

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

R1 --- RR --- R2

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

#Keyur: Yep. I agree. :)

Section 1

Section 3.2

Question:

Thx,
R.
​

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 May 2016 18:04:46 +0200

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

> To: Keyur Patel <[email-masked]>
> Cc: "Acee Lindem (acee)" <[email-masked]>, Bruno Decraene <
> [email-masked]>, Susan Hares <[email-masked]>, "[email-masked]"
> <[email-masked]>
> 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) <
> [email-masked]> wrote:
>
>> Hi Robert,
>>
>> To: Keyur Patel <[email-masked]>, "Acee Lindem (acee)" <
>> [email-masked]>
>> ​So what exactly are we to discourage here because clearly not
>> "generation of single NLRI exceeding 4K" ?
>>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 25 May 2016 16:24:28 +0000

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

Date: Wednesday, May 25, 2016 at 9:04 AM

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Comments inlined #Keyur1

R1 --- RR --- R2

Regards,
Keyur

Best,
R.
​

#Keyur: Yep. I agree. :)

Section 1

Section 3.2

Question:

Thx,
R.
​

---

From: "Russ White" <[email-masked]>
Date: Wed, 25 May 2016 21:23:17 -0400

> > (5/24 to 6/7). The draft can be found at:
> >

Support.

:-)

Russ

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 26 May 2016 03:07:06 +0000

Support.

This extension can address the requirement that one Ethernet A-D route per ESI can be issued with 4k RTs,
No need to use a set of routes that each route use a different RD to convey the total number of RTs.

https://tools.ietf.org/id/draft-ietf-bess-evpn-usage-02.txt
5.2.1. Service startup procedures

   As soon as the EVIs are created in PE1, PE2 and PE3, the following
   control plane actions are carried out:

   o Flooding tree setup per EVI (4k routes): Each PE will send one
     Inclusive Multicast Ethernet Tag route per EVI (up to 4k routes per
     PE) so that the flooding tree per EVI can be setup. Note that
     ingress replication or P2MP LSPs can optionally be signaled in the
     PMSI Tunnel attribute and the corresponding tree be created.

   o Ethernet A-D routes per ESI (a set of routes for ESI12): A set of
     A-D routes with a list of 4k RTs (one per EVI) for ESI12 will be
     issued from PE1 and PE2 (it has to be a set of routes so that the
     total number of RTs can be conveyed). As per [RFC7432], each
     Ethernet A-D route per ESI is differentiated from the other routes
     in the set by a different Route Distinguisher (ES RD). This set
     will also include ESI Label extended communities with the active-
     standby flag set to zero (all-active multi-homing type) and an ESI
     Label different from zero (used for split-horizon functions). These
     routes will be imported by the three PEs, since the RTs match the
     EVI RTs locally configured. The A-D routes per ESI will be used for
     fast convergence and split-horizon functions, as discussed in
     [RFC7432].

Regards,
Shunwan

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2016年5月25日 4:42
收件人: [email-masked]
抄送: 'Keyur Patel (keyupate)'; 'David Ward'
主题: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

---

From: <[email-masked]>
Date: Thu, 26 May 2016 09:18:47 +0000

Hi Keyur,

Thanks for considering my comments and your prompt answer.
Please see inlined #Bruno

From: Keyur Patel (keyupate) [mailto:[email-masked]]
Sent: Wednesday, May 25, 2016 5:58 PM
To: DECRAENE Bruno IMT/OLN; Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-12 WG LC (5/24 to 6/7)

Hi Bruno,

Hi,

1)      Support.

#Bruno: You may have missed the above question? It's linked to some of the below comments, so even though it's not a comment, it's useful to me / this thread. Thanks

"4.  Operation"

#Keyur: Clients would receive internal routes as long as a RR can announce prefixes using existing message length (of 4K). It would be using multiple messages limited to 4K length.
#Bruno: Agreed.
 Alternatively, if the attribute size is such that the message length does get exceeded then the Prefix SHOULD not be announced and an error should be logged (existing case).
#Bruno: That was indeed the issue I had in mind.
I'm not seeing this point in the draft. Could this be added? Plus the consequences both within an AS and across ASes, in particular to raise this point to network operator (which may deploy this) and protocol designed (which may want to use it).

This is partly similar to the "treat as withdraw" behavior described in RFC7606, so you may want to reuse existing text. cf "Operational Considerations" https://tools.ietf.org/html/rfc7606#section-6 In particular

 "we note
   that if an UPDATE message received on an Internal BGP (IBGP) session
   is subjected to this treatment, inconsistent routing within the
   affected Autonomous System may result.  The consequences of
   inconsistent routing can include long-lived forwarding loops and
   black holes. >
[...]
< Even if inconsistent routing does not arise, the "treat-as-withdraw"
   behavior can cause either complete unreachability or suboptimal
   routing for the destinations whose routes are carried in the affected
   UPDATE message. >
[...]
"Because of these potential issues, a BGP speaker must provide
   debugging facilities to permit issues caused by a malformed attribute
   to be diagnosed. >

An in term of warning to network operator and protocol designer, something along the following lines
"Network operator needing to advertise within its AS  a BGP route which size would require a BGP message larger than 4096 octets, SHOULD enabled this Extended Message capability on all BGP speaker needing to receive this routes. Failure to do so may result in inconsistent routing within its AS, as described above".
"A protocol designer or network operator needing to advertise, outside of its AS, a BGP route which size would require a BGP message larger than 4096 octets should take into account that it has no guarantee that its route will be propagated as expected as a downstream BGP speaker might not be compliant or might not has enabled BGP extended messages and hence will not propagate the route. This is especially the case if one expect Internet wide propagation of its route, which seems highly improbable until a few years/decades".

We could add the IPv6 example, to illustrate the time needed to deploy a new feature across the Internet, but I guess this would trigger some negative reactions.

----

#Bruno
This document does not define the default behavior with regards to the advertisement of the capability. IMO, this point may impact the deployability of features using extended message and the security consideration. May be it should be enabled by default on IBGP session and disabled by default on EBGP sessions.

--

May be :s/received/sent and received
---
#Keyur: A capability announcement indicates an ability to "receive and parse" extended messages. In that context "receive" is good enough?

#Bruno: I agree with you in general, but this is not was this document states. "By advertising the BGP Extended Message Capability to a peer, a BGP speaker conveys that it is able to send, receive, and properly handle BGP Extended Messages. >

I would a priori have assumed that both sentences be related. But in fact they are not since the first sentence only refers to the sending of the capability, while the second only refers to the reception of the capability. Shouldn't both sentences be extended to cover both the sending and the receiving?
--
#Keyur: We wanted to be explicit in error handling section. :) Again, the capability meaning is to be able to "receive and parse".
#Bruno: Again same comment. _This_ document has defined the capability to mean "send, receive and parse".

   likewise. >

---

#Keyur:  The text is meant for a BGP speaker that doesn't announce extended message capability AND doesn't support extended messages implementation (old style peer). Such a peer would consider a receipt of an extended message as a malformed message.
#Bruno: ok, thanks for the clarification. I'm not sure to see the value of the quoted sentence. You are making a distinction/specific sub-case (a BGP which handled error as fatal error), to say that the behavior is the same. So it looks like removing the sentence would have the same effect. (no need for a specific case)

7.  IANA Considerations

#Keyur: Ack.

Regards,
Keyur

Thanks,

Regards,

Bruno

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 26 May 2016 13:20:08 +0200

Hi Bruno/all,

“A protocol designer or network operator needing to advertise, outside of
> its AS, a BGP route which size would require a BGP message larger than 4096
> octets should take into account that it has no guarantee that its route
> will be propagated as expected as a downstream BGP speaker might not be
> compliant or might not has enabled BGP extended messages and hence will not
> propagate the route. This is especially the case if one expect Internet
> wide propagation of its route, which seems highly improbable until a few
> years/decades”.
>

​The above text which very true triggered few more observations:

​- As this is WG last call implementation report (even on the wiki should
be available) Can we get a pointer to it ? I do not see it on the IETF page:
https://www.ietf.org/iesg/implementation-report.html

- Did implementation report (if even completed) included the set of test
cases say with large AS_PATH or long Extended Community (stuffing a lot of
RTs as described in RTC backwards compatibility work) to make sure that
most popular BGP implementation can handle such large attributes without
crashing ? Otherwise enabling this would be an excellent attack vector in
the Internet.

- Do we have an agreement that this will not be "ON" by default, but will
be enabled only with a knob ?

- How do we detect if this is supported across the private AS/public
Internet zoo of routers ? Should we have a protocol tool which would allow
to detect support of extended messages at each BGP speaker and if not
report this as an error to the originator of the large message ? Sending
large BGP message if not supported by any remote peer by any BGP speaker
along the propagation would trigger reporting it back with new ICMP error
could be one approach. I am sure there would be others ...

Thx,
r.

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 May 2016 13:34:37 +0200

packing is not relevant.  receiver unpacks if nlri are packed, and as a
sender decides whether and how densly to pack or not.  if the outbound
link is smaller than the inbound, pack in less nlri.  if it is the
attributes that over-flow, then you have a more general problem.

if we are in the bgpsec space,

  o will a single nlri with a signed path fit in the extended message?
    yes.  even degenerate prepends don't hurt because of the pCount
    hack.

  o if there is an outbound that is not a bgpsec speaker, they will be
    sent a classic as4_path which darn well should fit in the classic
    message size.  if there is prepend insanity, that would die today.

  o if the outbound is a bgpsec speaker yet will not use an extended
    message size, there is one interesting case, the singleton stub.
    a non-transit router can sign toward its upstream(s) and not care
    about receiving bgsec as it has no other choice of where to send
    packets.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 26 May 2016 13:58:33 +0200

>  if there is prepend insanity, that would die today.

The difference is that today it will immediately die at yr peer and it is
very easy to detect. Same for other attributes which can take tons of stuff
loaded on them today.

With extended message it will die few hops away likely in different AS and
to detect it will be quite hard without proper tool.

Thx,
R.

---

From: Ignas Bagdonas <[email-masked]>
Date: Thu, 26 May 2016 15:21:04 +0100

I have read the draft and support the publication.

Some assorted comments:

- s/RFC4221/RFC4271, and remove reference of RFC4221.

- Section 4, third paragraph talks about the propagation path. How would 
such a path be known in advance of the propagation? This seems contrary 
to a normal multipoint flooding mode of BGP operation.

- Error handling in the environment with old style and extended messages 
capable peers. There could be several scenarios advertising received 
extended messages to an old style peer:
-- Single NLRI itself is longer than 4096 (opaque key-value AFI as an 
example). It is not possible to send it to an old style peer at all, 
should be dropped and logged.
-- Single path attribute is longer than 4096. Removing such attribute 
would leave no place where to put partial indication. Would see dropping 
and logging to stay consistent with the NLRI case being a practical 
approach.
-- The sum of path attributes is above 4096, while each path attribute 
is shorter than 4096. This seems to be the least deterministic case, 
likely it will be optional attributes that exceed the length, with local 
node having no knowledge based on what criteria to remove which 
attribute from propagation. Also this is not specific to extended 
messages. Behaviour today seems to be left to implementation detail. 
Should be logged and possibly dropped, leaving to the implementation 
detail.

Ignas

On 24/05/2016 21:42, Susan Hares wrote:
> 1)Support/”no-support” of this draft being ready for publication,
>
> 2)You know of an implementation for this draft, please report the 
> 3)Do you have any concerns about extending the BGP messages.
>