Re: Next steps on Extension Header Insertion

> On Nov 4, 2016, at 12:16 PM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
> 
>> On 3 Nov 2016, at 19:36, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>> 
>> On 03/11/2016 23:30, otroan@employees.org wrote:
>> ...
>>> Indeed, and since no-one has proposed to do this (in a draft) makes it very fuzzy what we're arguing against (or for).
>>> We're arguing about an imagined treat. ;-)
>> 
>> Huh? The segment routing header is far from imaginary.
> 
> But what do you deduce is really being specified in the SRH drafts?
> 
> In draft-ietf-6man-segment-routing-header-02 it says in section 2.2:
> 
> “While the source routing model defined in [RFC2460] doesn't mandate
>    which node is allowed to insert (or modify) the SRH, it is assumed in
>    this document that the SRH is inserted in the packet by its source.
>    For example:
> 
>    o  At the node originating the packet (host, server).
> 
>    o  At the ingress node of an SR domain where the ingress node
>       receives an IPv6 packet and 
> encapsulates
>  it into an outer IPv6
>       header followed by a Segment Routing header.”
> 
> 
> which implies the SRH uses encapsulation, and doesn’t insert an EH in the existing header chain.

indeed, the current version of the draft only describes the encapsulation case.

> 
> In draft-ietf-spring-segment-routing-09 it says in section 8.2:
> 
> "From a network protection standpoint, there is an assumed trust model
>    such that any node adding an SRH to the packet is assumed to be
>    allowed to do so."
> 
> 
> so “adding” is a little vague.

draft-ietf-spring-segment-routing is an architecture draft that is agnostic on the dataplane. The same architecture components apply to MPLS and v6. 

The document doesn’t aim to provide details on SR instantiation over a specific dataplane. For that we have draft-ietf-spring-segment-routing-mpls and draft-ietf-6man-segment-routing-header.

> Perhaps both documents should be more explicit in terms of what “insert” really means?

I think a good plan would be to not introduce any new text (i.e.: leave RFC2460 unchanged wrt header insertion) for now and work on a separate document explaining segment routing header insertion. 

s.

> 
> Tim
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------