[Idr] Rtgdir early review of draft-ietf-idr-entropy-label-06

[Gyan Mishra via Datatracker <[e-mail]>]

Reviewer: Gyan Mishra
Review result: Has Issues

The draft has few issues that should be addressed.
The authors did an excellent job combining ELCv3 with NHC.

Draft overview & history and issues solved by this draft:
ELCv1 RFC 6790 - ELC  optional transitive path attribute 28 that unfortunately
gets propagated by transit nodes not supporting per RFC 4271 and not remove as
desired.

RFC 7447 deprecated the RFC 6790 code point - optional transitive attribute

ELCv2 Juniper implementation copies next hop into data field of the path
attribute for signaling check, uses the original RFC 6790 code point deprecated
by RFC 7447.

ELCv3 rev 00 is identical to ELCv2 Juniper implementation optional transitive
path attribute, but now with a new code point IANA allocation and thus is
required per RFC 8216 must be Standards track.

NHC draft - Generic next hop capability which can be used for the EL signaling-
non transitive BGP attribute.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-next-hop-capability-08

ELCv3 rev 01 – ELCv3 + NHC – Generic next hop capability to support other use
cases

Juniper customers running ELCv2 with deprecated code point from RFC 7447 need a
resolution so the goal of IDR is to get a draft.  Juniper has an attribute 28
discard knob to strip attribute 28.

An issue was reported recently with attribute 28 ELC caused session reset on
versions of Juniper code due to incorrectly flagging the packets as corrupt.

https://labs.ripe.net/author/emileaben/unknown-attribute-28-a-source-of-entropy-in-interdomain-routing/

ELCv3 Rev 2   no change
ELCv3 Rev 3  Section 3.1 added Readable label depth
ELCv3 Rev 4  Security consideration next hop capability filtering in/out &
trust relationship ELCv3 Rev 5  IANA codepoint 0 Reserved, By default RCA must
not be accepted ELCv3 Rev 6 BY default RCA must be accepted

There are no implementations of ELCv3 or NHC.

Major issues:
None

Minor issues:
Updates & Recommendations to RFC 2119 Normative language

2nd to last paragraph of Introduction

Old

An RCA carried in a given BGP UPDATE message conveys information that relates
to all NLRI advertised in that particular UPDATE, and only to those NLRI. A
different UPDATE message originated by the same source might not include an
RCA, and if so, NLRI carried in that UPDATE would not be affected by the RCA.
By implication, if a router wishes to use RCA to describe all NLRI it
originates, it needs to include an RCA with each UPDATE it sends. In this
respect, despite its similar naming, the RCA is unlike RFC 5492 BGP
Capabilities.

New

An RCA carried in a given BGP UPDATE message MAY convey information that
relates to all NLRI advertised in that particular UPDATE, and only to those
NLRI. A different UPDATE message originated by the same source might not
include an RCA, and if so, NLRI carried in that UPDATE would not be affected by
the RCA. By implication, if a router wishes to use RCA to describe all NLRI it
originates, it MUST include an RCA with each UPDATE it sends. In this respect,
despite its similar naming, the RCA is unlike RFC 5492 BGP Capabilities.

Section 2.1 – I think it would be good to more clearly correlate the “address
given in the header portion of the RCA” and what that is as it is referred back
t in section 2.3.

Old

The BGP Router Capabilities attribute (RCA attribute, or just RCA) is an
optional, transitive BGP path attribute with type code 39. The RCA has as its
data a network layer address, representing the next hop of the route the RCA
accompanies.

New

The BGP Router Capabilities attribute (RCA attribute, or just RCA) is an
optional, transitive BGP path attribute with type code 39. The RCA header has
its data field set to the network layer address, representing the next hop of
the NLRI AFI / SAFI route.

Rewritten to make more clear
I would  not call RCA an optimization but rather a way to provide next hop
intelligence in an opaque data fields that is extensible to a variety of
meanings

Old
The RCA signals potentially useful optimizations, 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 RCA. New The RCA signals potentially useful
next hop extensibility logic, so it is desirable to make it transitive; the
next hop data is to ensure correctness in cases where it may traverses BGP
speakers that do not understand the RCA.

Nits:
Abstract
Should say a “new optional transitive attribute” as its optional.

As the NHC was folded into ELCv3 no need to reference this draft.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-next-hop-capability-08

Introduction
This specification defines a new BGP optional transitive attribute to carry
such capability information, the "Router Capabilities Attribute", or RCA. (This
somewhat ponderous name is regrettable but is needed in order to be descriptive
while still distinguishing it from RFC 5492 BGP Capabilities.) Maybe you can
exlclude in (This somewhat ponderous name is regrettable but is needed in order
to be descriptive while still distinguishing it from RFC 5492 BGP
Capabilities.)  I think RCA is an appropriate term to the use case and as it
may seem confusing RFC 5492 “capability advertisement with BGP” is subjective
only that the word “capability” is used in both but RFC 5492 is “BGP
capability” update with the addition of capability options parameter type 2 &
error handling  where RCA is about “router capability” advertisement.

! Making this next two sentences easier to parse

Old
Since the RCA is intended chiefly for conveying information about forwarding
plane features, it needs to be regenerated whenever the BGP route's next hop is
changed. Since owing to the properties of BGP transitive attributes this can't
be guaranteed (an intermediate router that doesn't implement this specification
would be expected to propagate the RCA as opaque data), the RCA identifies
itself with the next hop of its originator. New Since RCA is intended for
conveying information about forwarding plane features, RCA MUST to be
regenerated whenever the BGP route's next hop is changed.  Transitiveness of
BGP path attributes does not guarantee this behavior (an intermediate router
that doesn't implement this specification would be expected to propagate the
RCA as opaque data), thus requiring the RCA to identify itself with the next
hop of its originator.

Last sentence in introduction

Old
It updates [RFC6790] and [RFC7447] with regard to this BGP signaling, this is
further discussed in Section 3. New It updates [RFC6790] and [RFC7447] with
regard to this BGP signaling, discussed further in Section 3.

I am in agreement with the updates from Rev 5 to Rev6 in the changes made in
Section 2.2 & 2.3.  In particular that the implementation should accept the RCA
by default.  In section 2.2 & 2.3 sending & receiving the RCA is the default
applicable to all NLRI and if so that should be specified.  As it is
recommended to have configuration control and fine grain control that maybe
available for attribute propagation  by implementations for advertising and
accepting RCA, I think its OK to send & receive RCA for ALL NLRI by default.

Since the RCA is being used for signaling of the next hop data field extensible
to any TLVs that require such as entropy label for load balancing or any other
use case I am not sure how the path attribute could impact routing and cause a
routing loop as its not a mandatory path attribute and is optional transitive
but is not part of the BGP best path selection algorithm.   In cases where all
nodes do not understand the capability which is understandable and the RCA
draft accounts for that with regards to propagation w/o regeneration with next
hop changes results in mismatch and the RCA is discarded.  So that does provide
the interoperability with other non supporting nodes and provides incremental
deployment so now sure how the RCA could result in routing loops.  Maybe this
subject should be expanded upon if its a real danger.

The presence of a capability SHOULD NOT influence route selection or route
preference, unless tunneling is used to reach the BGP next hop or the selected
route has been learned from External BGP (that is, the next hop is in a
different Autonomous System). Indeed, it is in general impossible for a node to
know that all BGP routers of the Autonomous System (AS) will understand a given
capability, and if different routers within an AS were to use a different
preference for a route, forwarding loops could result unless tunneling is used
to reach the BGP next hop.¶

Section 2.5 Talks about the Anycast use case

AFAIK with MPLS unidirectional LSP is possible and LDP downstream unsolicited 
from downstream to upstream node label mapping message for the FEC label
binding.  If we had multiple egress PE LER with the same loopback the LSP would
only build to one of the egress LSRs not all of them.  I think this section
should be removed as Anycast is really only relevant in the context of SR-MPLS
using the Anycast SID where the node-sid loopback0 is defined on multiple
egress PE’s for resiliency or on inter-domain boundaries with node-sid same
loopback on all ASBRs.

Section 6.1

Good idea to include OAD draft here to incorporate into the specification for
RCA use cases "inter admin domain" RCA localization for cooperating ASN’s in an
OAD. https://datatracker.ietf.org/doc/draft-uttaro-idr-bgp-oad/

As the RCA optional transitive attribute is likely to be propagated inter
domain resulting in “attribute escape” it is at least limited to the receiving
ASBR which will fail the next hop check and discard the RCA.  The next hop
within the operator domain would be then then exposed to the other carriers
domain but limited to the 1st ASBR within the domain.  Care must be taken with
unwanted leakage of next hop data field and unintentional exposure and
consequences.

https://datatracker.ietf.org/doc/draft-haas-idr-bgp-attribute-escape/

Kind Regards

Gyan