Subject: Magnus Westerlund's Discuss on draft-ietf-6man-segment-routing-header-22: (with DISCUSS and COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 05 Sep 2019 05:13:01 -0700

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

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/

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

I have several issues that appears to be serious enough that I really like some
feedback on them prior to approving the document.

1. Section 2.1:

           An implementation MAY limit the number and/or length of TLVs it
   processes based on local configuration.  It MAY:
        o  Limit the number of consecutive Pad1 (Section 2.1.1.1) options to
      1, if padding of more than one byte is required then PadN
      (Section 2.1.1.2) should be used.
        o  Limit the length in PadN to 5.
        o  Limit the maximum number of non-Pad TLVs to be processed.
        o  Limit the maximum length of all TLVs to be processed.
        The implementation MAY stop processing additional TLVs in the SRH
   when these configured limits are exceeded.

        Isn't this repeating the same interoperability and extensibility issues
        we have for IPv6 extension headers in an IPv6 Routing header? Wouldn't
        it be better to tighten a bit the possibilities for the basic support
        of at least handling TLVs, and if anyone defines something larger they
        know this will be more uphill work to ensure that you get support for
        it. But it will making matching the constraints likely more easily to
        deploy as implementations haven't made different choices of what is
        required to support when it comes to handling TLVs and buffer them for
        example in their implementations.

2. Section 2.1.2.1

   If HMAC verification fails, an ICMP error message (parameter problem,
   error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate
   limited) and SHOULD be logged.

Shouldn't it be made explicit that the packet should be discarded? Please
clarify the text.

3. Section 5.3:

5.3.  MTU Considerations
        An SR Domain ingress edge node encapsulates packets traversing the SR
   Domain, and needs to consider the MTU of 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.

I find this section very much lacking. Considering that the minimal usage of
this RH is 24 bytes, and getting above 100 bytes of overhead is trivial. 3
segments plus the HMAC TLV is 96 bytes.

The text mentions well known techniques (Note plural) but suggests only one.
Are the more that can be referenced?

The one mentioned requires one to calculate the worst case overhead for the SR
domain for the this routing header. Then take the lowest available path MTU and
subtract that worst case overhead to find the supported MTU. Then police that
value at the ingresses to the SR domain to ensure consistent behavior that Path
MTU discovery methods can work with.

What do you do if one of the path MTUs inside the SR domain is 1280?

This document do need to answer this question or I believe write an
applicability statement restrict this to not work in such network where the
1280 minimal MTU can be ensured. As Joe Touch note in his TSV-ART review this
is non trivial and I don't see punting on these MTU question will work in
general:
https://mailarchive.ietf.org/arch/msg/tsv-art/cdMgmFS79lBr7oha9Z4S4qqqA8c

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

1. Section 2.
         o  Tag: tag a packet as part of a class or group of packets, e.g.,
      packets sharing the same set of properties.  When tag is not used
      at source it MUST be set to zero on transmission.  When tag is not
      used during SRH Processing it SHOULD be ignored.  Tag is not used
      when processing the SID defined in Section 4.3.1.  It may be used
      when processing other SIDs which are not defined in this document.
      The allocation and use of tag is outside the scope of this
      document.

           Consistent with the source routing model, the source of the SRH
   always knows how to set the segment list, Flags, Tag and TLVs of the
   SRH for use within the SR Domain.  How it achieves this is outside
   the scope of this document, but may be based on topology, available
   SIDs and their mutability properties, the SRH mutability requirements
   of the destination, or any other information.

        Are there any scoping of the Tag field? I assume that it is SR domain
        local, is there any scoping based on any other IPv6 header fields? To
        me this tag appears to be a magic field, which one can hang almost any
        functionality on. It can represent QoS, policy, etc. I at least see it
        as 16-bit extra DSCP field, is that a misunderstanding? Have there been
        much discussion about how this field is going to affect
        interoperability?

        I also note that the rest of the document does not discuss the tag
        field. I can assume that it is only segment endpoints that will process
        it due to the transit nodes are supposed to not look at the routing
        header. (But is something that could easily be violated if the goal is
        to enable the use of the tag for some purpose assuming that you can get
        implementations that does that.)

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 16 Sep 2019 07:32:59 +0000

Hi Magnus.  Thanks for the review, please see inline.

> On Sep 5, 2019, at 8:13 AM, Magnus Westerlund via Datatracker <[email-masked]> wrote:
> 
> 

Indeed it should.

> What do you do if one of the path MTUs inside the SR domain is 1280?

Provider MPLS networks have operated with larger internal MTU within their domains than at the ingress edge for a very long time.

> https://mailarchive.ietf.org/arch/msg/tsv-art/cdMgmFS79lBr7oha9Z4S4qqqA8c

It seems to be more appropriate to reference the IPv6 tunnel packet size section of RFC2473 and its recommendations for IPv6 tunnels.
I’ll close this with Joe, point taken.

The SRH is defined for use within the SR Domain.  This includes the Tag.
The SRH is only inspected at nodes in the destination address.
The discussion within the WG has resulted in the text in the document.

Thanks
  Darren

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Sep 2019 12:07:40 +0000

Hi Darren, 

Please see inline. 

> > On Sep 5, 2019, at 8:13 AM, Magnus Westerlund via Datatracker <

No comment on this issue. Primarily asking to understand if this was
discussed. 

> Provider MPLS networks have operated with larger internal MTU within
> their domains than at the ingress edge for a very long time.

That is not answering my question. 

If the intention for SRH to only work in SR domains that have an
internal MTU that is larger than the ingress and where that ingress
minimal MTU is guaranteed to be over 1280 that is fine. However, if
that is the case I expect to see an applicability statement saying
exactly what requirements one have on the SR domain. 

From my perspective I think this document can select either of two
roads, either specify how one deal with fragmentation or make it
explicity what applicability this have and what network requirements
need to be fulfilled for it to work. 

> > 
> 
> It seems to be more appropriate to reference the IPv6 tunnel packet
> size section of RFC2473 and its recommendations for IPv6 tunnels.

Please do. 

> The discussion within the WG has resulted in the text in the

Okay, it is a 16-bit domain specific handling identifiers for any local
or vendor specific special things one like to do within a SR domain. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 17 Sep 2019 03:10:41 +0000

Thanks Magnus for your response, please see inline

On Sep 16, 2019, at 8:07 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:

Hi Darren,

Please see inline.

On Sep 5, 2019, at 8:13 AM, Magnus Westerlund via Datatracker <
[email-masked]<mailto:[email-masked]>> wrote:

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

I have several issues that appears to be serious enough that I
really like some
feedback on them prior to approving the document.

1. Section 2.1:

         An implementation MAY limit the number and/or length of
TLVs it
 processes based on local configuration.  It MAY:
      o  Limit the number of consecutive Pad1 (Section 2.1.1.1)
options to
    1, if padding of more than one byte is required then PadN
    (Section 2.1.1.2) should be used.
      o  Limit the length in PadN to 5.
      o  Limit the maximum number of non-Pad TLVs to be processed.
      o  Limit the maximum length of all TLVs to be processed.
      The implementation MAY stop processing additional TLVs in
the SRH
 when these configured limits are exceeded.

      Isn't this repeating the same interoperability and
extensibility issues
      we have for IPv6 extension headers in an IPv6 Routing
header? Wouldn't
      it be better to tighten a bit the possibilities for the
basic support
      of at least handling TLVs, and if anyone defines something
larger they
      know this will be more uphill work to ensure that you get
support for
      it. But it will making matching the constraints likely more
easily to
      deploy as implementations haven't made different choices of
what is
      required to support when it comes to handling TLVs and
buffer them for
      example in their implementations.

Thanks for calling my attention back to this question.

This was discussed in the working group, and this text limiting the SRH TLVs was the result - i.e. make SRH TLV limits were equivalent to option TLVs.

2. Section 2.1.2.1

 If HMAC verification fails, an ICMP error message (parameter
problem,
 error code 0, pointing to the HMAC TLV) SHOULD be generated (but
rate
 limited) and SHOULD be logged.

Shouldn't it be made explicit that the packet should be discarded?
Please
clarify the text.

Indeed it should.

3. Section 5.3:

5.3.  MTU Considerations
      An SR Domain ingress edge node encapsulates packets
traversing the SR
 Domain, and needs to consider the MTU of 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.

I find this section very much lacking. Considering that the minimal
usage of
this RH is 24 bytes, and getting above 100 bytes of overhead is
trivial. 3
segments plus the HMAC TLV is 96 bytes.

The text mentions well known techniques (Note plural) but suggests
only one.
Are the more that can be referenced?

The one mentioned requires one to calculate the worst case overhead
for the SR
domain for the this routing header. Then take the lowest available
path MTU and
subtract that worst case overhead to find the supported MTU. Then
police that
value at the ingresses to the SR domain to ensure consistent
behavior that Path
MTU discovery methods can work with.

What do you do if one of the path MTUs inside the SR domain is
1280?

Ah, I see what you’re asking.
This will have the same closure as the point below (re Joe).

This document do need to answer this question or I believe write an
applicability statement restrict this to not work in such network
where the
1280 minimal MTU can be ensured. As Joe Touch note in his TSV-ART
review this
is non trivial and I don't see punting on these MTU question will
work in
general:

Please do.

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

1. Section 2.
       o  Tag: tag a packet as part of a class or group of
packets, e.g.,
    packets sharing the same set of properties.  When tag is not
used
    at source it MUST be set to zero on transmission.  When tag is
not
    used during SRH Processing it SHOULD be ignored.  Tag is not
used
    when processing the SID defined in Section 4.3.1.  It may be
used
    when processing other SIDs which are not defined in this
document.
    The allocation and use of tag is outside the scope of this
    document.

         Consistent with the source routing model, the source of
the SRH
 always knows how to set the segment list, Flags, Tag and TLVs of
the
 SRH for use within the SR Domain.  How it achieves this is
outside
 the scope of this document, but may be based on topology,
available
 SIDs and their mutability properties, the SRH mutability
requirements
 of the destination, or any other information.

      Are there any scoping of the Tag field? I assume that it is
SR domain
      local, is there any scoping based on any other IPv6 header
fields? To
      me this tag appears to be a magic field, which one can hang
almost any
      functionality on. It can represent QoS, policy, etc. I at
least see it
      as 16-bit extra DSCP field, is that a misunderstanding? Have
there been
      much discussion about how this field is going to affect
      interoperability?

      I also note that the rest of the document does not discuss
the tag
      field. I can assume that it is only segment endpoints that
will process
      it due to the transit nodes are supposed to not look at the
routing
      header. (But is something that could easily be violated if
the goal is
      to enable the use of the tag for some purpose assuming that
you can get
      implementations that does that.)

The SRH is defined for use within the SR Domain.  This includes the
Tag.
The SRH is only inspected at nodes in the destination address.
The discussion within the WG has resulted in the text in the
document.

Cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Sep 2019 07:38:42 +0000

Hi Darren and the WG,

Thanks for clarifications. My understanding of the situation is that
the first discuss requires no changes. The second a straightforward
change. And the third part I am awaiting some proposed changes as next
steps. The first comment requires no change. 

Cheers

Magnus

On Tue, 2019-09-17 at 03:10 +0000, Darren Dukes (ddukes) wrote:
> > On Sep 16, 2019, at 8:07 AM, Magnus Westerlund <
> > [email-masked]> wrote:
> > 
> > Hi Darren, 
> > 
> > Please see inline. 
> > 
> > > > [email-masked]> wrote:
> This was discussed in the working group, and this text limiting the
> SRH TLVs was the result - i.e. make SRH TLV limits were equivalent to
> option TLVs.
> 
> > 
> > > > 2. Section 2.1.2.1
> > > > 
-- 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Sep 2019 07:41:11 +0000

Hi,

Have now checked the changes in -23 which resolves Discuss 2. I will
update the discuss to make this clear.

/Magnus

On Tue, 2019-09-17 at 07:38 +0000, Magnus Westerlund wrote:
> > > > >       deploy as implementations haven't made different
> > > > > choices
> > > > > of
> > > > > what is
> > > > > 1280 minimal MTU can be ensured. As Joe Touch note in his
> > > > > TSV-
> > > > > ART
> > > > > review this
> > > > >     at source it MUST be set to zero on transmission.  When
> > > > > tag
> > > > > is
> > > > > not
> > > > >  always knows how to set the segment list, Flags, Tag and
> > > > > TLVs
> > > > > of
> > > > > the
> > > > >       Are there any scoping of the Tag field? I assume that
> > > > > it
> > > > > is
> > > > > SR domain
-- 
Cheers

Magnus Westerlund