Re: [Idr] WGLC is for "BGP Router Capabilities Attribute” [was: Re: WG LC for draft-ietf-idr-entropy-09 (8/29 to 9/12/2023)]

[Ketan Talaulikar <[e-mail]>]

Hello All,

I am probably quite late in sending out these comments for the WGLC.
Nevertheless, they are for the v11:

Sec 1:

Although ELCv3 is only relevant to labeled NLRI, ...

Is "labeled NLRI" a well-known/defined term. Does it indicate only those
SAFIs that use RFC8277 based encoding or would it also cover EVPN as an
example? Would it not be better to just say SAFIs that use MPLS forwarding
... or something like that?

Sec 2.1:

The NHC signals potentially useful information, so it is desirable to make
it transitive; the next hop data is to ensure correctness if it traverses
BGP speakers that do not understand the NHC.

I would expect we would never put info that is not useful into BGP ;-) ...
Perhaps what was meant here was that the choice of making it transitive was
to ensure it would get propagated via BGP speakers (like RRs) that do not
change the NH and therefore are not in the forwarding path?

Sec 2.1

The Attribute Data field of the NHC attribute is encoded as a header
portion that identifies the router that created or most recently updated
the attribute, ...

Strictly speaking, what is encoded is a NH and can we say that it
"identifies the router that ..."? Considering anycast scenario described in
sec 2.5?

Sec 2.1

Capability Code: a two-octet unsigned binary integer that indicates the
type of capability advertised and unambiguously identifies an individual
capability.

The use of "binary integer" is somewhat confusing. Is it just a number code
point similar to what the IANA considerations suggest, or is it something
that can be encoded differently as a binary string?

Sec 2.2

Any capability TLVs received by S that are for capabilities not supported
by S will not be included in the version of R constructed by S.

Perhaps it should be "... the version of NHC constructed by S"?

Sec 2.2

An implementation SHOULD send the NHC and its contained capabilities by
default. An implementation SHOULD provide configuration control of whether
any given capability is sent.

It is not clear what is meant by "send" here? Is this referring to
propagation or origination or both? The next sentence is clear in this
respect.

Sec 2.3

An implementation SHOULD accept the NHC and its contained capabilities by
default. An implementation SHOULD provide configuration control of whether
any given capability is accepted.

Could you clarify what exactly is meant by "accept" above? The rest of this
section explains the receiving, validation and use. Is this about a route
policy that discards the attribute on reception or which scrubs out certain
capabilities?

Sec 3.2/3.3

These sections do not discuss the scenario where a router receives the same
route from different peers and some of them are received with ELCv3 but
others are not. Since ELC3 does not affect best path calculation, whether
the router propagates ELCv3 further depends on the ELCv3 on the best path
that it has selected. There is also the scenario where we have multipath
with a mix of capabilities.

Sec 3.4

I believe multiple instances of ELCv3 would not be considered malformed?

Appendix A

The point that EL capability can be derived from configuration is already
covered in sec 3.2. What would be the motivation to cover ELCv2 in this
document? I would suggest removing Appendix A since the ELC attribute (28)
is deprecated and this document asks that it be discarded in sec 4. The
Appendix A seems to contradict that in some form by indicating that
implementations leverage ELC attribute 28.

I hope this helps clarify/improve the document.

Thanks,
Ketan


On Fri, Sep 8, 2023 at 12:05 AM John Scudder <jgs=
[e-mail]> wrote:

> Hi All,
>
> Robert Raszuk pointed out [1] that the draft filename
> (draft-ietf-idr-entropy) doesn’t clearly reflect the title and scope of the
> spec — the title is "BGP Router Capabilities Attribute”, and indeed the
> ELCv3/Entropy Label Capability is only one example of a capability the RCA
> can contain.
>
> As a reminder, we ended up with this filename because the draft is a
> merger of draft-ietf-idr-next-hop-capability and
> draft-ietf-idr-entropy-label, and that was the one we picked to merge down
> to. In retrospect maybe we should have merged down to
> draft-ietf-idr-next-hop-capability instead, or even picked a third, new,
> filename.
>
> I’ve adjusted the subject line to spotlight this fact, because Robert
> expressed concern that WG participants might not realize what the WGLC is
> about, and I promised [2] to follow up.
>
> Thanks,
>
> —John
>
> [1] https://mailarchive.ietf.org/arch/msg/idr/lEabkTb0VjymshotgF8Ej29vVkM/
> [2] https://mailarchive.ietf.org/arch/msg/idr/5XchsuIzrj5Hb4a8Ju2zG7jI_kM/
>
> > On Aug 29, 2023, at 11:53 AM, Susan Hares <[e-mail]> wrote:
> >
> >
> > This begins a 2 week WG LC for draft-ietf-idr-entropy-09.txt (8/29 to
> 9/12).
> > https://datatracker.ietf.org/doc/draft-ietf-idr-entropy-label/
> >
> > Each of the authors should reply to this message with an IPR statement
> indicating
> > whether they know of any IPR relating to this draft beyond that
> disclosed in:
> >
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-idr-entropy-label
> >
> > There is only 1 implementation for this specification, and the
> > Implementation report is at:
> >
> https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-entropy-label
> >
> > If anyone is in the process of implementing this specification  or has an
> > Implementation for this specification, please send a note to the IDR
> chairs ([e-mail])
> > or to me ([e-mail]).
> >
> > A few questions the WG should consider:
> >
> > 1) Do you feel the Router Capabilities Attribute (RCA) is a useful
> general attribute
> > to transitively pass router characteristics between Autonomous Systems
> under
> > the same administrator?
> >
> > 2) feel the Router Capabilities Attribute (RCA) is a useful general
> attribute
> > to transitively pass that a router is capability of handling the entropy
> label?
> >
> > 3) Is the Router Capabilities Attributes (RCA) useful for passing router
> > Capabilities between Autonomous Systems under different
> > Administrators?
> >
> > 4) Is this specification ready for publication?
> >
> > 5) Is the entropy label function operationally useful in networks?
> >
> > Cheers, Sue
> >
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>