[Idr] AD evaluation review of draft-ietf-idr-link-bandwidth-15

[Ketan Talaulikar <[e-mail]>]

Hello Authors (and WG),

Thanks for your work on picking up this long pending document and the
collaborations in getting it across the WG finish line.

Please find below my AD evaluation review with comments and suggestions
inline in the idnits output of v15 of the document. Please look for the tag
< EoRv15 > at the bottom of the email. If you don't find that, likely the
email has been truncated by your email client and you should refer to the
IDR mailing list archive for the full review email.

The review has been done with a "fresh eyes" view of the current document
towards RFC publication and the suggestions are to improve the readability.

Thanks,
Ketan

< general/major > I would like to strongly recommend to the authors and the
WG
to include some text that explains what is meant by "link" in this
document.
Ideally, the EC could have been just called Bandwidth Extended Community"
or
even "Path Bandwidth Extended Community" where the "path" can be described
in
BGP terms (i.e., towards a BGP nexthop). However, I realize that it may be
too late for such a change and so, just clarifying what "link" means will
 be sufficient (something like - The term link in this document ...).

< related editorial > Please look for "link bandwidth" (in other than the
name of the community) and see if it can be simply replaced by "bandwidth"
without affecting the meaning of the text. In some other places, it
probably
needs to be replaced with the community name.

19 Abstract

21   This document describes an application of BGP extended communities
22   that allows a router to perform WECMP (Weighted Equal-Cost
23   Multipath).

<major> The document is actually specifying a new BGP extended community.

SUGGEST:
This document specifies a BGP Extended Community that enables routers to
perform
weighted equal-cost multipath (WECMP).

89   network performance.  Traditional equal-cost multi-path (ECMP)
90   routing does not account for the varying capacities of different
91   paths.  This document suggests that the external link bandwidth be

<minor> Can you please clarify the meaning of "external link" here? Is it
not
OK to just delete the word "external" ?

93   [RFC4360] - the transitive and non-transitive Link Bandwidth Extended
94   Community.  The Link Bandwidth Extended Community provides a

<minor> Please consider abbreviating Link Bandwidth Extended Community for
ease of reading and then it can be used consistently through the rest of the
document.

95   mechanism for routers to advertise the bandwidth of their downstream
96   path(s), facilitating maximum utilization of network resources.

< minor > perhaps s/maximum/optimal ?

98 2.  Link Bandwidth Extended Community

100   The Link Bandwidth Extended Community is defined as a BGP extended
101   community that carries the bandwidth information of a router,
102   represented by BGP Protocol Next Hop, connecting to remote network.

< major > What is the difference between 'BGP Protocol Next Hop' and 'BGP
Next
Hop'? Is the former term defined in an RFC?

103   This community can be used to inform other routers about the
104   available bandwidth through a given route.

< minor > given route or given router?

113   any 2-byte value.  If the Autonomous System number cannot be
114   represented in two octets, as enabled by [RFC6793], AS_TRANS should
115   be used in the Global Administrator subfield.  The encoding of

<minor> To improve readability

SUGGEST:
If the Autonomous System number cannot be represented in two octets,
AS_TRANS
[RFC6793] SHOULD be used in the Global Administrator subfield.


144 3.  Protocol Procedures

<major> Please consider adding the suggested text here at the beginning to
avoid repetition in the procedures in this section. The key point is that
the
document is trying to safeguard existing deployments that use different
implementations that use different transitivity types. This is more about
those deployments.

SUGGEST (new text to insert):
The procedures cover both the transitive and non-transitive variants of the
Link Bandwidth Extended Community and for implementations to handle both
variants in a way that supports existing deployments. Please refer to
sections
5 and 8 for more details.

146 3.1.  Sender (Originating Link Bandwidth Extended Community)

< major >The term "originate" can be confusing. Is the the router that
originally introduced the LBW when it originated the route, or is it simply
 the router that includes LBW with the route that it advertises? Does
replacing "originate" with "advertise" (or something like that) work?
Similarly, does replacing "originator" with "sender" work?
In other words are the procedures here only for the "originator" and not
any "sender"? What complicates things is there is also a separate section
3.3
about re-advertisement. Can the contents of section 3.3 be moved into
section
3.1 where it just becomes about "sender" and the subtleties about NHS/NHU
can
also be described herein?


148   An originator of Link Bandwidth Extended Community SHOULD be able to
149   originate either a transitive or a non-transitive Link Bandwidth
150   Extended Community.  Implementations SHOULD provide configuration to

<minor> To improve readability

SUGGEST:
A router advertising Link Bandwidth Extended Community SHOULD be able to
send
either a transitive or a non-transitive or both types of Link Bandwidth
Extended
 Community.

151   set the transitivity type of the Link Bandwidth Extended Community,
152   as well as the Global Administrator and bandwidth values in (Local
153   Administrator field), using local policy.  For backward
154   compatibility, different implementations MAY use different default
155   values for the transitivity type of the Link Bandwidth Extended

<minor> How about all the backward compatibility and the operations related
to
the two types be focused in section 8 to make it easier for the reader?

SUGGEST-1:
Different implementations MAY use different default values for the
transitivity
type of the Link Bandwidth Extended Community.

OR (if you are not adding the text at the start of section 3, then)

SUGGEST-2:
Different implementations MAY use different default values for the
transitivity
type of the Link Bandwidth Extended Community (see section 8 for details).


156   Community.  The provided configuration SHOULD allow operators to
157   override the default transitivity value as needed.  An implementation
158   MAY advertise a link bandwidth value as zero.

< major > Can the last sentence be moved from this section to Error
Handling as
follows? It is a bit stronger even if the end result is the same.

SUGGEST (for error handling section):
The link bandwidth value of 0 MUST NOT be considered as malformed.

160   No more than one Link Bandwidth Extended Community SHOULD be attached
161   to a route.  For purpose of backward compatibility during transition,

<major> What happens if two LBW of the same type get attached? This is
already
covered in the error handling. So, perhaps the intent of this text is better
captured as:

CURRENT:
No more than one Link Bandwidth Extended Community SHOULD be attached to a
route.
For purpose of backward compatibility during transition, a BGP speaker MAY
attach
one Link Bandwidth Extended Community per transitivity
(transitive/non-transitive)
 both having the same 'Link Bandwidth Value' field.

SUGGEST:
Generally, a single Link Bandwidth Extended Community of the transitivity
type
that is desired in a deployment is attached to a route. However during
transition
(refer section 8 for details), a BGP speaker MAY attach one Link Bandwidth
Extended
Community per transitivity (transitive/non-transitive) both having the same
'Link Bandwidth Value' field.


172   Note: Implementations MAY provide a configuration option to send non-
173   transitive Link Bandwidth Extended Communities on external BGP
174   sessions.

< major > Please remove the "Note:" since this is text with normative
language
and not a "note". There is a similar instance in section 3.2 as well.


188   Implementations MUST be able to process and accept a Link Bandwidth
189   Extended Community where the bandwidth value is set to zero.  WECMP
190   can be utilized when all contributing paths have a non-zero value in
191   the Link Bandwidth Extended Community.

193   In case some paths have a zero value but others have non-zero value,
194   or all paths have Link Bandwidth with zero value, the behavior is
195   determined by local policy.  For example, an implementation may
196   exclude the paths with zero value from WECMP formation or an
197   implementation may fallback to ECMP.

< minor > Please see this suggestion in conjunction with the comment in
section 3.1

CURRENT:
Implementations MUST be able to process and accept a Link Bandwidth
Extended
Community where the bandwidth value is set to zero. WECMP can be utilized
when
all contributing paths have a non-zero value in the Link Bandwidth Extended
Community.

In case some paths have a zero value but others have non-zero value, or all
paths have Link Bandwidth with zero value, the behavior is determined by
local policy. For example, an implementation may exclude the paths with
zero
value from WECMP formation or an implementation may fallback to ECMP.

SUGGEST:
Zero is a valid bandwidth value to be set in the Link Bandwidth Extended
Community. WECMP can be utilized when all contributing paths have a non-zero
value in the Link Bandwidth Extended Community. However, in the case where
the
paths have a mix of zero and non-zero values, or all zero values, the
behavior
is determined by local policy. For example, implementations MAY exclude the
paths with zero value from WECMP formation as long as at least one path with
non-zero value exists or they MAY fallback to ECMP.


207   In the absence of any import or export policies that alter the Link
208   Bandwidth Extended Community, any received Link Bandwidth Extended
209   Community on the route will be re-advertised unchanged, in accordance
210   with standard BGP procedures.

< major > Should the text not just say "route policies" as opposed to being
explicit about import/export? Furthermore there should be a pointer to
section
3.4 as well?

SUGGEST:
In the absence of any route policies that alter the Link Bandwidth Extended
Community, any received Link Bandwidth Extended Community on the route will
be re-advertised unchanged. Please also refer to section 3.4 for use in a
BGP
multipath environment.


212 3.3.2.  Re-advertisement with Next Hop Unchanged

214   A BGP speaker that receives a route with a Link Bandwidth Extended
215   Community, re-advertises or reflects the same without changing its
216   next hop, SHOULD NOT change the Link Bandwidth Extended Community in
217   any way.

< minor > For better readability

SUGGEST:
A BGP speaker that receives a route with a Link Bandwidth Extended Community
and re-advertises or reflects the same without changing its next hop,
SHOULD NOT
change the Link Bandwidth Extended Community in any way.

219 3.4.  Link Bandwidth Extended Community Arithmetic and BGP Multipath

221   In a BGP multipath ECMP environment, the link bandwidth value that is
222   sent or re-advertised may be calculated based on the Link Bandwidth
223   Extended Community of the routes contributing to multipath in the
224   Local Routing Information Base (Local-RIB).  This topic is beyond the
225   scope of this document.

< major > This text does not cover the cumulative LBW scenario which is
one of the key use-cases. Should this text at least not allude to the
cumulative LBW usage (ideally with an informative reference to the use-case
document currently in BESS WG) even if the details are outside the scope of
this document? Another thing to look at it is that the abstract talks about
"weighted"
ECMP but there is no description of even how those weights are determined.
So,
we need some more text to cover that aspect as well.


246   Link Bandwidth Extended Communities with a negative value SHALL be
247   ignored and MUST NOT be originated.

< major > s/MUST NOT be orignated./MUST NOT be advertised.


252 5.  Document History

< major > While this section is very valuable, I don't think it belongs in
the
body of the document when it becomes an RFC. Please move it into the
Appendix
section.

254   BGP Link Bandwidth Extended Community has evolved over several
255   versions of the IETF draft.  In the earlier versions up to draft-
256   ietf-idr-link-bandwidth-08, only the non-transitive version of Link
257   Bandwidth Extended Community was supported.  However, starting from
258   draft-ietf-idr-link-bandwidth-09, both transitive and non-transitive
259   versions of Link Bandwidth Extended Community are supported.

261   An old sender/receiver is a BGP speaker that uses procedures up to
262   draft (https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-
263   bandwidth-08) or any undocumented behavior for Link Bandwidth
264   Extended Community.

266   A new sender/receiver is a BGP speaker that implements procedures
267   specified in this document.

<major> The term "older" is used only in section 8.1 and there it can be
simply replaced by "an implementation that understands only one transitivity
type". There is no use of "newer". So, while the first and the last (fourth)
paragraph of this section is important, the second and third don't seem
necessary to me.

269   A BGP speaker (Sender or Receiver) needs to be upgraded to support
270   the procedures defined in this document to provide full
271   interoperability for both transitive and non-transitive versions of
272   Link Bandwidth Extended Community.  In order to simplify
273   implementations, it is not a goal to provide interoperability by
274   upgrading only the RR.


276 6.  IANA Considerations

278   This document defines a specific application of the two-octet AS
279   specific extended community.

<major> The above sentence does not belong to the IANA consideration
section and should be removed.


293       Name
294       ----
295       non-transitive Link Bandwidth Extended Community

297   Both updates are to Reference this document.

<nit> s/Reference/reference

299 7.  Security Considerations

301   There are no additional security risks introduced by this design.

<major> I think this section needs to discuss the aspect that the LBW
conveys
the bandwidth available (e.g., in the cumulative use case) and this
information going out say over the Internet can result in disclosure of
bandwidth and capacity that is private to a network. Doesn't there need to
be
a discussion about the use of LBW being within single provider network or
between trusted parties - i.e., not over the Internet - with a short mention
of filtering of this community?

314   In circumstances where networks have deployed a mixture of
315   implementations supporting this document's current procedures for

< nit > s/current procedure/procedure

318   A primary example is when a route received by a BGP speaker contains

< nit > s/primary/prime ?

322   community may be have an inconsistent value.  As a result, downstream
323   BGP speakers that may receive such routes may perform inappropriate
324   ECMP load balancing.

<minor> s/may be have/may have .... and also ... s/ECMP/WECMP

328   take actions to address such inconsistencies.  One example would be

<minor> s/example/option ?

336   Ideally this operational consideration is short-lived until the
337   network has been upgraded to implementations that consistently
338   support the procedures in this draft.

<minor> To better capture the intent?

SUGGEST:
Ideally this operational consideration is short-lived until the routers in
the
network have been upgraded to (versions of) implementations that support
the
procedures in this document.

< EoRv15 >