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

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 2 Oct 2019 15:55:05 +0000

Hello Magnus, the text (inline) has been closed with Joe as part of the TSVART review and should resolve your third discuss.  The next revision will include this text.

On Sep 17, 2019, at 3:41 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:

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:
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:
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 Mon, 2019-09-16 at 07:32 +0000, Darren Dukes (ddukes) wrote:
Hi Magnus.  Thanks for the review, 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.

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

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?

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.

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:

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

<NEW>
Encapsulation with an outer IPv6 header and SRH have the same MTU and fragmentation
considerations as other IPv6 tunnels described in RFC2473.  Further investigation on
the limitation of various tunneling methods (including those) are discussed in draft-ietf-intarea-tunnels
and should be considered by operators when considering MTU within the SR domain.
</NEW>

Thanks
  Darren

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.

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.

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]<mailto:[email-masked]>
-----------------------------------------------------------------
-----

--
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]<mailto:[email-masked]>
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Oct 2019 06:49:19 +0000

Hi Darren,

I think the text looks reasonable, and draft-ietf-intarea-tunnels will be an
informational reference? 

Please publish a new version so that I can review it in its proper context. 

Cheers

Magnus

On Wed, 2019-10-02 at 15:55 +0000, Darren Dukes (ddukes) wrote:
> Hello Magnus, the text (inline) has been closed with Joe as part of the TSVART
> review and should resolve your third discuss.  The next revision will include
> this text.
> 
> 
> 
> > On Sep 17, 2019, at 3:41 AM, Magnus Westerlund <
> > [email-masked]> wrote:
> > 
> > Hi,
> > 
> > > > > [email-masked]> wrote:
> > > > > 
> > > > > Hi Darren, 
> > > > > 
> > > > > Please see inline. 
> > > > > 
> > > > > > > [email-masked]> wrote:
> > > > > [email-masked]
> > SE-164 80 Stockholm, Sweden | mailto: [email-masked]
-- 
Cheers

Magnus Westerlund 

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