Subject: Comments on draft-previdi-6man-segment-routing-header-00 (Was: Segment Routing IPv6 Drafts

From: Jen Linkova <[email-masked]>
Date: Thu, 6 Mar 2014 17:42:53 +0100

On Thu, Mar 6, 2014 at 1:19 PM, Stefano Previdi (sprevidi)
<[email-masked]> wrote:
> we just submitted, in 6MAN, draft-previdi-6man-segment-routing-header-00
> which consists of the ipv6 dataplane instantiation of segment routing
> (through the definition of a new routing header type).

Hi,

After reading the draft I have some minor clarifying questions/comments:

1) RFC2640 explicitly defines the meaning of "Segments Left" field for
any possible type of RH. However in SRH case this field has a
different meaning. The only case when it really matters is if SR
Endpoint Node for some reason does not recognize SRH type, so it seems
rather unlikely. However, shall not the draft mention that RFC2640
needs to be updated?

2)
"Policy List flags.  Define the type of the IPv6 addresses encoded
      into the Policy List (see below).  The following have been
      defined:

         Bits 0-2: determine the type of the first element after the
         segment list.

         Bits 3-5: determine the type of the second element.

         Bits 6-8: determine the type of the third element.

         Bits 9-1: determine the type of the fourth element."

[Comment] :
a) How many elements are actually in the list? 3 or 4? The image shows
only 3 elements of the list (and the document mentions Ingress/Egress
SR PE address and Original Source Address only).

b) Should be Bits '9-11, not 'Bits 9-1'

3) Section 4.1.1. SRH and RFC2460 behavior
"The SRH being a new type of the Routing Header, it also has the same
   properties:

      Can only appear once in the packet."

[Comment]   AFAIR RFC2460 says 'should' so it might make sense to keep
the language consistent.

4) Section 3.2 says
"Typically, the domain ingress node obtains the path it has to use for
   a given packet flow through either local configuration, local
   computation or through an interaction with an external server such as
   an SDN controller."

and then
"5.2.1. Ingress SR Node

The ingress SR node obtain the segment list by either:

      Local path computation.

      Interaction with an SDN controller delivering the path as a
      complete SRH.

   When creating the SRH (either at ingress node or in the SDN
   controller) the following is done:..."

[Comment] Somehow "local computation" is mentioned just in one place out of 3.
As the mechanism used by a node to obtain the segment list should be
out of scope of this draft. so it would make sense to mention possible
ways just once as an example.

5) Section 5.3.  FRR Flag Settings
It might be just me but this section is a little bit confusing. It
looks like the only operation applicable to that flag is setting it by
the rerouting node. It would be nice to clarify a little if there are
any other rules for processing this flag.

6) Section 5.1.  Segment Routing Operations
"The PUSH operation is implemented through the insertion of the SRH
      or the insertion of additional segments in the SRH segment list."

While the document contains detailed instructions on how each type of
SR nodes can process SRH, it does not explain the case when/why a node
would *insert* additional segment.

7) Section 5.2.1 Ingress SR Node
[Comment] IMHO it should mention that the ingress node (or any node
performing PUSH)
shall also (re)calculate HMAC.

8) (just typo):
"5.2.2.1
"The ingress node (e.g.: the host in the home network) requests the
   SRH to a control system "

I assume it should be either "requests from" or "sends the request to".

>
>> From: "Stefano Previdi (sprevidi)" <[email-masked]>
>> Subject: [spring] SR-IPv6 drafts
>> Date: March 6, 2014 11:21:35 AM GMT+01:00
>> To: "[email-masked]" <[email-masked]>
>>
>> All,
>>
>> here below you'll find the pointers to:
>> draft-martin-spring-segment-routing-ipv6-use-cases-00
>> draft-previdi-6man-segment-routing-header-00
>>
>> that have been submitted today.
>>
>> Any comment, contribution, suggestion, flames,... are welcome.
>>
>> s.
>>
>>
>> Begin forwarded message:
>>> A new version of I-D, draft-martin-spring-segment-routing-ipv6-use-cases-00.txt
>>> has been successfully submitted by Roberta Maglione and posted to the
>>> IETF repository.
>>>
>>> Name:                draft-martin-spring-segment-routing-ipv6-use-cases
>>> Revision:    00
>>> Title:               IPv6 Segment Routing Use Cases
>>> Document date:       2014-03-06
>>> Group:               Individual Submission
>>> Pages:               12
>>> URL:            http://www.ietf.org/internet-drafts/draft-martin-spring-segment-routing-ipv6-use-cases-00.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-martin-spring-segment-routing-ipv6-use-cases/
>>> Htmlized:       http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-use-cases-00
>>>
>>>
>>> Abstract:
>>> Segment Routing (SR) leverages the source routing paradigm.  A node
>>> steers a packet through a controlled set of instructions, called
>>> segments, by prepending the packet with an SR header.  A segment can
>>> represent any instruction, topological or service-based.  A segment
>>> can have a local semantic to an SR node or global within an SR
>>> domain.  SR allows to enforce a flow through any topological path and
>>> service chain while maintaining per-flow state only at the ingress
>>> node to the SR domain.
>>>
>>> The objective of this document is to illustrate some use cases that
>>> would benefit from an IPv6 Segment Routing data-plane architecture.
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>> The IETF Secretariat
>>>
>>
>>
>>
>> Begin forwarded message:
>>> A new version of I-D, draft-previdi-6man-segment-routing-header-00.txt
>>> has been successfully submitted by Stefano Previdi and posted to the
>>> IETF repository.
>>>
>>> Name:                draft-previdi-6man-segment-routing-header
>>> Revision:    00
>>> Title:               IPv6 Segment Routing Header (SRH)
>>> Document date:       2014-03-05
>>> Group:               Individual Submission
>>> Pages:               22
>>> URL:            http://www.ietf.org/internet-drafts/draft-previdi-6man-segment-routing-header-00.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-previdi-6man-segment-routing-header/
>>> Htmlized:       http://tools.ietf.org/html/draft-previdi-6man-segment-routing-header-00
>>>
>>>
>>> Abstract:
>>> Segment Routing (SR) allows a node to steer a packet through a
>>> controlled set of instructions, called segments, by prepending a SR
>>> header to the packet.  A segment can represent any instruction,
>>> topological or service-based.  SR allows to enforce a flow through
>>> any path (topological, or application/service based) while
>>> maintaining per-flow state only at the ingress node to the SR domain.
>>>
>>> The Segment Routing architecture can be applied to the IPv6 data
>>> plane with the addition of a new type of Routing Extension Header.
>>> This draft describes the Segment Routing Extension Header Type and
>>> how it is used by SR capable nodes.
>>>
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>> The IETF Secretariat
>>>
>>
>> _______________________________________________
>> spring mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spring
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
SY, Jen Linkova aka Furry

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 7 Mar 2014 10:32:26 +0000

Hi Jen,

thanks for your comments. See below.

> rather unlikely. However, shall not the draft mention that RFC2640

SRH doesn't want to mandate a change in the way other routing headers use 
the "segment left" field (or may use it in the future) so I preferred 
to just rename it in the context of SRH.

If it hurts too much, I'm fine with an rfc2460 update, but I don't think 
it's necessary.

> SR PE address and Original Source Address only).

policy list may have up to four elements. We have defined three for now. 
I agree with you: text and figures are somehow confusing.

> b) Should be Bits '9-11, not 'Bits 9-1'

yup.

> [Comment]   AFAIR RFC2460 says 'should' so it might make sense to keep

ok.

> ways just once as an example.

ok.

> It might be just me but this section is a little bit confusing.

it is not just you ;-)

>  It

a bit of history: for a long time we worked on FRR mechanisms (IP and 
MPLS and we always missed the possibility to mark a packed when being 
rerouted. So, it is not something strictly related to segment routing 
but since we had to opportunity to set such flag, we took it.

Ideally, any SR capable node that reroute the packet (because of FRR) 
would set the flag. This helps FRR strategies because in many cases 
you don't want reroute a packet twice.

I agree with you, probably more text is necessary here (or probably a 
separate document describing the usage of the FRR flag).

> would *insert* additional segment.

this is covered in the Segment Routing drafts:
   draft-filsfils-rtgwg-segment-routing
   draft-filsfils-rtgwg-segment-routing-use-cases

note that I'm in the process of renaming the draft so in a few days 
you'll see:
   draft-filsfils-spring-segment-routing
   draft-filsfils-spring-segment-routing-use-cases

I'll send the announcements anyway.

This draft (i.e.: SRH) is just about encodings of the new routing 
header type for segment routing.

> shall also (re)calculate HMAC.

note that by "ingress" we intend "the ingress node of the SR domain" 
which may (or may not) correspond to the ingress node of the network 
domain (AS, operator infrastructure, ...).

You may have an SR ingress node which is in fact a core device and 
therefore all your SR domain is well within the core infrastructure and 
HMAC is not going to be used at all.

Another example is a core SR node doing Segment Routing FRR. Such node 
will change the segment list but will not recompute the HMAC because of 
this. The packet has been validated while entering in the domain so 
there's no need to check it again along its path.

The goal of HMAC is to be sure we have a secure mechanism in order to 
handle SR packets coming from outside the network domain (or from 
untrusted sources like home devices).

> I assume it should be either "requests from" or "sends the request to".

yup.

thanks.
s.