Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

From: Randy Bush <[email-masked]>
Date: Sun, 05 Mar 2017 16:46:42 +0900

quite the review.  decided to earn your dinner, eh?  owe you one.  you
can collect in chicago.

> M1. Section 4. (Operation): “An implementation that supports the BGP
> Extended Messages MUST be prepared to receive an UPDATE message that
> is larger than 4096 bytes.“ Only UPDATEs?

yes.  see jeff's message.

> I know that the most likely case for exceeding the 4k size is an
> UPDATE, but why are the other messages not considered?

rather ask why they should be.  i know this is bgp, but do we really
need to complicate life?

and there is a bit of a recursion problem if you try to extended OPEN.

> what does “prepared to receive” mean, and how can “MUST be prepared to
> receive” be enforced?

   An implementation that advertises support for BGP Extended Messages
   MUST be capable of receiving an UPDATE message with a length up to
   and including 65535 octets.

like many MUSTs, there is no direct enforcement, only the ability to
diagnose blame in the case of failure and have the resulting tac ticket
be classified as an enhancement request :)

> Given the discussion in Section 5 (Error Handling), you might want to
> add something like “…even if the Capability is not advertised”.

this section is predicated on advertisement.  personally, as a long term
naggumite (yes, dr postel and i argued about this), i think the whole
send/receive without advertisement is a useless slippery slope and i
would be happy to toss it.

> M2. Section 5 (Error Handling).  “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.”  This paragraph troubles me a lot because
> it is in direct contraction with Section 3: “A peer which does not
> advertise this capability MUST NOT send BGP Extended Messages, and BGP
> Extended Messages MUST NOT be sent to it.”.  However, I think that
> John Scudder’s reasoning [3] makes sense ("keep the session up at
> (almost) all costs", and there’s clear precedence in the WG) for the
> case where the sender did advertise the Capability, but I’m not
> convinced on the case where it didn’t – please include something like
> John’s explanation in the text.

you did see where john went on to say "I acknowledge this choice would
be fairly disgusting, and I understand why the authors didn't make it."

but, if we keep the MAY, then i guess throwing in jgs's excuse is
worthwhile.

   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 to which it has not advertised the capability, in
   the interest of preserving the BGP session if at all possibe.

> M2.1.  Even with John’s explanation, I find myself thinking that this
> specification could result in some sloppy implementations: if I need
> to account for receiving unexpected Extended Messages in my code, then
> maybe I won’t worry too much about controlling what to send to my
> peers – specially in cases where it would be easy to just replicate an
> UPDATE (like in a peer-group) and not worry about possible exceptions.
> I know that we can’t avoid bad implementations, no matter what text is
> added – but I think that recognizing the threat (maybe in the Security
> Considerations section) of someone receiving an Extended Message when
> they don’t support it would be good.  I know that there’s text in the
> document already which talks about what to do if the receiver doesn’t
> support Extended Messages – I’m just worried about potential issues
> with memory allocation if the receiver was not ready…

in the absense of an AD with the guts to let me tear that out, i'll put
a note in sec cons. :)

   Section 5 allowed a receiver to accept an extended message even
   though they had not advertised the capability.  This slippery slope
   will surely lead to sloppy implementations sending extended messages
   when the receiver is not prepared to deal with them, e.g. to peer
   groups.  At best, this will result in erroes; at worst, buffer
   overflows.

> M3. Section 5 (Error Handling).  “…reset the session with a Bad
> Message Length NOTIFICATION…” Please be clear and specific: (something
> like this would be more precise) “...send a NOTIFICATION message with
> the Error Code set to Message Header Error and the Error Subcode set
> to Bad Message Type, and close the session”.  Alternatively, you can
> just remove the text (after the reference to rfc4271) as that is what
> rfc4271 already says and there’s no need to repeat it here and risk
> not being precise…

i like removing text!

> M4. Section 5 (Error Handling).  “Similarly, any speaker that treats
> an improper extended message as a fatal error, MUST do likewise.”  It
> sounds that you’re saying that any fatal error will result in a “Bad
> Message Length NOTIFICATION”.  I hope that is not what you meant – and
> that other errors should result in the appropriate action from
> rfc4271/rfc7606.  IOW, the error checking for the message (besides de
> length) doesn’t change, right?

ok, jgs, what did you mean by "any speaker that treats an improper
extended message as a fatal error," and what did you think we should
do about it.  neither 4271 not 7606 tell what to do with a fatal error
per se.

saying treat it as an as an UPDATE Message Error per RFC4271 is not
perfect, as it could be an overly long message of a different type.

clue bat, please.

> M5. Section 5 (Error Handling).  “The inconsistency between the local
> and remote BGP speakers MUST be reported via syslog and/or SNMP.”
> SNMP?  AFAIK, there’s no object that can report this inconsistency
> since there’s no NOTIFICATION generated.  In the proposed text by
> Gunter Van De Velde [4], SNMP and syslog were mentioned as examples –
> I suggest you follow that path (no need for all the “flowery
> language”) and just reference mechanisms by example to avoid having to
> point at how it would be done.
>
> M5.1. [minor] Gunter had originally suggested that the message that
> caused the inconsistency be included in the report.  Are you expecting
> the inconsistency report to just be a “Bob sent me an Extended
> Message, but I didn’t advertise the Capability to him”-type message,
> or something more?  It might be useful to provide some guidance
> indicating what type of information might be useful/interesting.

   The inconsistency between the local and remote BGP speakers MUST be
   flagged to the network operator through standard operational
   interfaces.  The information should include the NLRI and as much
   relevant information as reasonably possible.

> M6. Updates to rfc4271.  The Abstract/Introduction correctly mention
> that this document Updates rfc4271.  But I think we need to be more
> specific, specially where rfc4271 changes and there is normative
> language involved.  I found two cases:
> 
> M6.1. Section 5 doesn’t describe the behavior if the message is longer
> than 65535.  Please include either an explicit update to
> rfc4271/Section 6.1 for the use of Extended Messages, or the specific
> process here.
> 
> M6.2. rfc4271: “The value of the Length field MUST always be at least
> 19 and no greater than 4096” That needs to be updated to 65535.

6.  Changes to RFC4271

   [RFC4271] states "The value of the Length field MUST always be at
   least > 19 and no greater than 4096."  This document changes the
   latter number to 65535 for UPDATE messages.

   [RFC4271] Sec 6.1, specifies raising an error if the length of a
   message is over 4096 octets.  For UPDATE messages, iff the receiver
   has advertised the capability to receive extended messages, this
   document raises that limit to 65535.

> M7. What about transition/migration/partial deployment?  What should
> the behavior be if, for example, an Extended Message UPDATE is
> received from a peer, but can’t be propagated to others because they
> don’t support Extended Messages

if they do not support extended messages, then they can not be bgpsec
speakers.  so the whole bgpsec path stripping applies and the message
becomes short.

> There should be some guidance for the general case (i.e. when the
> total size is >4k due simply to the total amount of information, and
> not because a single attribute, for example, is really big)

how about "do not do this?"

i believe you have entered a twisty maze in which all rooms do not have
path(s) to the exit.

4.  Operation
...
   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 sure path to routing failure.

> P1. Abstract: s/extend its current message size from 4096/extend its
> current maximum message size from 4096

ack

> P2. s/I-D.ietf-sidr-bgpsec-overview/I-D.ietf-sidr-bgpsec-protocol

ack

> P3. IANA already assigned Code 6 for the Capability.  Please use that
> value and remind IANA of the early allocation in the IANA
> Considerations section.

ack

> P4. I don’t understand what this means: “Applications generating
> messages which might be encapsulated within BGP messages MUST limit
> the size of their payload to take into account the maximum message
> size.”

given that we restrict to UPDATE, i do not know what this means at all
:)

> P5. Security Considerations: I think it would be good to also
> reference rfc4272 (BGP Security Vulnerabilities Analysis) in this
> section.

sure

> N1. “It does enable large BGPsec BGPSEC_PATHs, see
> [I-D.ietf-sidr-bgpsec-protocol].”  Nice, but superfluous as it refers
> to this document.  [2 <text/html; utf-8 (base64)>]

ack

randy, who is serious about the dinner offer.  this was one hell of a
       review

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 5 Mar 2017 15:17:35 -0500

Randy and Alvaro: 

A few point have raised my disagreement regarding the AD reviews.   At this
point, the text is at odds with RFC4271.   If you feel RFC4271, does not
speak about these issues - you may have missed why the BGP FSM is there.
Please change your text. 

Sue  

Point 1 - 
===============

>like many MUSTs, there is no direct enforcement, only the ability to
diagnose blame in the case of failure and have the resulting tac ticket be
classified as an enhancement request :)

Sue:  Normally, the diagnosis comes from testers that people run prior to
putting things in the field (E.g. IXIA).   Part of BGP implementation
testing is a length BGP FSM test with a tester.  
-------------
Point 2:   Error handling is precisely defined in the BGP FSM.  You need to
tag the Extended message reception to the BGP Header error for all of this
to work. 

Randy's comment: 
Randy: "ok, jgs, what did you mean by "any speaker that treats an improper
extended message as a fatal error," and what did you think we should do
about it.  neither 4271 not 7606 tell what to do with a fatal error per se."

Sue's response:   
Any messages that exceeds 4096 for BGP speaker will result in a BGP state
machine event of BGP Header error (event 21,  BGP state machine, page 49).
Therefore,  the error procedures would be based on this even in the BGP FSM
based on state.    The RFC4271 error handling procedures are defined by the
BGP FSM based on the current state .   Please walk through the BGP FSM to
fine the precise action based on state.  Implementations do adhere to it.
There are options - so please read the entire section. 

Text from version 21

   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 to which it has not advertised the capability, in
   the interest of preserving the BGP session if at all possible.

   A BGP speaker that does not advertise the BGP Extended Messages
   capability might also genuinely not support Extended Messages.  Such
   a speaker would be expected to follow the error handling procedures
   of [RFC4271] if it receives an Extended Message.  Similarly, any
   speaker that treats an improper Extended Message as a fatal error,
   MUST treat it similarly. 

Replacement text.  

    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 BGP speaker that does not advertise the BGP Extended Messages
   capability might also genuinely not support Extended Messages.  
   If the BGP speaker does not accept an extended messages, the
   BGP speaker MUST indicate a BGP Header error (event 21) to the 
   BGP finite state machine (FSM).   

   A speaker MAY implement a more liberal policy and accept Extended
Messages,
   even from a peer to which it has not advertised the capability, in
   the interest of preserving the BGP session if at all possible.

============================================================================
=========================

#3  - on reporting this error - The HEADER length error is reported as part
of the BGP Statement machine for errors. 

Why are we going through additional issues rather than stay with the BGP
Finite state machine.  Either the Length field is correct, or it is not.
If you have an erroneous length for what is configured, you drop it.   Most
people include the erroneous header length and check the BGP speakers.   Why
are you making this more complicated? 
 
If you want to enforce the MUST, then we must open the BGP FSM.   

========================
#4 - on the limit the message size, this was to be a warning to BESS or
other groups to not defined BGP applications which not stuff more junk in
than the BGP packet size can hold. 

> P4. I don't understand what this means: "Applications generating 
> size.

It is a social warning, like the cancer warning on cigarettes.   I not in
favor of social warnings in a base technical specification.   Author/AD can
remove. 

Sue Hares 

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Sunday, March 5, 2017 2:47 AM
To: Alvaro Retana (aretana)
Cc: [email-masked]; [email-masked];
[email-masked]; Susan Hares
Subject: Re: AD Review of draft-ietf-idr-bgp-extended-messages-20

quite the review.  decided to earn your dinner, eh?  owe you one.  you can
collect in chicago.

> M1. Section 4. (Operation): "An implementation that supports the BGP 
> is larger than 4096 bytes." Only UPDATEs?

yes.  see jeff's message.

> UPDATE, but why are the other messages not considered?

rather ask why they should be.  i know this is bgp, but do we really need to
complicate life?

> what does "prepared to receive" mean, and how can "MUST be prepared to 
> receive" be enforced?

like many MUSTs, there is no direct enforcement, only the ability to
diagnose blame in the case of failure and have the resulting tac ticket be
classified as an enhancement request :)

> add something like ".even if the Capability is not advertised".

this section is predicated on advertisement.  personally, as a long term
naggumite (yes, dr postel and i argued about this), i think the whole
send/receive without advertisement is a useless slippery slope and i would
be happy to toss it.

> M2. Section 5 (Error Handling).  "A BGP speaker that has the ability 
> advertised the capability."  This paragraph troubles me a lot because 
> it is in direct contraction with Section 3: "A peer which does not 
> Extended Messages MUST NOT be sent to it.".  However, I think that 
> John Scudder's reasoning [3] makes sense ("keep the session up at
> (almost) all costs", and there's clear precedence in the WG) for the 
> case where the sender did advertise the Capability, but I'm not 
> convinced on the case where it didn't - please include something like 
> John's explanation in the text.

you did see where john went on to say "I acknowledge this choice would be
fairly disgusting, and I understand why the authors didn't make it."

> M2.1.  Even with John's explanation, I find myself thinking that this 
> maybe I won't worry too much about controlling what to send to my 
> peers - specially in cases where it would be easy to just replicate an 
> I know that we can't avoid bad implementations, no matter what text is 
> added - but I think that recognizing the threat (maybe in the Security 
> they don't support it would be good.  I know that there's text in the 
> document already which talks about what to do if the receiver doesn't 
> support Extended Messages - I'm just worried about potential issues 
> with memory allocation if the receiver was not ready.

in the absense of an AD with the guts to let me tear that out, i'll put a
note in sec cons. :)

> M3. Section 5 (Error Handling).  ".reset the session with a Bad 
> Message Length NOTIFICATION." Please be clear and specific: (something 
> like this would be more precise) "...send a NOTIFICATION message with 
> to Bad Message Type, and close the session".  Alternatively, you can 
> rfc4271 already says and there's no need to repeat it here and risk 
> not being precise.

i like removing text!

> M4. Section 5 (Error Handling).  "Similarly, any speaker that treats 
> an improper extended message as a fatal error, MUST do likewise."  It 
> sounds that you're saying that any fatal error will result in a "Bad 
> Message Length NOTIFICATION".  I hope that is not what you meant - and 
> length) doesn't change, right?

ok, jgs, what did you mean by "any speaker that treats an improper extended
message as a fatal error," and what did you think we should do about it.
neither 4271 not 7606 tell what to do with a fatal error per se.

saying treat it as an as an UPDATE Message Error per RFC4271 is not perfect,
as it could be an overly long message of a different type.

clue bat, please.

> M5. Section 5 (Error Handling).  "The inconsistency between the local 
> and remote BGP speakers MUST be reported via syslog and/or SNMP."
> SNMP?  AFAIK, there's no object that can report this inconsistency 
> since there's no NOTIFICATION generated.  In the proposed text by 
> Gunter Van De Velde [4], SNMP and syslog were mentioned as examples - 
> I suggest you follow that path (no need for all the "flowery
> language") and just reference mechanisms by example to avoid having to 
> the inconsistency report to just be a "Bob sent me an Extended 
> Message, but I didn't advertise the Capability to him"-type message, 

> M6.1. Section 5 doesn't describe the behavior if the message is longer 
> M6.2. rfc4271: "The value of the Length field MUST always be at least
> 19 and no greater than 4096" That needs to be updated to 65535.

6.  Changes to RFC4271

> received from a peer, but can't be propagated to others because they 
> don't support Extended Messages

4.  Operation
...

ack

ack

ack

> P4. I don't understand what this means: "Applications generating 
> size."

sure

> N1. "It does enable large BGPsec BGPSEC_PATHs, see 
> [I-D.ietf-sidr-bgpsec-protocol]."  Nice, but superfluous as it refers 

ack

---

From: Enke Chen <[email-masked]>
Date: Mon, 6 Mar 2017 12:22:24 -0800

Hi, Folks:

I see benefits and no drawbacks for the "BGP-Extended Message Capability" to cover
all the message types, that is, requiring a speaker that advertises the capability
to be able to receiving large messages of any type.  While the requirement for the
large message is driven by the UPDATE message, other messages (such as NOTIFICATION
or OPEN) can potentially exceed the 4K message size as well. It is better to deal with
this issue once.

Clearly a large UPDATE message may require a large NOTIFICATION message, e.g., for
carrying a malformed attribute.

Regarding the OPEN message, as BGP capabilities are carried inside the OPEN message
and a number of capabilities are AFI/SAFI specific and thus have the "multiplier"
effect on the message size, potentially the OPEN message may exceed the message size
in the future. This "extended message capability" can be used in a couple of ways to
deal with the large OPEN message if the capability is made to mean support for all
message types:

   o A speaker can remember the capability from its previous OPEN, and infer that
     the large message is most likely supported over the current session, and send
     the large OPEN message if needed. (It can back off from sending the large OPEN
     based on NOTIFICATION message.)

   o A speaker can send a normal OPEN, and once it determines from the received
     OPEN message that the large message capability is supported by the remote
     speaker, the speaker can close the connection and start with a large OPEN.

Admittedly these mechanism are not as elegant as the one that bumps the BGP version.
They can be just as effective (especially the first one) in practice.

Thanks.  -- Enke

On 2/28/17 1:06 PM, Jeffrey Haas wrote:
> Alvaro,
> 
> I'm not speaking for the authors.  However, a few comments on your writeup:
> 
> On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) wrote:
>> Extended Messages MUST be prepared to receive an UPDATE message that is
>> larger than 4096 bytes.“  Only UPDATEs?  I know that the most likely case
>> for exceeding the 4k size is an UPDATE, but why are the other messages not
>> considered?  
> 
> The fundamental issue is with regards to not only the basic behavior of RFC 4271 
> and its earlier RFC 1771 but also to BGP Versioning.
> 
> Those RFCs set the expectation that version 4 of BGP will have at most a 4k
> packet size.  Capability advertisement, an extension on top of BGP, isn't a
> required feature - although it's certainly very common these days.
> 
> Thus, for backward compatibility reasons, OPEN messages must be no bigger
> than 4k if we're still BGP-4.
> 
> I don't think there's an argument for larger KEEPALIVE messages. :-)
> 
> Similarly, the NOTIFICATION with no restrictions for version compatibility
> reasons.  *However*, once BGP has reached the Established state, it is
> possible for it to send longer NOTIFICATION messages, if we permitted it and
> the feature was duly negotiated.  This is probably not the best idea because
> it will still be necessary to be able to deal with an old speaker in such
> cases.  
> 
> Also, most implementations don't dump that much information in the
> NOTIFICATION Data section.  Putting sufficient semantics on the content
> would start to get messy.  We don't want XML or backtrace over that message.
> 
> The case for UPDATE is clear.
> 
> The remaining message with some potential motivation is ROUTE-REFRESH.  The
> basic refresh message is likely to be able to hold AFI/SAFI sets for some
> time.  The ORF feature that is built upon refresh already deals with sending
> its filters over the course of multiple messages.  So, there's not a lot of
> motivation.
> 
> And that's the messages we have so far.  While I can see new messages being
> defined that may want it, I don't think there's a strong argument for it
> today.
> 
>> Also, what does “prepared to receive”
>> mean, and how can “MUST be prepared to receive” be enforced?  Given the
>> discussion in Section 5 (Error Handling), you might want to add something
>> like “…even if the Capability is not advertised”.
> 
> If the capability hasn't been negotiated, then the expectation is that it's
> a PDU error and the session should be dropped.  See prior comments about BGP
> versioning.
> 
>> M2. Section 5 (Error Handling).  “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.”  This paragraph troubles me a lot because it is in direct
>> contraction with Section 3: “A peer which does not advertise this
>> capability MUST NOT send BGP Extended Messages, and BGP Extended Messages
>> MUST NOT be sent to it.”.  However, I think that John Scudder’s reasoning
>> [3] makes sense ("keep the session up at (almost) all costs", and there’s
>> clear precedence in the WG) for the case where the sender did advertise
>> the Capability, but I’m not convinced on the case where it didn’t – please
>> include something like John’s explanation in the text.
> 
> John can own this one.  I find the case a little weaker.  It vaguely makes
> me want a probe message to verify that I can indeed get a full-sized PDU
> through.
> 
>> M5. Section 5 (Error Handling).  “The inconsistency between the local and
>> remote BGP speakers MUST be reported via syslog and/or SNMP.”   SNMP?
>> AFAIK, there’s no object that can report this inconsistency since there’s
>> no NOTIFICATION generated.  In the proposed text by Gunter Van De Velde
>> [4], SNMP and syslog were mentioned as examples – I suggest you follow
>> that path (no need for all the “flowery language”) and just reference
>> mechanisms by example to avoid having to point at how it would be done.
> 
> IMO, "brought to the attention of the operator.  Example mechanisms might
> include syslog or SNMP notifications."
> 
> While you're correct that no IETF standard MIB object covers such a
> scenario, we shouldn't be proscriptive about some vendor deciding they want
> it in their enterprise implementation.
> 
> At some point, we need similar boilerplate language for yang notifications.
> 
>> M7. What about transition/migration/partial deployment?  What should the
>> behavior be if, for example, an Extended Message UPDATE is received from a
>> peer, but can’t be propagated to others because they don’t support
>> Extended Messages (think route reflectors or simple eBGP -> iBGP)??  There
>> should be some guidance for the general case (i.e. when the total size is
>>> 4k due simply to the total amount of information, and not because a
>> single attribute, for example, is really big), and some requirements
>> looking forward to potential new messages/attributes that specifically
>> rely on Extended Messages.
> 
> I'm not sure such guidance belongs in this document.  We already have
> scenarios wherein normal protocol machinery can result in messages that are
> too large.  The expected behavior is "treat as withdraw" to the next
> downstream, similar to the BGP Error handling RFC.
> 
> Examples of this include AS_PATH or CLUSTER_LIST attributes needing to add a
> new entry on a full PDU.
> 
>> M7.2. What should the default be for this extension?  Should it be enabled by default or not?
> 
> IMO, there are good reasons to not turn it on for existing BGP deployments
> but alternatively good reasons once the extension is widely enough present
> in a given topology.  The latter example includes bgpsec.
> 
> -- Jeff
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Mar 2017 19:39:54 -0500

Enke: 

<individual contributor's hat on> 
This reply is being a bit specific about RFC4271.  You may have implied all of this in your message, but after the AD's comments on this draft I think it is best to be specific on the BGP FSM on RFC4271.  

According to RFC4271, the event which is generated  when a BGP packet is received by a peer with a message size over 4096 is BGP Header Error event (event 21).  It does not matter which BGP message generates this error.   Therefore,  the extended BGP message specification ( version -21) could handle the OPEN message if the following text was changed: 

Old/
   [RFC4271] states "The value of the Length field MUST always be at
   least 19 and no greater than 4096."  This document changes the latter
   number to 65535 for UPDATE messages.

   [RFC4271] Sec 6.1, specifies raising an error if the length of a
   message is over 4096 octets.  For UPDATE messages, if the receiver
   has advertised the capability to receive Extended Messages, this
   document raises that limit to 65535.
/ 

New / 
   [RFC4271] states "The value of the Length field MUST always be at
   least 19 and no greater than 4096."  This document changes the latter
   number to 65535 for BGP messages.

   [RFC4271] Sec 6.1, specifies raising an error if the length of a
   message is over 4096 octets.  For BGP messages, if the receiver
   is configured to be a  BGP speaker to be an Extended Message speaker, 
   this  document raises that limit to 65535.
/  

Randy may be indicating the problem of 

TCP connection comes up 
BGP-speaker 1 (Extended size OPEN ) --->  
                                     <---BGP speaker 2 (only supports normal OPEN) 
                                          But wants to indicate that the EXTENDED OPEN is bad. 

This is actually handled in the current BGP FSM by using the SENDNOTIFICATIONwithoutOPEN attribute set to TRUE.   The BGP speaker2 with this option does the following 

BGP-speaker 1 (Extended size open) ---> 
                              <-------BGP speaker 2: NOTIFICATION:  HEADER ERR, Message Length Error. 

You can find this on p. 56 of RFC4271, see Event 21 (BGP message Header Error) with the following text: 

"      If BGP message header checking (Event 21) or OPEN message checking
      detects an error (Event 22) (see Section 6.2), the local system:
        - (optionally) If the SendNOTIFICATIONwithoutOPEN attribute is
          set to TRUE, then the local system first sends a NOTIFICATION
          message with the appropriate error code, and then
        - stops the ConnectRetryTimer (if running) and sets the
          ConnectRetryTimer to zero,
        - releases all BGP resources,
        - drops the TCP connection,
        - increments the ConnectRetryCounter by 1,
        - (optionally) performs peer oscillation damping if the
          DampPeerOscillations attribute is set to TRUE, and
        - changes its state to Idle.

Note, if the SENDNOTIFICATIONwithoutOpen Attribute is set, then the error code will provide Bad Message Header, sub-code: Bad message length.   With this notification, the BGP speaker sending the OPEN with the extended message can have a pretty understanding of what happened.   If the BGP speaker receives this message in response to an oversize open, it would be prudent for the BGP implementation to send a BGP Open (with/without the capability that advertises the extended message). 

If you do use the extended message capability, the scenario might go

BGP peer-1                 BGP peer-2 
Capable of                 not capable of 
Extended msg           extended msg

BGP Open (Extended message) -----> 
                                <---- BGP notification (BGP Message header error, Bad message length) 
BGP open (normal, Extended message capability)---->  
		   <--- BGP Open (normal, [no extended message capability) 
BGP open (normal, [no extended message capability]----> 
 
With the SENDNOTIFICATIONwithoutOpen Attribute, I do not see how Randy gets into an open-loop.   I'm sure Randy will let me know if I've missed something in the scenario he's suggesting. 

Sue Hares

-----Original Message-----
From: Enke Chen [mailto:[email-masked]] 
Sent: Monday, March 6, 2017 3:22 PM
To: Jeffrey Haas; Alvaro Retana (aretana)
Cc: [email-masked]; [email-masked]; Susan Hares; [email-masked]; Enke Chen
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

Hi, Folks:

I see benefits and no drawbacks for the "BGP-Extended Message Capability" to cover all the message types, that is, requiring a speaker that advertises the capability to be able to receiving large messages of any type.  While the requirement for the large message is driven by the UPDATE message, other messages (such as NOTIFICATION or OPEN) can potentially exceed the 4K message size as well. It is better to deal with this issue once.

Clearly a large UPDATE message may require a large NOTIFICATION message, e.g., for carrying a malformed attribute.

Regarding the OPEN message, as BGP capabilities are carried inside the OPEN message and a number of capabilities are AFI/SAFI specific and thus have the "multiplier"
effect on the message size, potentially the OPEN message may exceed the message size in the future. This "extended message capability" can be used in a couple of ways to deal with the large OPEN message if the capability is made to mean support for all message types:

Thanks.  -- Enke

On 2/28/17 1:06 PM, Jeffrey Haas wrote:
>> is larger than 4096 bytes.“  Only UPDATEs?  I know that the most 
>> likely case for exceeding the 4k size is an UPDATE, but why are the 
>> other messages not considered?
> 
> The fundamental issue is with regards to not only the basic behavior 
> of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning.
> 
> Those RFCs set the expectation that version 4 of BGP will have at most 
> a 4k packet size.  Capability advertisement, an extension on top of 
> BGP, isn't a required feature - although it's certainly very common these days.
> 
> Thus, for backward compatibility reasons, OPEN messages must be no 
> bigger than 4k if we're still BGP-4.
> 
> Similarly, the NOTIFICATION with no restrictions for version 
> compatibility reasons.  *However*, once BGP has reached the 
> Established state, it is possible for it to send longer NOTIFICATION 
> messages, if we permitted it and the feature was duly negotiated.  
> This is probably not the best idea because it will still be necessary 
> to be able to deal with an old speaker in such cases.
> 
> NOTIFICATION Data section.  Putting sufficient semantics on the 
> content would start to get messy.  We don't want XML or backtrace over that message.
> 
> The remaining message with some potential motivation is ROUTE-REFRESH.  
> The basic refresh message is likely to be able to hold AFI/SAFI sets 
> for some time.  The ORF feature that is built upon refresh already 
> deals with sending its filters over the course of multiple messages.  
> So, there's not a lot of motivation.
> 
> And that's the messages we have so far.  While I can see new messages 
> being defined that may want it, I don't think there's a strong 
> argument for it today.
> 
>> mean, and how can “MUST be prepared to receive” be enforced?  Given 
>> the discussion in Section 5 (Error Handling), you might want to add 
>> something like “…even if the Capability is not advertised”.
> 
> If the capability hasn't been negotiated, then the expectation is that 
> it's a PDU error and the session should be dropped.  See prior 
> comments about BGP versioning.
> 
>> advertise this capability MUST NOT send BGP Extended Messages, and 
>> BGP Extended Messages MUST NOT be sent to it.”.  However, I think 
>> that John Scudder’s reasoning [3] makes sense ("keep the session up 
>> at (almost) all costs", and there’s clear precedence in the WG) for 
>> the case where the sender did advertise the Capability, but I’m not 
>> convinced on the case where it didn’t – please include something like John’s explanation in the text.
> 
> John can own this one.  I find the case a little weaker.  It vaguely 
> makes me want a probe message to verify that I can indeed get a 
> full-sized PDU through.
> 
>> AFAIK, there’s no object that can report this inconsistency since 
>> there’s no NOTIFICATION generated.  In the proposed text by Gunter 
>> Van De Velde [4], SNMP and syslog were mentioned as examples – I 
>> suggest you follow that path (no need for all the “flowery language”) 
>> and just reference mechanisms by example to avoid having to point at how it would be done.
> 
> IMO, "brought to the attention of the operator.  Example mechanisms 
> might include syslog or SNMP notifications."
> 
> scenario, we shouldn't be proscriptive about some vendor deciding they 
> want it in their enterprise implementation.
> 
>> don’t support Extended Messages (think route reflectors or simple 
>> eBGP -> iBGP)??  There should be some guidance for the general case 
>> (i.e. when the total size is
>> looking forward to potential new messages/attributes that 
>> specifically rely on Extended Messages.
> 
> scenarios wherein normal protocol machinery can result in messages 
> that are too large.  The expected behavior is "treat as withdraw" to 
> the next downstream, similar to the BGP Error handling RFC.
> 
> Examples of this include AS_PATH or CLUSTER_LIST attributes needing to 
> add a new entry on a full PDU.
> 
> IMO, there are good reasons to not turn it on for existing BGP 
> deployments but alternatively good reasons once the extension is 
> widely enough present in a given topology.  The latter example includes bgpsec.
> 
> -- Jeff
>

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Mar 2017 19:42:09 -0500

Enke and IDR WG: 
<WG chair hat on> 
If there is enough concern about the extended messages covering all messages versus UPDATE messages,  I will need to do  1 week call on this topic.  
<WG Chair hat off> 

Sue Hares 

-----Original Message-----
From: Enke Chen [mailto:[email-masked]] 
Sent: Monday, March 6, 2017 3:22 PM
To: Jeffrey Haas; Alvaro Retana (aretana)
Cc: [email-masked]; [email-masked]; Susan Hares; [email-masked]; Enke Chen
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

Hi, Folks:

Thanks.  -- Enke

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 7 Mar 2017 11:08:33 +0100

Hi Sue, Authors,

Current draft says:

*"Currently, the Extended Message Capability only applies to UPDATE
messages."*

I would like to ask authors to change the below restriction to also
consider future BGP messages still compliant with RFC4271 RFC. I would
therefor propose to extend the above sentence with:

*"The Extended Message Capability applies to UPDATE messages as well as if
required to any new BGP messages."*

- - -

I am less concerned in making Extended Message Capability applicable to
OPEN or KEEPALIVE messages. IMHO Capabilities from OPEN should be moved to
new BGP message (BGP CAPABILITIES MESSAGE) which would by design allow
their dynamic nature along the lines of current dynamic capabilities
proposal except outside of messing up with OPEN.

For NOTIFICATION as Enke already pointed there is good reason for it to be
extended. Alternatively a new provision for signalling the errors between
peers should be provided in new message (example: BGP OPERATIONAL message).

Thx,
R.

On Tue, Mar 7, 2017 at 1:42 AM, Susan Hares <[email-masked]> wrote:

> Enke and IDR WG:
> <WG chair hat on>
> If there is enough concern about the extended messages covering all
> messages versus UPDATE messages,  I will need to do  1 week call on this
> topic.
> <WG Chair hat off>
>
> Sue Hares
>
> I see benefits and no drawbacks for the "BGP-Extended Message Capability"
> to cover all the message types, that is, requiring a speaker that
> advertises the capability to be able to receiving large messages of any
> type.  While the requirement for the large message is driven by the UPDATE
> message, other messages (such as NOTIFICATION or OPEN) can potentially
> exceed the 4K message size as well. It is better to deal with this issue
> once.
>
> Clearly a large UPDATE message may require a large NOTIFICATION message,
> e.g., for carrying a malformed attribute.
>
> Regarding the OPEN message, as BGP capabilities are carried inside the
> OPEN message and a number of capabilities are AFI/SAFI specific and thus
> have the "multiplier"
> effect on the message size, potentially the OPEN message may exceed the
> message size in the future. This "extended message capability" can be used
> in a couple of ways to deal with the large OPEN message if the capability
> is made to mean support for all message types:
>
> and

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 08:55:45 -0500

Robert: 

<individual contributor hat on>

This is a more complex change to the state machine than just extending all messages. 

Sue Hares 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, March 7, 2017 5:09 AM
To: Susan Hares; Randy Bush
Cc: Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); [email-masked]; [email-masked]; idr wg
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

Hi Sue, Authors,

Current draft says: 

"Currently, the Extended Message Capability only applies to UPDATE messages."

I would like to ask authors to change the below restriction to also consider future BGP messages still compliant with RFC4271 RFC. I would therefor propose to extend the above sentence with:

"The Extended Message Capability applies to UPDATE messages as well as if required to any new BGP messages."

- - -

I am less concerned in making Extended Message Capability applicable to OPEN or KEEPALIVE messages. IMHO Capabilities from OPEN should be moved to new BGP message (BGP CAPABILITIES MESSAGE) which would by design allow their dynamic nature along the lines of current dynamic capabilities proposal except outside of messing up with OPEN. 

For NOTIFICATION as Enke already pointed there is good reason for it to be extended. Alternatively a new provision for signalling the errors between peers should be provided in new message (example: BGP OPERATIONAL message). 

Thx,

R.

 

Enke and IDR WG:
<WG chair hat on>

Sue Hares

-----Original Message-----
From: Enke Chen [mailto:[email-masked]]
Sent: Monday, March 6, 2017 3:22 PM
To: Jeffrey Haas; Alvaro Retana (aretana)
Cc: [email-masked]; [email-masked]; Susan Hares; [email-masked]; Enke Chen
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

Hi, Folks:

Thanks.  -- Enke

---

From: "Russ White" <[email-masked]>
Date: Tue, 7 Mar 2017 10:06:08 -0500

> I would like to ask authors to change the below restriction to also consider
> future BGP messages still compliant with RFC4271 RFC. I would therefor
> propose to extend the above sentence with:

I agree with this assessment -- the new extended message type should apply to any message type necessary.

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 7 Mar 2017 16:14:09 +0100

Sue,

I don't understand your point of "more complex".

Current proposal extends single message type. I indicated that future
defined messages needs also to have an option to be extended with proposed
capability.

That's all.

Thx,
Robert

On Tue, Mar 7, 2017 at 2:55 PM, Susan Hares <[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, March 7, 2017 5:09 AM
> *To:* Susan Hares; Randy Bush
> *Cc:* Enke Chen; Jeffrey Haas; Alvaro Retana (aretana);
> [email-masked]; [email-masked]; idr wg
>
> *Subject:* Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20
>
>
>
> Hi Sue, Authors,
>
>
>
> Current draft says:
>
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 10:23:32 -0500

Robert: 

Let’s take this offline.  The complexity is in the changes to the RFC4271 finite state machine.  I’m glad to explain the design of the BGP FSM offline, but I’ve gone through the precise reasons already on the mail list.   My suggestion is to include all messages including future messages if approved.   

Sue 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, March 7, 2017 10:14 AM
To: Susan Hares
Cc: Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); [email-masked]; [email-masked]; idr wg
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

Sue, 

Current proposal extends single message type. I indicated that future defined messages needs also to have an option to be extended with proposed capability. 

That's all. 

Thx,

Robert

Robert: 

Sue Hares 

Hi Sue, Authors,

Current draft says: 

- - -

Thx,

R.

 

Enke and IDR WG:
<WG chair hat on>

Sue Hares

-----Original Message-----
From: Enke Chen [mailto:[email-masked]]
Sent: Monday, March 6, 2017 3:22 PM
To: Jeffrey Haas; Alvaro Retana (aretana)
Cc: [email-masked]; [email-masked]; Susan Hares; [email-masked]; Enke Chen
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

Hi, Folks:

Thanks.  -- Enke

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 7 Mar 2017 16:32:45 +0100

Hi Sue,

> My suggestion is to include all messages including future messages if
approved.

Ahh then it is great - we are in sync !

My other comments were just an opinion ... but if it is easier to extend
all messages then perfect.

Cheers,
R.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 10:32:55 -0500

Robert:

<individual contributor’s hat on> 

Yep  - Easier to just include all messages.  

Sue 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, March 7, 2017 10:33 AM
To: Susan Hares
Cc: Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); [email-masked]; [email-masked]; idr wg
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

Hi Sue,

> My suggestion is to include all messages including future messages if approved.  

My other comments were just an opinion ... but if it is easier to extend all messages then perfect. 

Cheers,

R.

---

From: Enke Chen <[email-masked]>
Date: Tue, 7 Mar 2017 10:45:22 -0800

Hi, Folks:

o There is no extra work for a receiver to cover message types other than UPDATE.
o There is a little bit work for a sender that wishes to send a large OPEN (e.g.,
  using the prior capability and possibly subsequent NOTIFICATION).

Additionally, I do not see a need to touch on the FSM specified in RFC 4271 even
in the case of sending a large OPEN, which potentially may involve two separate
consecutive sessions but each session would just follow the existing FSM.

Thanks.   -- Enke

On 3/7/17 7:32 AM, Susan Hares wrote:
> *From:[email-masked] [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, March 7, 2017 10:33 AM
> *To:* Susan Hares
> *Cc:* Randy Bush; Enke Chen; Jeffrey Haas; Alvaro Retana (aretana); [email-masked]; [email-masked]; idr wg

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 7 Mar 2017 22:07:10 +0000

On 2/28/17, 4:06 PM, "Jeffrey Haas" <[email-masked]> wrote:

…
> Examples of this include AS_PATH or CLUSTER_LIST attributes needing to add a

Ok…but is that documented anywhere?  I may be missing it, but I couldn’t find anything like that in rfc4271 or rfc7606.

Thanks!

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 7 Mar 2017 22:07:58 +0000

On 3/5/17, 2:46 AM, "Randy Bush" <[email-masked]> wrote:

Randy:

Hi!

I have some in-line comments.  Thanks for the updated document.

Alvaro.

…
> in the absense of an AD with the guts to let me tear that out, i'll put

☺

Personally, I don’t like this path of accepting anything that you didn’t negotiate.  However, I have to assume that, by the time the Chairs request the publication of a document, there is already consensus in the WG – in this case, the Shepherd’s write-up says that there is “strong consensus” [1].  From your answers and the text below, I think you and I would both have been in the rough on this consensus call.

[1] https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/shepherdwriteup/ 

>    groups.  At best, this will result in erroes; at worst, buffer

This text raises the obvious question of: why even do this if it may be so bad?

The text should reflect the WG consensus – not your personal opinion (or mine, for that matter).  Please reword to be more objective.

…
>    document raises that limit to 65535.

This last paragraph is not completely true because of Section 4.

>    Extended Message is a sure path to routing failure.

If this text is in the document, then you’re basically saying that you shouldn’t deploy anything that could need more than 4k because it is a “sure path to routing failure”.  Again, please reflect WG consensus…

What I was really hoping for was something like what you wrote above about BGPSec: if a 4k-neighbor is encountered, then just revert to “normal operation”.  I’m not asking you to put that text in this document, mostly because there might not be “normal operation” for something new in the future (like there is for BGPSec).  So, what am I asking for?  Two things:

- guidance of what to do if the “normal operation” of adding attributes results in >4k.  Maybe “treat as withdraw” would be appropriate…

- some text saying that if a future extension knows it needs more than 4k (like BGPSec does), then it MUST include some text about what to do.  IOW, you can’t solve the future case now, let them solve it later.

BTW, it looks like you may have overlooked these other questions: “What should the default be for this extension?  Should it be enabled by default or not?”

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 7 Mar 2017 22:08:56 +0000

On 3/5/17, 3:17 PM, "Susan Hares" <[email-masked]> wrote:

Sue:

Hi!

> speak about these issues - you may have missed why the BGP FSM is there.

I’m not sure why you disagree with my comments…but if I interpret your points correctly, I think you’re saying that this document should also update the FSM where needed, is that right?  If so, then I agree with that.

Thanks!

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 7 Mar 2017 22:15:52 +0000

Hi!

After reading the messages in this thread, I’m returning the document to the WG to finish the discussion there.

Based on the discussion, I think there are some open items that I would like the WG to close on (in no particular order):

- Should this document address all messages or just UPDATES?  [The Chairs asked for feedback from grow.]

- Are any updates needed to the FSM?

- Is it ok to send/accept Extended Messages without having received/advertised the Capability?  This is a significant change in the way BGP operates – and would set an important precedent.

- What about incremental deployment?  Should there be operational guidance?  If so, what should that guidance be?

Thanks!

Alvaro.

On 3/6/17, 7:42 PM, "Susan Hares" <[email-masked]> wrote:

> <WG chair hat on> 
> If there is enough concern about the extended messages covering all messages versus 
> UPDATE messages,  I will need to do  1 week call on this topic.  
> <WG Chair hat off>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Mar 2017 17:14:52 -0500

Alvaro:

<shepherd hat on> 
I'm saying your suggested revisions did not correctly align with RFC4271 specification, specifically in the area of the FSM.  I objected to version-21 because it contained errors by misaligning the text with the IDR FSM.  (see mail list for specific issues0.  I proposed a cleaner replacement text.  Earlier versions did not hit this misalignment.  As a shepherd, I felt version-21 could not go forward.  
<shepherd hat off> 
<individual contributor, co-author on RFC4271 hat on> 
I am saying the better way is to just utilize the BGP message header length error function (0-4096 normal, 4097-65535 extended) and let the FSM handle it.  Then all BGP messages could be large. See the email thread. 
<individual contributor hat off> 
<WG chair hat on> 
This is why we have the thread on the mail list about accepting all messages
</WG chair hat off> 

Happy changing hat day to you! 
Sue
-----Original Message-----
From: Alvaro Retana (aretana) [mailto:[email-masked]] 
Sent: Tuesday, March 7, 2017 5:09 PM
To: Susan Hares; 'Randy Bush'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: AD Review of draft-ietf-idr-bgp-extended-messages-20

Sue:

Hi!

Thanks!

Alvaro.

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Tue, 7 Mar 2017 23:44:11 +0000

I am wondering – according to RFC 4271, how can an OPEN message ever exceed 284 bytes?
The bgp message header has 19 bytes and the OPEN message payload adds 10. This is 29, then the only 
addition here are the Optional Parameters which cannot exceed 255 bytes combined due to the 1 byte length field.

Therefore, an open message cannot exceed 284 bytes and if larger than 284 bytes, wouldn’t it be invalid. 

In this regard, I don’t really understand the whole discussion about allowing an OPEN message larger than 4K. 
It shouldn’t even be larger than 284 bytes?  Maybe I am missing something.

BTW, same is true for KEEPALIVE (max 19 bytes)

Oliver

On 3/7/17, 1:45 PM, "Idr on behalf of Enke Chen" <[email-masked] on behalf of [email-masked]> wrote:

    Hi, Folks:

    
    Thanks.   -- Enke

---

From: Enke Chen <[email-masked]>
Date: Tue, 7 Mar 2017 15:49:17 -0800

Please check out the following document:

Extended Optional Parameters Length for BGP OPEN Message
draft-ietf-idr-ext-opt-param-02

-- Enke

---

From: Enke Chen <[email-masked]>
Date: Tue, 7 Mar 2017 15:51:21 -0800

https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/
draft-ietf-idr-ext-opt-param-05

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 8 Mar 2017 01:21:14 +0000

Enke,

thanks for the pointer. With this in mind, it makes perfectly sense then to have all bgp messages included rather than “cherry picking” some of them.

Oliver

On 3/7/17, 6:49 PM, "Enke Chen" <[email-masked]> wrote:

    
    -- Enke

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 8 Mar 2017 20:04:21 +0000

I don't think it makes sense to fallback if a long OPEN message fails.
Suppose the OPEN message is 4100 bytes long and it fails.
How will you shrink it?
The operator will need to remove some features from the configuration before trying again.

Thanks,
Jakob.

> From: Idr [mailto:[email-masked]] On Behalf Of Borchert, Oliver (Fed)
> Sent: Tuesday, March 07, 2017 5:21 PM
> To: Enke Chen (enkechen) <[email-masked]>
> Cc: 'idr wg' <[email-masked]>; [email-masked]; 'Robert Raszuk' <[email-masked]>;
> Susan Hares <[email-masked]>; [email-masked]

---

From: Enke Chen <[email-masked]>
Date: Wed, 8 Mar 2017 12:13:38 -0800

If one has to send a large OPEN, then it is rejected by the remote speaker, 
then the session needs to be held down (or for slow retry) until the remote
speaker is upgraded or the OPEN size reduced locally as you are saying.

The details need to be specified in a new revision.

Thanks.  -- Enke

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 8 Mar 2017 13:35:01 -0800

> On Mar 8, 2017, at 12:13 PM, Enke Chen <[email-masked]> wrote:
> 

This covers my prior comment: The minute you move to extended BGP Open size, you change what wiggle room we've left for version negotiation.

And perhaps that's fine.  I've spent my entire networking life in BGP-4.  A BGP-5 that only has interop with BGP-4 will likely be fine.

That said, you need to say this in the specs.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 8 Mar 2017 13:36:47 -0800

> On Mar 7, 2017, at 2:07 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 

At best, this is "reading between the lines".

If you can't form a valid PDU to encode in your Adj-rib-out, you withdraw your entry from the adj-rib-out.  This means you send an explicit withdraw.

I think it'd be gross to take this specific document and try to force it to be a normative clarification to this point.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Mar 2017 20:19:21 -0500

Enke and Jakob: 

I am not commenting on the operational desires or your implementations in this message, only to clarify that the "slow retry" is not an absolute in the state machine.  There is also no logical difference in the current statement machine between BGP header error (Event 21) or an OPEN message header error (Event 22) in the FSM. 

So, if you are talking code and the RFC4271 specification in your messages - I do not understand your comments.  RFC4271 consider the issues you are indicating and put in optional switches to control behaviors.  There are knobs to have no peer damping, little peer damping or lots of peer damping.    It is also possible to have logic in implementations which sets these options based on a previous response. 

If you are speaking about your implementations, you know best. 

Sue 

==========================

If the OPEN exceeds the maximum size, it is a header size error (Event 21, p 49, RFC4271 ) in the state machine.  If the logical flag SendNOTIFICATIONwithoutOPEN (p. 37, RFC4271), then the state machine will respond to an open with a Notification with the header error message. 

Two possible sequences in the FSM if the logical SENDNOTIFICATIONwithoutOpen is sent 

Sequence 1 - Peer with Extended BGP message establishes first 

TCP connection establish ------
Send Open ---> 
[open sent state] 
(5000)                 <----- NOTIFICATION (header error) 
		      Performs peer damping (if this option is set) 
		       Peer 2 goes to idle and restarts 
		      [p. 57, RFC4271] 

Reception of NOTIFICATON
Clears all BGP resources 
Goes to IDLE.
Manual/automatic start can restart session 

If you configure peer damping, then you have a delay. 
If you configure "no peer damping" and "automatic start"
And the implementation logic knows to switch back to 4096,  
This sequence does not have to delay the peer. 

If you configure peer damping, then it does damp.
If not, you can sequence through this quickly.  
 
Sequence 2 - Peer with Normal BGP sends first open 

TCP connection 
          <--------- (open) (less than or equal to 4096) 
		No extended message capability 

Open ----> 
Extended peer should not send  a OPEN with more than 4096. 

====================
You could specify in a specification these optional settings + peer logic without changing RFC4271 FSM. 
You just would specify some optional settings as mandatory and a logic around them. 
I agree with Enke that additional text should be created to define these for open. 

If you specify that the Open cannot be greater than 4096, then the logic changes in the 
OPEN validation code.  And the errors messages is OPEN-MSG-Format error. 
You would go through the exact sequence in the FSM (see page 57 of RFC4271), 
And the error is not specific to the error length.  

Sue 

-----Original Message-----
From: Enke Chen [mailto:[email-masked]] 
Sent: Wednesday, March 8, 2017 3:14 PM
To: Jakob Heitz (jheitz)
Cc: Borchert, Oliver (Fed); 'idr wg'; [email-masked]; 'Robert Raszuk'; Susan Hares; [email-masked]; Enke Chen
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

If one has to send a large OPEN, then it is rejected by the remote speaker, then the session needs to be held down (or for slow retry) until the remote speaker is upgraded or the OPEN size reduced locally as you are saying.

Thanks.  -- Enke

On 3/8/17 12:04 PM, Jakob Heitz (jheitz) wrote:
>> Cc: 'idr wg' <[email-masked]>; 
>> [email-masked]; 'Robert Raszuk' 
>> <[email-masked]>; Susan Hares <[email-masked]>; 
>> [email-masked]
>> thanks for the pointer. With this in mind, it makes perfectly sense 
>> then to have all bgp messages included rather than “cherry picking” some of them.
>>
>> Oliver
>>
>>     > addition here are the Optional Parameters which cannot exceed 
>> 255 bytes combined due to the 1 byte length field.
>>     >

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Mar 2017 20:29:37 -0500

Jeff:

Caveat - I am not commenting on operational issues.  If your brief comment
denotes some operational issues, I would appreciate a longer description
on-list or off-list. 

If you are comment on the functionality within the RFC4271 FSM, I am not
sure why the "wiggle room is reduced when the open message size is changed"?
I have been specific on this list as to the functionality a message header
length error enacts (Event 21) versus an Open Message Header enacts (Event
22).    Please be as specific in your response if it is a FSM issues. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Wednesday, March 8, 2017 4:35 PM
To: Enke Chen
Cc: idr wg; Robert Raszuk; [email-masked];
[email-masked]; Susan Hares
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

> If one has to send a large OPEN, then it is rejected by the remote 
> speaker, then the session needs to be held down (or for slow retry) 
> until the remote speaker is upgraded or the OPEN size reduced locally as
you are saying.
> The details need to be specified in a new revision.

This covers my prior comment: The minute you move to extended BGP Open size,
you change what wiggle room we've left for version negotiation.

And perhaps that's fine.  I've spent my entire networking life in BGP-4.  A
BGP-5 that only has interop with BGP-4 will likely be fine.

-- Jeff

---

From: Thomas Mangin <[email-masked]>
Date: Mon, 13 Mar 2017 09:31:23 +0000

Hello,

I just noticed that I tried to re-invent
draft-ietf-idr-ext-opt-param [1] on grow. For people not on both list,
here are the summary of what I found.

At least one implementation seen
in the wild (read ExaBGP) is buggy and do not check the "Optional
Parameters Length", parsing the rest of the OPEN buffer without
truncating
it.

https://github.com/Exa-Networks/exabgp/blob/974f97fc6be63f0b05755ffc3e1ea69a02c0505b/lib/exabgp/bgp/message/open/capability/capabilities.py#L159

While
I now fixed the bug, using 255 as a values and expecting the speaker to
handle this number as "magical" may break some deployment down the
line.

While I can only apologise for letting such a error in my code, I
would assume that more than one "home brewed" implementation may perform
bad or lazy OPEN parsing and that therefore the draft as written would
at some point break some currently working BGP session.

I therefore
proposed on grow an alternative way to encode the extended length within
a capability - total or extra bytes after the initial value in the 1
bytes length, and asking new implementation to make sure that the data
within the one byte length remains valid.
This approach does not change
at all the parsing of the current OPEN and for buggy implementation
ignoring the length (parsing the whole payload - like ExaBGP did), it
will continue to work, this change is transparent.

However this change
would not allow to extend an individual capability size (from one byte
to two) the way the current encoding propose, it would however allow
partial capability exchange between a speaker aware of the extension (if
this is a good or bad thing is surely up to debate).

I also realise
that it may be several years before the extended encoding, even if
available today, is required due to the growth of the OPEN size. I am
therefore only pointing this issue to the list for information so that
the author can decide if they consider this scenario as probable and
worthy of consideration or not.

Sincerely,

Thomas

On 2017-03-07
23:51, Enke Chen wrote: 

https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/
[1]draft-ietf-idr-ext-opt-param-05

Links:
------
[1]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Mar 2017 18:52:43 -0400

Sue,

> 22).    Please be as specific in your response if it is a FSM issues. 

This is to some extent a simple issue with regard to extended and
non-extended speakers trying to interoperate.  However, the version case
with the changes under discussion complicate the matter slightly.

Presume old RFC 4271 speaker, O.
Presume new extended message speaker E.

If E sends an open message > 4096 octets to O, the generally expected
behavior is that O will send a notification message with a Bad Message
Length subcode.  O has no reason to change its behavior.

E may have course note this specific error and try to back-off, if possible
to a <= 4096 message size.  However, I tend to agree with other threads that
we're better off blocking the peering session from coming up without further
intervention.  I am *not* a supporter of deferring the larger Open
operations to another message; we'd be better off getting something like
Dynamic Capabilities working and we've had a number of discussions about why
some of that behavior is problematic.

(Alternatively, we simply have the extended open message, but that's a bit
of a change in the FSM.)

So... why did I bring up the version negotiation point?

Mostly because for version negotiation to work, once we leave -4 behind, we
need to be able to generate an Unsupported Version Number error.  We can't
do that if the receiver simply dumps the session due to hitting the message
length validation failure first.

As I mention too tersely in my response... oh well.  But it does mean that
if we go with > 4k open messages that old speakers will only get upset about
PDUs that are too big rather than giving us other useful information about
why session negotiation is failing.

I suspect this is fine, but it should be a choice that is clearly
understood.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 15 Mar 2017 11:37:56 -0400

Jeff:

I now understand your "wiggle room".   We both agree on the FSM actions and
that we need operator input on the choices. 

1) Open Message < 4096 - hold while at BGP version 4  
  [This can be held at the Open Message header tests (event 22)]
  While all other MESSAGES > 4096 if 
  open capability for extended messages. 

2) all Messages at > 4096 - with BGP version 5 
    (no capability negotiation) 

3) Open Message < 4096  - with BGP version 4 +  Dynamic Capabilities
    All other BGP-4 messages > 4096 if 
    Open capability for extended messages 

4) Update message only at > 4096 
   if  Open capability for extended messages

Did I miss an open?  If not, I will open a request for feedback on IDR, and
add this to the grow request for input. 

Sue Hares 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Tuesday, March 14, 2017 6:53 PM
To: Susan Hares
Cc: 'Enke Chen'; 'idr wg'; 'Robert Raszuk'; [email-masked];
[email-masked]
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

Sue,

On Wed, Mar 08, 2017 at 08:29:37PM -0500, Susan Hares wrote:
> Caveat - I am not commenting on operational issues.  If your brief 
> comment denotes some operational issues, I would appreciate a longer 
> description on-list or off-list.
> 
> If you are comment on the functionality within the RFC4271 FSM, I am 
> not sure why the "wiggle room is reduced when the open message size is
changed"?
> I have been specific on this list as to the functionality a message 
> header length error enacts (Event 21) versus an Open Message Header enacts
(Event

-- Jeff