Subject: Re: AD Evaluation: draft-ietf-6man-segment-routing-header-21

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 6 Aug 2019 16:01:09 +0000

draft-ietf-6man-segment-routing-header-22 has been posted to resolve these comments from the AD evaluation.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-22
https://datatracker.ietf.org/doc/html/draft-ietf-6man-segment-routing-header-22

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-segment-routing-header-22

Thanks
  Darren

On Jul 25, 2019, at 3:52 PM, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:

The changes look good to me Darren. I will send the draft along as soon as the new version posts.

Regards
Suresh

On Jul 25, 2019, at 3:03 PM, Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:

FYI. I plan to publish an updated draft mid next week based on these responses.

Darren

On Jul 23, 2019, at 6:00 PM, Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Suresh, here’s the follow up from todays session.

On Jul 20, 2019, at 12:16 AM, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:

Hi authors,
 I have completed my AD evaluation of draft-ietf-6man-segment-routing-header-21 and found the draft to be well written and easy to understand. There are a few issues I would like to see addressed before I send it off to IETF Last Call and I have listed them below.

Major:

* Section 2.1.

 TLVs are present when the Hdr Ext Len exceeds the Last Entry element
 in the Segment List.

This seems to be wrong. Say there are 5 entries in the Segment list and no TLVs. The Hdr Ext Len would be 10 and the Last Entry will be 4.

Lets clarify this with some math.  Something like...

<OLD>
TLVs are present when the Hdr Ext Len exceeds the Last Entry element
in the Segment List.
</OLD>

<NEW>
TLVs are present when the Hdr Ext Len is greater than ((Last Entry+1)*2).
</NEW>

* Section 2.1.2:

What is the purpose of being able to include a HMAC TLV with the Key ID set to 0 since there will be no HMAC?
The text regarding Key ID set to 0 can be removed now, it was not relevant after the HMAC was made a TLV.

* Section 2.1.2.2:

"SRH implementations can support multiple hash functions but MUST
implement SHA-2 [FIPS180-4] in its SHA-256 variant.”

Since support for the HMAC TLV is optional, I think this MUST level requirement for SRH implementations needs to be relaxed or qualified.

Adding a qualification that only implementations supporting HMAC MUST support SHA-256
<OLD>
SRH implementations can support multiple hash functions but MUST
implement SHA-2 [FIPS180-4] in its SHA-256 variant.
</OLD>

<NEW>
An implementation supporting HMAC can support multiple hash functions.
An implementation supporting HMAC MUST implement SHA-2 [FIPS180-4] in
its SHA-256 variant.
</NEW>

* Section 5.3:

I think more descriptive text is needed here. Simply specifying a greater MTU value is not enough. Can you expand on your thinking here as to what you are trying to mitigate?

<OLD>
5.3.  MTU Considerations
  Within the SR Domain, well known mitigation techniques are
  RECOMMENDED, such as deploying a greater MTU value within the SR
  Domain than at the ingress edges.
</OLD>

<NEW>
5.3.  MTU Considerations
  An SR Source node encapsulates packets traversing an SR Domain,
  so the MTU of the SR Domain needs to be considered at ingress to the SR Domain.
  Within the SR Domain, well known mitigation techniques are
  RECOMMENDED, such as deploying a greater MTU value within the SR
  Domain than at the ingress edges.

</NEW>

Minor:
=====

Section 2:

Not sure where this text is in Section 4.4 of RFC8200.

 In the SRH, the Next Header, Hdr Ext Len, and Routing Type fields are
 defined in Section 4.4 of [RFC8200] as not mutable.  The Segments
 Left field is defined as mutable in Section 4.4 of [RFC8200].

Lets qualify the reference to section 4.4.  Something like below...
<NEW>
In the SRH, the Next Header, Hdr Ext Len, Routing Type,
and Segments Left fields are defined in Section 4.4 of [RFC8200].
Based on the constraints in that section Next Header, Hdr Ext Len,
and Routing Type are not mutable while Segments Left is mutable.
</NEW>

Section 2.1.1:

I think this section should also mention that the padding TLVs are used for alignment of TLVs themselves. Something like

NEW:
Padding TLVs are used for meeting the alignment requirement of the subsequent TLVs

OK

Section 2.1.2.1:

This text in the beginning is really out of place. At this point “Text” is not even introduced.

"potentially provides an alternate composition of Text”

Some proposed text.

<OLD>
Local configuration determines when to check for an HMAC and
potentially provides an alternate composition of Text,
</OLD>

<NEW>
Local configuration determines when to check for an HMAC and
potentially indicates what the HMAC protects,

</NEW>

* Section 5.4:

Mentioning the 0th segment does not seem very obvious. Suggest rewording to

OLD:
Use the 0th segment in the segment list

NEW:
Use the SID at Segment List[0]

OK

Editorial:

Section 1:

OLD:
Segment Routing can be applied to the IPv6 data plane using a new
type of Routing Extension Header (SRH)

NEW:
Segment Routing can be applied to the IPv6 data plane using a new
type of routing extension header called the Segment Routing Header (SRH)

OK

OLD:
Terminology used within this document is defined in detail in [RFC8402].
Specifically, these terms: Segment Routing, SR Domain,
SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy.

NEW:
This document uses the terms Segment Routing, SR Domain,
SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy as defined in [RFC8402].

OK

Please let me know if you have any questions or concerns.

Thanks
Suresh