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

From: <[email-masked]>
Date: Thu, 1 Aug 2019 07:35:38 +0000

From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: Wednesday, July 31, 2019 10:06 PM
To: idr@ietf. org
Cc: [email-masked]; [email-masked]; Susan Hares
Subject: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

On July 31, 2019 at 1:31:11 PM, Susan Hares ([email-masked]<mailto:[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.

[Bruno]
In general, I support this asymmetric behavior with capability advertisement  as it brings flexibility and reflects what looks to be the natural meaning: Sending capability A, means I support A. It should mean that my neighbor can use A with me.

However, I’m less in favor of such asymmetry for bgp-extended-messages as in general, for consistent routing, we would likely want the opposite asymmetry: everyone willing to accept receiving extended messages, before someone sends one. So I’d rather say that if you want to send extended-messages, you need to send the capability to be ready to also receive extended messages. Although this brings additional constraints (and nobody like constraints), I don’t really see a case where an BGP speaker could send an extended message and could not implemented the receiving side. While I can see that some implementers may be tempted to support the minimal for their use case and be happy to send large messages but not ready to do the work on the receiving side.

That been said, I can live with both options. We can leave this to operators to only configure the feature when both speakers support it. (Note that if your concerned with deployment speed of this feature, I’m not sure that in general this will be the speediest path)

--Bruno

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

_________________________________________________________________________________________________________________________

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: Thu, 01 Aug 2019 07:00:12 -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.

even more fun

the internet is only four routers, A - B - C - D
they are all happily speaking extended
router E joins after D
E does not speak extended

how does the signal to not speak extended propagate
E - D - C - B - A?

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 1 Aug 2019 11:52:54 -0400

I know I am late with this suggestion - but why not do this in backwards
compatible fashion moving the solution up the stack ?

Instead of extending the message itself - why not to issue a simple draft
to enable sending BGP UPDATE exceeding 4K into multiple UPDATE messages ?

On Thu, Aug 1, 2019 at 10:00 AM Randy Bush <[email-masked]> wrote:

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

---

From: Keyur Patel <[email-masked]>
Date: Thu, 1 Aug 2019 18:36:44 +0000

I don’t think this level is strictness is needed. A bgp speaker is capable of sending messages only to those speakers with whom it has exchanged capabilities. 

On 7/31/19, 10:04 PM, "Jakob Heitz (jheitz)" <[email-masked]> wrote:

    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,
    
    On Wed, Jul 31, 2019 at 09:50:08PM +0000, Enke Chen (enkechen) wrote:
    > >>  Note that RFC 6793 (4-byte ASes) require bi-directional advertisement

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 1 Aug 2019 17:05:19 -0400

Enke,

On Thu, Aug 01, 2019 at 05:29:41AM +0000, Enke Chen (enkechen) wrote:
> 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. 

I've made no argument against this.

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

Then the normative text needs to be adjusted for notifications and future
messages.  A minor thing, but roughly: If you say you're willing to receive
extended messages, but protocol demands you respond (i.e. notification) with
information that may overflow 4k, you truncate or silently die.

(c.f. RFC 4271, §6.3, "Data field)

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

I don't have Jakob's general issue.  I do think it simplifies a lot of cases
in code if a given pair of speakers symmetrically have the same limits.  So,
this is primarily a preference for cleaner code.

I am personally fine living with this being asymmetric (delete the
additional sentence in Alvaro's message), but would suggest the comment
above is handled.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 7 Aug 2019 11:12:02 -0400

Enke:

I apologize for the delay in responding to you, but  I am confused by your response.   
Are you also stating that this portion of the text is incorrect. 

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

Thank you for your review of this important addition. 

Cheerily, Sue

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

Hi, Jeff:

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

    On Wed, Jul 31, 2019 at 01:06:04PM -0700, Alvaro Retana wrote:
    > 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. 
    
    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: Alvaro Retana <[email-masked]>
Date: Fri, 9 Aug 2019 06:27:51 -0700

Hi!

Thank you for everyone’s opinion and discussion!

The current text in -35 says this:

>From the thread, the consensus is to keep the asymmetric capability
advertisement.  As written, operators have the flexibility to advertise (or
not) the capability to meet their local policy.

Jeff brought up the point that rfc4271 (§6.3 / UPDATE Message Error
Handling) says that, for some errors, the NOTIFICATION "Data field MUST
contain the attribute (type, length, and value)."  The problem is that if
an Extended UPDATE (> 4k) with an erroneous attribute is received from a
speaker that hasn't advertised the Capability (which is ok because of the
asymmetry), then that peer may not be able to handle an Extended
NOTIFICATION (> 4k).

NEW (to be inserted as the 3rd paragraph in §5 (Error Handling))>
   The UPDATE Message Error Handling, as specified in Section 6.3 of
[RFC4271],
   is not changed.  However, if a NOTIFICATION is to be sent to a BGP
speaker
   that hasn't advertised the BGP Extended Message Capability, the maximum
size
   of the message MUST NOT exceed 4096 octets.

Authors: If no word-smithing suggestions are received in the next couple of
days, please submit a revised draft by the middle of next week.

Thanks!

Alvaro.

On July 31, 2019 at 4:06:04 PM, Alvaro Retana ([email-masked])
wrote:

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

   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):

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

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.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Aug 2019 12:23:04 -0400

Hi Alvaro,

So imagine that BGP Operational Message draft get's standardized and one
TLV will ask to replay back the received message to the sender.

Example: 3.4.3.3
<https://tools.ietf.org/html/draft-ietf-idr-operational-message-00#section-3.4.3.3>.
Malformed Update Dump (MUD)

How is this going to work in this case when I receive over 4K PDU and can
not mirror it back to sender per his request ?

Aren't we getting ourselves into the trap here and "Oooops" condition by
allowing this asymmetry ?

Thx,
R.

On Fri, Aug 9, 2019 at 9:28 AM Alvaro Retana <[email-masked]> wrote:

> Authors: If no word-smithing suggestions are received in the next couple
> of days, please submit a revised draft by the middle of next week.
>
> Thanks!
>
> Alvaro.
>
> 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

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Fri, 9 Aug 2019 16:31:20 +0000

Hi, Robert:

If “A” sends a large message to “B”, and requests “B” to play back. Then “A” has to advertise the
Large Message capability.   Is that not intuitive or logical?

Thanks.  -- Enke

From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Friday, August 9, 2019 at 9:24 AM
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

Hi Alvaro,

So imagine that BGP Operational Message draft get's standardized and one TLV will ask to replay back the received message to the sender.

Example: 3.4.3.3<https://tools.ietf.org/html/draft-ietf-idr-operational-message-00#section-3.4.3.3>. Malformed Update Dump (MUD)

How is this going to work in this case when I receive over 4K PDU and can not mirror it back to sender per his request ?

Aren't we getting ourselves into the trap here and "Oooops" condition by allowing this asymmetry ?

Thx,
R.

On Fri, Aug 9, 2019 at 9:28 AM Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:
Hi!

From the thread, the consensus is to keep the asymmetric capability advertisement.  As written, operators have the flexibility to advertise (or not) the capability to meet their local policy.

Jeff brought up the point that rfc4271 (§6.3 / UPDATE Message Error Handling) says that, for some errors, the NOTIFICATION "Data field MUST contain the attribute (type, length, and value)."  The problem is that if an Extended UPDATE (> 4k) with an erroneous attribute is received from a speaker that hasn't advertised the Capability (which is ok because of the asymmetry), then that peer may not be able to handle an Extended NOTIFICATION (> 4k).

NEW (to be inserted as the 3rd paragraph in §5 (Error Handling))>
   The UPDATE Message Error Handling, as specified in Section 6.3 of [RFC4271],
   is not changed.  However, if a NOTIFICATION is to be sent to a BGP speaker
   that hasn't advertised the BGP Extended Message Capability, the maximum size
   of the message MUST NOT exceed 4096 octets.

Authors: If no word-smithing suggestions are received in the next couple of days, please submit a revised draft by the middle of next week.

Thanks!

Alvaro.

On July 31, 2019 at 4:06:04 PM, Alvaro Retana ([email-masked]<mailto:[email-masked]>) wrote:
On July 31, 2019 at 1:31:11 PM, Susan Hares ([email-masked]<mailto:[email-masked]>) wrote:

Dear WG:

Thanks!

Alvaro.

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

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Fri, 9 Aug 2019 17:20:54 +0000

BTW, such a case can be handled similarly like in RFC 2858 for
the Multiprotocol Capability, which was the first BGP capability:

   RFC 2858 Multiprotocol Extensions for BGP-4

   To have a bi-directional exchange of routing information for a
   particular <AFI, SAFI> between a pair of BGP speakers, each such
   speaker must advertise to the other (via the Capability Advertisement
   mechanism) the capability to support that particular <AFI, SAFI>
   routes.

Thanks.   -- Enke

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Friday, August 9, 2019 at 9:31 AM
To: Robert Raszuk <[email-masked]>, Alvaro Retana <[email-masked]>
Cc: "idr@ietf. org" <[email-masked]>, "[email-masked]" <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>, "Enke Chen (enkechen)" <[email-masked]>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

Hi, Robert:

Thanks.  -- Enke

Hi Alvaro,

Thx,
R.

Thanks!

Alvaro.

Dear WG:

Thanks!

Alvaro.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Aug 2019 13:26:10 -0400

Hi Enke,

if you insist on keeping this asymmetric the only possible solution in the
example I provided would be to have BGP Operational Message by definition
be of 65K and never even require capability exchange for that SAFI.

So if the draft in question makes capability optional I think we are good
to go.

Thx,
R,

On Fri, Aug 9, 2019 at 12:31 PM Enke Chen (enkechen) <[email-masked]>
wrote:

> *From: *Idr <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Friday, August 9, 2019 at 9:24 AM
> *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
>
>
>
> Hi Alvaro,
>
>
>
> Example: *3.4.3.3*
> <https://tools.ietf.org/html/draft-ietf-idr-operational-message-00#section-3.4.3.3>*.
> Malformed Update Dump (MUD)*
>
>
>