Subject: Re: Comments on draft-ietf-6man-segment-routing-header-11

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 7 May 2018 06:43:11 +0000

Hi Tom, I should have replied earlier about closure of these issues in revision 12 of the draft.  Can you ack accordingly?

Issue 53<https://trac.ietf.org/trac/6man/ticket/53> - Section 2.3.1 is removed in revision 12
Issue 55<https://trac.ietf.org/trac/6man/ticket/55> - recommend new TLVs are 8 byte aligned to avoid need for padding, and added pad0
Issue 56<https://trac.ietf.org/trac/6man/ticket/56> - I Clarified below in email and removed that text from 3.2.

Issue 54<https://trac.ietf.org/trac/6man/ticket/54> - I think I still need more text to cover your concern, look for that in -13

Darren
On Apr 3, 2018, at 11:46 AM, Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Tom, see inline...

On Mar 31, 2018, at 4:44 PM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

Hello, here are my comments on this draft. I think the requirements
around TLVs should be at least be specified before moving forward.

From the draft: "The outer header with the SRH is no different from
any other tunneling encapsulation mechanism and allows a network
operator to implement traffic engineering mechanisms so to efficiently
steer traffic across his infrastructure."

This wording seems weak to me and provides no useful guidance. I think
it would be better to say that IPIP encapsulation is used and all the
tunneling considerations for that are applicable. It might also be
nice to leave open the door that something other than simple IPIP
encap might be needed, there's going to be a lot of deployed devices
that aren't ready to deal with a combinaton of EH and IPIP-- good
chance that some sites will lose some performance optimizations.

Section 3.1 needs a lot more requirements about dealing with TLVs. For
instance, what happens if a node doesn't understand a TLV type? Can a
TLV type appear more than once? Do nodes have to process all TLVs? Are
there any limits to the number of TLVs? Alignment requirements of
TLVs? These questions are very relevant since SR is a datapath
protocol and TLVs can easily be a source of DOS attack, especially if
the protocol allows unknown TLVs to be skipped and there's no limit to
number of TLVs in a packet.

If there are variable length TLVs (like NSH Carrier TLV) then either
TLVs should be required have a total length as a multiple of four, or
there should be padding between TLVs to maintain correct alignment.
Also, it's pretty common to define a one byte pad value (usually type
zero)-- might we worth considering here.

I think I understand what you are looking for, I’ll write up some proposed text for the TLV section that addresses these comments and have a quick review with you.

From the draft: "The DA of the packet changes at each segment
termination/completion and therefore the final DA of the packet MUST
be encoded as the last segment of the path."

In the case of encapsulation the inner destination address already has
that so this requirement should be unnecessary.

For encapsulation, the final DA of the outer IP is the tail end of the encapsulation.  Do you think the text is clear in that regard or needs clarification?

This also means that
if there is only one segment encapsulation is sufficient and SRH
wouldn't be needed in that case.

Tom

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 7 May 2018 06:43:10 +0000

Darren

This also means that

Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 7 May 2018 11:44:12 -0700

On Sun, May 6, 2018 at 11:43 PM, Darren Dukes (ddukes) <[email-masked]> wrote:
> Hi Tom, I should have replied earlier about closure of these issues in
> revision 12 of the draft.  Can you ack accordingly?
>
> Issue 53 - Section 2.3.1 is removed in revision 12

ack

> Issue 55 - recommend new TLVs are 8 byte aligned to avoid need for padding,
> and added pad0

ack, but I don't quite understand the requirement that padding can
only be used to align the whole header. Padding could be useful to
align specific TLVs.

> Issue 56 - I Clarified below in email and removed that text from 3.2.
>
ack

> Issue 54 - I think I still need more text to cover your concern, look for
> that in -13

okay, will watch for that

>
>
> Darren
>
> On Apr 3, 2018, at 11:46 AM, Darren Dukes (ddukes) <[email-masked]> wrote:
>
> On Mar 31, 2018, at 4:44 PM, Tom Herbert <[email-masked]> wrote:
>
> I think I understand what you are looking for, I’ll write up some proposed
> text for the TLV section that addresses these comments and have a quick
> review with you.
>
>
> For encapsulation, the final DA of the outer IP is the tail end of the
> encapsulation.  Do you think the text is clear in that regard or needs
> clarification?
>
> This also means that
> [email-masked]