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

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 <aretana.ietf@gmail.com> wrote:

> On July 1, 2019 at 11:39:39 PM, Enke Chen (enkechen) (enkechen@cisco.com)
> 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.
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>