Re: Alvaro Retana's Discuss on draft-ietf-6man-segment-routing-header-22: (with DISCUSS and COMMENT)

["Darren Dukes (ddukes)" <[e-mail]>]

Hi Alvaro, thanks for your detailed review.  Please see inline.

On Sep 5, 2019, at 2:13 AM, Alvaro Retana via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-6man-segment-routing-header-22: Discuss

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

The new "Segment Routing Header TLVs" registry (§8.2) includes a range "for
TLVs that may change en route".  However, I couldn't find a specification for
these types of TLVs.  The only clues come from §4.3.1 (FIB Entry Is Locally
Instantiated SRv6 SID), where it says:

  Processing this SID modifies the Segments Left and, if configured to
  process TLVs, it may modify the "variable length data" of TLV types
  that change en route.  Therefore Segments Left is mutable and TLVs
  that change en route are mutable.  The remainder of the SRH (Flags,
  Tag, Segment List, and TLVs that do not change en route) are
  immutable while processing this SID.

From section 2.1
<quote>

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
   |     Type      |    Length     | Variable length data
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------


</quote>

I think there is some confusion with your interpretation of “variable length data”.
As defined in section 2.1 “variable length data” is only the bits following Type and Length.
This is why it was placed in quotes as it is normatively defined in section 2.1.


Section 2.1 also says:

<quote>

   The highest-order bit of the TLV type (bit 0) specifies whether or
   not the TLV data of that type can change en route to the packet's
   final destination:

      0: TLV data does not change en route

      1: TLV data does change en route


</quote>
Again ‘data’ refers only to only the “variable length data” not Type nor Length.

The WG decided on this language based on RFC8200’s use of the same.



I am balloting DISCUSS because the description of "TLVs that may change en
route" is not clear or specific enough.  I would like to see a clear
specification of what "TLVs that may change en route" are, *AND* corresponding
instructions to the Designated Experts-to-be.

  Some related questions that come to mind include: Where can these TLVs be
  processed/changed?

Extension headers are only processed at the node represented by the destination address in the IPv6 header.
Section 4.3.1 reiterates this with its definition of SID processing

 If the data is modified, what about the alignment,
  should the Padding TLVs be also changed?

No, the Length never changes.

If no data is left, can the TLV be
  removed?

No, the Length never changes.

 The instructions above (for the SRV6 SID) seem generic enough to
  apply to other potential future SIDs, what type of variation is expected?

Several TLV types are defined outside of this specification that were originally part of it.
One example is https://www.ietf.org/id/draft-xuclad-spring-sr-service-programming-02.txt

Thanks,
  Darren



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

(1) I support Ben's DISCUSS.

Adding to his HMAC concerns, §2.1 says that when "processing the SID defined in
Section 4.3.1, all TLVs are ignored unless local configuration indicates
otherwise (Section 4.3.1.1.1).  Thus, TLV and HMAC support is optional for any
implementation..."  This seems to indicate that, regardless of the HMAC
security properties, it will be ignored by default.

(2) §4.1.1: "When a source does not require the entire SID list to be preserved
in the SRH, a reduced SRH may be used."  When does a source require the entire
SID list to be preserved?  Please provide an example of these cases.

(3) §8.1: Given that the SRH Flags Bits are limited, I would like to see
instructions to the DEs-to-be about the type of information that may need to be
encoded in the Header.