Subject: I-D Action: draft-ietf-6man-segment-routing-header-17.txt

From: [email-masked]
Date: Mon, 25 Mar 2019 01:52:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

        Title           : IPv6 Segment Routing Header (SRH)
        Authors         : Clarence Filsfils
                          Stefano Previdi
                          John Leddy
                          Satoru Matsushima
                          Daniel Voyer
	Filename        : draft-ietf-6man-segment-routing-header-17.txt
	Pages           : 30
	Date            : 2019-03-25

Abstract:
   Segment Routing can be applied to the IPv6 data plane using a new
   type of Routing Extension Header.  This document describes the
   Segment Routing Extension Header and how it is used by Segment
   Routing capable nodes.

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-17
https://datatracker.ietf.org/doc/html/draft-ietf-6man-segment-routing-header-17

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

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 25 Mar 2019 08:54:34 +0000

Hello 6man and spring WGs.  We have a new version of the SRH published.

Changes in this version include...
 
Network Programming: Remove reference
TLV processing limits: When length of TLVs exceeding hdr ext len, say what to do
Pad TLV: Minor description updates
HMAC: Cover destination address matching first segment
Extension header processing order: Process in the order received
Flow label/ECMP: Set for intra-domain and inter-domain packets

Thanks
  Darren

On 2019-03-25, 4:53 AM, "ipv6 on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    
    Abstract:

    

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

---

From: Tom Herbert <[email-masked]>
Date: Mon, 25 Mar 2019 11:55:10 +0100

Hi Darren,

Some comments in line.

> TLV processing limits: When length of TLVs exceeding hdr ext len, say what

Please see RFC8504 section 5.3 for limiting number of HBH/DO options
allowed in a packet to mitigate DOS. It seems like this should be
applicable to SR TLVs.

If I read it correctly, the new text means that padding must only be last
TLV (so really the only purpose is to pad routing header to eight byte
length alignment). Does that mean there's no use of padding for TLV
alignment?

If padding is only used at end of options, the padN isn't need. Padding can
be zeroes, and when receiver encounters type zero option that is taken as
end of list.

> Flow label/ECMP: Set for intra-domain and inter-domain packets

It's not clear why setting flow label needs to be a MUST (i.e. it is
technically an optimization), nor what the specific interaction is with SR.
I would think it's sufficient to say that flow label SHOULD be set when
using SR (IMO it's a SHOULD for any use of IPv6 anyway).Good news is that
AFAIK all the host OSes have been updated to set flow label by default, so
flow label ip-in-ip v6 encapsulation should just be a matter of copying
label from inner to outer header.

Tom

>
> Thanks
>   Darren
>
> On 2019-03-25, 4:53 AM, "ipv6 on behalf of [email-masked]" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>