[Idr] draft-ietf-idr-rfc5575bis-19, reverting to consensus text on opaque typed NLRI

[John Scudder <[e-mail]>]

Hi All,

A while ago we had some debate on the list regarding opaque typed flowspec NLRI, which was introduced post-WGLC. It seems to me the consensus is that what we WGLC’d is what’s right and that we should essentially return to it. After a side conversation with the authors and AD, I agree. I’d like to ask the authors to make the necessary change (see the draft changes Christoph was so kind as to provide, below) and we’ll consider it closed.

This doesn’t mean we should consider extensibility a dead letter, but that we should address it in Flowspec v2 (or whatever name we end up choosing for that work).

Thanks,

—John


Section 4.1., paragraph 0:
REMOVE:

    The Flow Specification NLRI is considered a Typed NLRI in the sense
    of Section 5.4 of [RFC7606].  See also Section 4.2 on unknown
    component type handling.
 

Section 4.2., paragraph 6:
OLD:

    An advertisement containing an unknown Flow Specification component
    type should be discarded as specified in Section 5.4 of [RFC7606].
    It needs to be pointed out that the encoding of the NLRI as a 2-tuple
    <length, NLRI value> allows to skip over a NLRI value (the NLRI that
    value should be discarded).
 
    Except for an unknown component type (see above), a NLRI value not
    encoded as specified in Section 4.2 is considered malformed and error
    handling according to Section 10 is performed.

NEW:

    A NLRI value not encoded as specified in Section 4.2 is considered
    malformed and error handling according to Section 10 is performed.



Section 10., paragraph 3:
REMOVE:

 11.  Future NLRI Extensions
 
    Future Flow Specification extensions may introduce new Flow
    Specification components.  If a receiving BGP speaker decodes an
    unknown Flow Specification component type it is unable to continue
    decoding the following Flow Specification components in the same NLRI
    value and MUST discard this NLRI value and all its components as
    described in Section 4.2 for further processing.  Since the NLRI
    field encoding (Section 4) is defined in the form of a 2-tuple
    <length, NLRI value> message decoding can skip over the NLRI value
    and continue with subsequent NLRI and message decoding.
 
    The specification of a new Flow Specification Component Type MUST
    clearly identify what the criteria used to match packets forwarded by
    the router is.  This criteria should be meaningful across router hops
    and not depend on values that change hop-by-hop such as TTL or Layer
    2 encapsulation.
 
    Such extensions SHOULD also specify a way to encode an "always-match"
    match condition within the newly introduced components (this is a
    match condition, encoded with the newly introduced components: If
    present on its own, matches all flows).  This match condition can be
    used to propagate (and apply) certain Flow Specifications only if a
    specific extension is known to the implementation.


 
12.  Security Considerations
Section 1000., paragraph 2:
REMOVE:

    When BGP decodes an unknown Flow Specification component type, as of
    Section 4.2 it needs to discard the NLRI and skip over the remaining
    undecoded octets to the following NLRI or to the end of the list.
    Skipping over unknown octets of the to be discarded NLRI is the
    specified behaviour for a Type NLRI in Section 5.4 [RFC7606].  While
    this is not intrinsic to the Flow Specification NLRI in particular,
    it needs to be pointed out that, carefully crafted wrong NLRI length
    fields may lead to synchronisation issues between BGP senders and
    receivers.


 
Appendix B., paragraph 2:
OLD:

       Section 1 introduces the Flow Specification NLRI.  In [RFC5575]
       this NLRI was defined as an opaque-key in BGPs database.  This
       specification has removed all references to a opaque-key property.
       BGP is able to understand the NLRI encoding.  This change also
       resulted in a new section regarding error handling and
       extensibility (Section 10 and Section 11).

NEW:

       Section 1 introduces the Flow Specification NLRI.  In [RFC5575]
       this NLRI was defined as an opaque-key in BGPs database.  This
       specification has removed all references to a opaque-key property.
       BGP is able to understand the NLRI encoding.


Appendix B., paragraph 10:
REMOVE:

       Section 11 describes graceful handling of unknown Flow
       Specification components to allow future extensions.