Subject: [Idr] [Re: Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-31.txt

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Tue, 2 Jul 2019 00:00:03 +0000

Hi,. Folks:

Apologies for being late in the review cycle of this document.  But I have a basic question about
the BGP capability defined in Sect 3:

--
   By advertising the BGP Extended Message Capability to a peer, a BGP
   speaker conveys that it is able to send, receive, and properly
   handle, see Section 4, BGP Extended Messages.
--

The text “… to send” does not seem to be necessary, and the spec would be simpler and
cleaner without it.

IMO the capability should be about “receiving” only. As long as a BGP speaker is able and willing
to receive large messages (by advertising the capability),  its neighbor would be allowed  to send
such messages to the speaker. It really does not matter whether the speaker is able / willing / need
to send any large messages to its neighbors.  (Of course certain “Operational” considerations still
apply, especially for IBGP, as discussed in the document.)

What do folks think?

Thanks.  – Enke

---

From: Randy Bush <[email-masked]>
Date: Mon, 01 Jul 2019 18:04:57 -0700

> Apologies for being late in the review cycle of this document.  But I
> have a basic question about the BGP capability defined in Sect 3:
> 
> --
> The text “… to send” does not seem to be necessary, and the spec would
> be simpler and cleaner without it.
> 
> IMO the capability should be about “receiving” only. As long as a BGP
> speaker is able and willing to receive large messages (by advertising
> the capability), its neighbor would be allowed to send such messages
> to the speaker. It really does not matter whether the speaker is able
> / willing / need to send any large messages to its neighbors.  (Of
> course certain “Operational” considerations still apply, especially
> for IBGP, as discussed in the document.)
> 
> What do folks think?

we weny around this at least twice during the wg process.  there was a
dislike of the possibility of extended messages being unidirectional,
error reporting, etc.

but i have no dog in this fight

randy

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 1 Jul 2019 22:00:26 -0400

(from enke)
> > / willing / need to send any large messages to its

is it a good idea to assume that you can send just because you can receive?
assuming seems a little dicey.

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Tue, 2 Jul 2019 03:34:37 +0000

No, there is no such assumption.  Perhaps let me rephrase for 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.

Regards,  -- Enke

On 7/1/19, 7:01 PM, "Christopher Morrow" <[email-masked]> wrote:

    (from enke)

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Tue, 2 Jul 2019 03:39:09 +0000

Hi, Randy:

Were there any specific issues for the capability to be unidirectional?   It's not
clear to me how requiring the capability to be bidirectional would help.

Thanks.  -- Enke

    

    randy

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 1 Jul 2019 20:41:57 -0700

+1 to Enke's opinion from what has been done on other options, don't make
spec tighter than needed unless a specific issue that mandates
bi-directionality can be presented.

--- tony

On Mon, Jul 1, 2019 at 8:35 PM Enke Chen (enkechen) <[email-masked]>
wrote:

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

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 2 Jul 2019 00:59:52 -0400

> No, there is no such assumption.  Perhaps let me rephrase for clarify:

ah! ok, I misread your intent I think :(

> send any large messages to its neighbors.

ok, makes sense to me. I believe I read it from the other direction:
"happy to send <nothing said about recieving>"
oops :)

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 2 Jul 2019 09:34:31 -0400

On July 1, 2019 at 11:39:39 PM, Enke Chen (enkechen) ([email-masked])
wrote:

Enke:

Hi!

Were there any specific issues for the capability to be unidirectional?
It's not
clear to me how requiring the capability to be bidirectional would help.

rfc5492 says this: "Simply put, a given capability can be used on a peering
if that capability has been advertised by both peers.  If either peer has
not advertised it, the capability cannot be used.”

IOW, it is not so much that the meaning can’t be something else…but that
this is how it was designed.

Alvaro.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Jul 2019 15:48:12 +0200

Alvaro,

> rfc5492 says this: "Simply put, a given capability can be used on a
peering if that capability has
> been advertised by both peers.  If either peer has not advertised it, the
capability cannot be used.”

I don't think this is the point here.

The issue is this:

Current version of the draft defines one simple capability to indicate
support for both sending and receiving.

Enke brings a valid point that there can be implementations and various use
cases where support for both may be too heavy and that we rather do more
atomic signalling in the protocol just like it has been done for example in
ORF Capability [Ref: RFC5291 Section 5]. Now WG can argue that point.

Cheers,
Robert.

On Tue, Jul 2, 2019 at 3:34 PM Alvaro Retana <[email-masked]> wrote:

> rfc5492 says this: "Simply put, a given capability can be used on a
> peering if that capability has been advertised by both peers.  If either
> peer has not advertised it, the capability cannot be used.”
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Jul 2019 07:41:08 -0700

robert,

>> peering if that capability has been advertised by both peers.  If
>> either peer has not advertised it, the capability cannot be used.”
> 

if they bost must be capable, then both must be able to send and
receive.

you seem to want two capabilities, sending and receiving.

but if they negotiate the sending capability, then both are senders.  in
which case, both must be receivers.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Jul 2019 16:51:55 +0200

> you seem to want two capabilities, sending and receiving.

I was trying to make sure all parties are on the same page here :)

Nope - technically you still negotiate single capability: Extended Msg -
but with TLVs indicating the more granular supported direction.

> which case, both must be receivers.

There are not such a thing as "sending capability" ... The capability is
still Ext Msg.

- - -

Anyhow I am not sure I would put that "I want it". I see pros and cons of
both options and very honestly I more biased to leave the current
send/receive combined one for this very extension.

Thx,
R.

---

From: "Enke Chen (enkechen)" <[email-masked]>
Date: Tue, 2 Jul 2019 17:23:54 +0000

Hi, Alvaro:

It seems to me that these are two separate issues, the capability itself,
and the requirement for capability advertisement by both sides. The topic
I brought up initially is the former.

Regarding the text your cited from RFC 5492, that is about the latter,
and that is a change from the original capability spec, and I am not sure
why the change was made. Looking at the first usage (multi-protocol), it
explicitly talks about the “bi-directional”.

Even given the text in RFC 5492, I do not see any reason for including
the “send” portion in the capability definition for large messages.

Thanks.  -- Enke

RFC 5492:

   A BGP speaker that supports a particular capability may use this
   capability with its peer after the speaker determines (as described
   above) that the peer supports this capability.  Simply put, a given
   capability can be used on a peering if that capability has been
   advertised by both peers.  If either peer has not advertised it, the
   capability cannot be used.

RFC 3392:

   A BGP speaker that supports a particular capability may use this

   capability with its peer after the speaker determines (as described

   above) that the peer supports this capability.

RFC 4760 Multiprotocol Extension 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>

   route.

From: Alvaro Retana <[email-masked]>
Date: Tuesday, July 2, 2019 at 7:10 AM
To: "Enke Chen (enkechen)" <[email-masked]>, Randy Bush <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Idr] [Re: Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-31.txt

On July 1, 2019 at 11:39:39 PM, Enke Chen (enkechen) ([email-masked]<mailto:[email-masked]>) wrote:

Enke:

Hi!

rfc5492 says this: "Simply put, a given capability can be used on a peering if that capability has been advertised by both peers.  If either peer has not advertised it, the capability cannot be used.”

IOW, it is not so much that the meaning can’t be something else…but that this is how it was designed.

Alvaro.