Skip to main content

Early Review of draft-ietf-idr-entropy-label-05

Request Review of draft-ietf-idr-entropy-label
Requested revision No specific revision (document currently at 14)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2023-07-31
Requested 2023-07-17
Requested by Susan Hares
Authors Bruno Decraene , John Scudder , Wim Henderickx , Kireeti Kompella , SATYA R MOHANTY , Jim Uttaro , Bin Wen
I-D last updated 2023-07-23
Completed reviews Rtgdir Early review of -06 by Gyan Mishra (diff)
Secdir Early review of -06 by Wes Hardaker (diff)
Secdir Early review of -13 by Wes Hardaker (diff)
Rtgdir Early review of -13 by Mach Chen (diff)
Opsdir Early review of -05 by Joel Jaeggli (diff)
Assignment Reviewer Joel Jaeggli
State Completed
Request Early review on draft-ietf-idr-entropy-label by Ops Directorate Assigned
Posted at
Reviewed revision 05 (document currently at 14)
Result Has nits
Completed 2023-07-23
I revieweddraft-ietf-idr-entropy-label on behalf of the operations and
managment area.

   introduced by [RFC6790], and deprecated by [RFC7447].  The latter RFC
   specifies that the ELC attribute, BGP path attribute 28, "MUST be
   treated as any other unrecognized optional, transitive attribute".
   This specification revises that requirement.

it's worth noting that  intermediate nodes which apply RFC7447 behaviors or
which are configured to strip attributes for self protection purposes (juniper
has config knob for this) are broadly equivalent to stripping these attributes.

If the case described in 2.5 occurs

2.5.  Network Operation Considerations

   In the corner case where multiple nodes use the same IP address as
   their BGP next hop, such as with anycast nodes as described in
   [RFC4786], a BGP speaker MUST NOT advertise a given capability unless
   all nodes sharing this same IP address support this capability.

having some nodes lose or fail to pass attributes due to configuration is the
equivalent of having the attributes not propagate to all nodes.

reading between the lines in 2.3

   By default, the RCA MUST NOT be accepted from peers not under the
   administrative control of the local network administrator (so,
   generally, from EBGP peers);

non-default enablement on ebgp peers is probably a relatively common case, as
when you have a bunch of internally managed private asns part of a common
administrative domain of control. so it is probably worth noting that case,
e.g. mature adults will do this all the time.

if a border router doesn't
   implement this specification, the attribute, like all BGP optional
   transitive attributes, will propagate to neighboring Autonomous

This is an unfortunate form of information leakage. e.g. only supporting
routers can be assumed follow instractions about not propagating said
attributes. it hard of not impossible to comply with 2.3 instruction if you are
unaware of teh attribute.

while I agree with  the discussion of

ELCv3 Capability

that the value of exploiting this is dubious I would be concerned that adding
new RCAs that perform other functions might be more adversely impacted.