Subject: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

From: Alvaro Retana <[email-masked]>
Date: Wed, 31 Jul 2019 13:06:04 -0700

On July 31, 2019 at 1:31:11 PM, Susan Hares ([email-masked]) wrote:

Dear WG:

As I hope all of you know, the Extended Messages draft is being processed
by the IESG.

Enke had brought up [1] some confusion in the text in rfc5492 related to
the need, or not, for both BGP speakers to advertise a Capability before it
can be used.  I discussed this point with Enke and John Scudder last week
in Montreal — we looked at the text in the RFC and how recent Capabilities
had been specified — and concluded that the intent of the RFC was to
require at least one speaker to advertise the Capability…but that it should
be the responsibility of any document defining a Capability to explicitly
specify any changes.

IOW, in some cases it may be enough for one of the peers to advertise a
Capability, but in other cases it may be required for both to do so.
 [Enke/John will work on an Update to rfc5492 to clarify.]

Related to Extended Messages, here’s is what Enke proposed on the list [2]:

   As long as Speaker A is able and willing to receive large messages (by
advertising
   the capability), its neighbor would be allowed to send such messages to
Speaker A.
   Such behavior does not depend on whether Speaker A is able / willing /
need to
   send any large messages to its neighbors.

We have modified the text in draft-ietf-idr-bgp-extended-messages to
reflect Enke’s proposal (from -35):

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

   An implementation that advertises the BGP Extended Message capability
   MUST be capable of receiving a message with a Length up to and
   including 65,535 octets.

During the IESG Evaluation, Sue pointed out that we removed the piece of
text below:

Just to let you know that the text below:

“A peer which does not advertise this capability MUST NOT send BGP

   Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”

was added due to comments on the IDR WG list from reviewers and operators.

Given that Extended Messages is a very important extension to BGP, and even
though I didn’t see objections in the thread mentioned above, I want to
confirm one more time that the current text is ok with the WG.  The
effective change is really related to the piece that says "A peer which
does not advertise this capability MUST NOT send BGP Extended Messages”,
which would require that both peers advertise the Capability before it can
be used.

Please reply with any comments by end-of-day on August 8, 2019.  Please
explain any arguments against what is currently specified in -35.   The
document is scheduled to be considered by the IESG on Aug/8, but I will
hold approving publication until there is consensus on this thread.

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/idr/vaBLOKHQZlRCiJOMTT8VjJrWp7c
[2] https://mailarchive.ietf.org/arch/msg/idr/K5rA5rVci6VhMv5-UqXXaoRlvXo

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 31 Jul 2019 17:16:02 -0400

On Wed, Jul 31, 2019 at 01:06:04PM -0700, Alvaro Retana wrote:
> confirm one more time that the current text is ok with the WG. 

I am fine with the current text, although my opinion is nuanced.

By requiring bi-directional advertisement of the capability, UPDATEs sent
from one can have NOTIFICATIONs of similar size.  This avoids some ugly edge
conditions that would result from uni-directional advertisement of the
capability.

The converse argument, which I'm not supporting, is that uni-directional
advertisement intentionally lets peers opt-out of receiving extended
messages, even it understands them.

Let the bi-directional requirement stand.

Note that RFC 6793 (4-byte ASes) require bi-directional advertisement.

-- Jeff

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Wed, 31 Jul 2019 21:50:08 +0000

>>  Note that RFC 6793 (4-byte ASes) require bi-directional advertisement.

No, this statement is not correct. It is fundamental (in transition) for a BGP  speaker
to be able to talk to both NEW speakers (that have advertised the capability), and OLD
speakers (that have not advertised the capability).  Different encodings are used in the
UPDATE message depending on whether the 4-byte AS capability is received from a
neighbor.

Thanks.  -- Enke

-----Original Message-----
From: Idr <[email-masked]> on behalf of Jeffrey Haas <[email-masked]>
Date: Wednesday, July 31, 2019 at 2:16 PM
To: Alvaro Retana <[email-masked]>
Cc: "idr@ietf. org" <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

    

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 31 Jul 2019 20:29:11 -0400

Enke,

> UPDATE message depending on whether the 4-byte AS capability is received from a

I should have known I wasn't pedantic enough in this comment. :-)

The point here is that in order to exercise the procedures between NEW BGP
speakers, (RFC 6793, §4.1), both sides must advertise and use the
capability.  If you have a mix, each speaks 4271 to each other with the new
speaker running the transitional procedures.

With regard to the extended messaging, my preference is that both sides
advertise the capability in order to use the large messages.  A mis-match
falling back to 4271 4k PDUs is fine - symmetrically.  Asymmetrically
sending extended messages leads to a mess of edge cases.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 1 Aug 2019 05:04:37 +0000

I'll raise you one.
A single speaker in a network that is not capable of receiving extended
messages will lead to a mess of (non-edge) cases. 

How about:

A BGP speaker MUST NOT send the extended messages capability in
an OPEN message to any BGP speaker if it has received an OPEN message
without the extended message capability from any
BGP speaker. A BGP speaker MUST delay sending an OPEN message to
any BGP speaker by one keepalive interval if that OPEN message will
contain the extended message capability and it has not yet received
an OPEN message from every configured BGP speaker. The stated OPEN
messages are understood to be of current or future BGP sessions,
not of old sessions that have been taken down.

This will reduce, but not completely eliminate the mess cases.

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Jeffrey Haas
Sent: Wednesday, July 31, 2019 5:29 PM
To: Enke Chen (enkechen) <[email-masked]>
Cc: [email-masked]; idr@ietf. org <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

Enke,

-- Jeff

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Thu, 1 Aug 2019 05:29:41 +0000

Hi, Jeff:

1) It is a new capability, and it will take time for it to be deployed or enabled. A BGP speaker has to deal
with the case that some neighbors have advertised the capability, and some have not. That is already
covered in "Section 4 Operation" of the draft. 

2) In terms of deployment, as this feature is likely to be controlled by config (and likely "off" by default),
requiring both sides to advertise the capability simultaneously would make it difficult for the feature to
be deployed or used.

3) I do not see a reason for this capability to be different from other capabilities that do not require
bi-directional advertisement of the capability.

Thanks.  -- Enke

-----Original Message-----
From: Jeffrey Haas <[email-masked]>
Date: Wednesday, July 31, 2019 at 5:27 PM
To: "Enke Chen (enkechen)" <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, "idr@ietf. org" <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

    Enke,

    

    -- Jeff

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Thu, 1 Aug 2019 05:39:57 +0000

Hi, Jakob:

I am afraid what you just proposed would make the feature non-deployable ☹

1) I suspect that for *a long time* there will some EBGP neighbors that don't have the capability
enabled. Thus the speaker will not be able to send the large messages to any neighbors...

2) Also just imagine when one of the neighbors decide disables the capability ...

Requiring "simultaneous configs" over a session always make it hard for the deployment of a feature,
let alone synchronizing  across many neighbors.

Thanks.  -- Enke  

-----Original Message-----
From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wednesday, July 31, 2019 at 10:04 PM
To: Jeffrey Haas <[email-masked]>, "Enke Chen (enkechen)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "idr@ietf. org" <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
Subject: RE: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

    I'll raise you one.
    
    How about:

    
    Regards,
    Jakob.
    
    -----Original Message-----
    From: Idr <[email-masked]> On Behalf Of Jeffrey Haas
    Sent: Wednesday, July 31, 2019 5:29 PM
    To: Enke Chen (enkechen) <[email-masked]>
    Cc: [email-masked]; idr@ietf. org <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>
    Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
    
    Enke,

    

    -- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 1 Aug 2019 05:45:53 +0000

MCAS made the MAX non-deployable, but at least crashes are avoided.
I prefer stable over deployable.

You could split this by non-interfering address families.
For example, if BGP-LS needs extended messages, but IPv4
does not, then allow extended messages only in the BGP-LS
address family. Interfering address families might be
EVPN and L3VPN, because IP routes can be transferred
between them.

Regards,
Jakob.

-----Original Message-----
From: Enke Chen (enkechen) 
Sent: Wednesday, July 31, 2019 10:40 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: [email-masked]; idr@ietf. org <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>; Enke Chen (enkechen) <[email-masked]>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

Hi, Jakob:

Thanks.  -- Enke  

-----Original Message-----
From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wednesday, July 31, 2019 at 10:04 PM
To: Jeffrey Haas <[email-masked]>, "Enke Chen (enkechen)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "idr@ietf. org" <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>
Subject: RE: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

    I'll raise you one.
    
    How about:

    
    Regards,
    Jakob.
    
    -----Original Message-----
    From: Idr <[email-masked]> On Behalf Of Jeffrey Haas
    Sent: Wednesday, July 31, 2019 5:29 PM
    To: Enke Chen (enkechen) <[email-masked]>
    Cc: [email-masked]; idr@ietf. org <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>
    Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
    
    Enke,

    

    -- Jeff

---

From: Randy Bush <[email-masked]>
Date: Wed, 31 Jul 2019 23:17:52 -0700

> A BGP speaker MUST NOT send the extended messages capability in an
> OPEN message to any BGP speaker if it has received an OPEN message
> without the extended message capability from any BGP speaker.

so, until every router in the bgp internet is extended enabled, no
router may use extended.

i suspect you may not want this consequence.

randy