[Idr] Mohamed Boucadair's Discuss on draft-ietf-idr-link-bandwidth-19: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-idr-link-bandwidth-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Pradosh, Reshma, Satya, Serge, Rafal, and Akshay,

Thank you for the effort put on this specification. Appreciate in particular
the perseverance to push for this spec for 16 years.

Thanks to Jeff for the excellent shepherd write-up and the link to relevant
work in BESS.

Also, thanks to Tim Chown for the OPSDIR review and the authors for engaging.

I support this effort and will definitely ballot “YES”. Till then, I have some
few points to discuss:

# Start with an easy to fix one :-)

OLD:
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

NEW:
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

# 32-bit and 16-bit ASNs

CURRENT:
The value of the Global Administrator subfield in the Value
   Field SHOULD represent the Autonomous System of the router that
   attaches the Link Bandwidth Extended Community, but it can be set to
   any 2-byte value.  If the Autonomous System number cannot be
   represented in two octets, AS_TRANS [RFC6793], SHOULD be used in the
   Global Administrator subfield.  The encoding of 4-octet ASN is out of
   scope of this document.

## The last sentence seems to contradict the SHOULD in the sentence right
before.

## If we only consider 16-bit ASNs, then I don’t see when the second SHOULD
apply.

## The value actually used in Global Administrator does not actually matter
after all, but I understand that this is to be consistent with registering the
community in the two 2-octet community registries.

I think some rearrangement of this text for better clarity is needed.

## I’m not asking to define a 4-octet ASN extended community as I trust this
was considered by the WG and that there is a reason for only registering 16-bit
ASN extended communities. Maybe add a motivation to justify the design (other
than this was inherited from early version since 2009 :-)).

# Link Value: Static or Dynamic one

CURRENT:
    Local Administrator sub-field:
             Bandwidth value (bytes per sec) encoded as 4 octets
             in IEEE floating point format.

The description needs to be clarified whether the advertised BW is static value
or about available BW. If this is not a static value, the there is evidently
some impact to consider on the stability and need for guards to prevent
injecting too dynamic values.

May consider updating the Operational Considerations Section with such
clarification (including, guidance to avoid changing too frequently the value).
That section may also say that how bw is computed/determined is out of scope.

# External Peers

Given the commercial relationships and use of the community to reveal some
capacity, I guess that as Operational Consideration, the text may say that
absent an explicit allow policy, the community has to be stripped when
advertised to an external peer.

The security section includes a mention, but I think a strong behavior is
needed.

# Associate a meaning with Zero value

CURRENT:
   An implementation MAY advertise bandwidth value as zero.

The spec does not specify how zero value is interpreted. Should that mean that
it should be unusable, deprioritized, else?

# Unconditional MUST

CURRENT:
   A BGP receiver MUST be able to process Link Bandwidth Extended
   Community of both transitive and non-transitive types.

This MUST should be scoped. For example, a speaker that does not support the
attribute won’t process it. Likewise, a policy may be provided to discard the
link information from some peers, etc.

# Intended Use

CURRENT:
   A BGP update with an attached Link Bandwidth Extended Community with
   a bandwidth value of zero is valid.  When all contributing paths have
   a non-zero value in the Link Bandwidth Extended Community, the
   bandwidth values of those paths (or their ratio) can be utilized as
   weights to enable weighted load-balancing.

Should this be specifically restricted to WLB, not cover other cases that
impact route selection process?

# Conflict?

CURRENT:
it MAY do any one of the following as its default behavior
   -remove the Link Bandwidth Extended Community, re-advertise it
   unchanged, or regenerate it with an appropriate value.

How to reconcile this with the SHOULD part in Section 3.3.2?

BTW: s/appropriate value/updated value


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Retrieve default values

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

and

   Implementations SHOULD provide a local configuration method to alter
   their default behavior to the other options with per-session
   granularity.

For the sake of deterministic behavior and ease network management, there is a
need to retrieve the default used by each impl. This will feed controllers and
so on.

I suggest to add the following for in the both places above:

NEW:
  Likewise, Implementation SHOULD expose their default value.

# Inadequate use of normative language: these are examples

OLD:
For
   example, implementations MAY exclude the paths with zero value from
   weighted load balancing formation as long as at least one path with
   non-zero value exists or they MAY fallback to ECMP.

NEW:
For
   example, implementations may exclude the paths with zero value from
   weighted load balancing formation as long as at least one path with
   non-zero value exists or they may fallback to ECMP.

Cheers,
Med