Re: draft-ietf-6man-segment-routing-header

Hi Ron, I do not agree with your proposal, nor analysis. Here is why.

With respect to combining or simultaneous last call…
- There are many successful definitions of a dataplane protocol without defining all the potential applications.
- For example RFC3032 defined MPLS back in 2001 and there are many other documents defining label usage and signalling.  RFC 8200 is similar IMO.

In response to the rational:

1 - It is possible to build a node that processes a Segment Routing Extension Header entirely from this draft.  
For a host A::1 which generates a packet to host F::1 and chooses to include an SRH with SIDs 1::1 (an END SID) and 2::2 (an END.X SID).
The SID list in the SRH would contains three IPv6 addresses <1::1,2::1,F::1>  where F::1 is the last SID in the list, 1::1 is the first.  The last SID is the ultimate destination address of the packet.
No further definition of SIDs, nor SRH, is required for the application at A::1 and F::1 to function.
The meaning of F::1 is entirely up to the source and destination nodes and need not be defined by the SRH specification itself, I think this has been obvious.

2 - Where there are contradictions we should be addressing them in the dependent document, that is draft-filsfils-spring-srv6-network-programming.

3 - draft-filsfils-spring-srv6-network-programming makes no modification to the addressing architecture defined in rfc4291 and other existing extensions of that document.

4 - As with #2, contradictions to base specifications should be addressed in draft-filsfils-spring-srv6-network-programming, this is the normal process.
    Having a stable SRH document that progresses independent of network programming, or any other usage, provides the foundation to build on.

Thanks
  Darren

> On Mar 15, 2018, at 1:59 PM, Ron Bonica <rbonica@juniper.net> wrote:
> 
> Folks,
> 
> While I am supportive of SRv6, draft-ietf-6man-segment-routing-header cannot be evaluated in isolation from draft-filfils-spring-srv6-network-programming. Therefore, 6man should do one of the following:
> 
> - Merge draft-ietf-6man-segment-routing-header and draft-filfils-spring-srv6-network-programming into a single draft
> - Keep the two drafts separate, but last call them simultaneously in the 6man WG
> 
> Rational follows:
> 
> 1) Using only information contained by draft-ietf-6man-segment-routing-header, it is impossible to build an SRv6 implementation
> 
> Draft-ietf-6man-segment-routing-header defines two SID types (END and END.X). Neither of these can be the last member of a SID list. Therefore, it is impossible to construct an SRH using only these. You need SIDs that are defined in draft-filfils-spring-srv6-network-programming to build a SRH
> 
> 2) Draft-filfils-spring-srv6-network-programming occasionally contradicts draft-ietf-6man-segment-routing-header
> 
> For example, draft-ietf-6man-segment-routing-header says:
> 
> " It is assumed in this document that the SRH is added to the packet by
>   its source, consistently with the source routing model defined in
>   [RFC8200].  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."
> 
> However, Section 5.2 of Draft-filfils-spring-srv6-network-programming describes a scenario in which a transit router inserts an SRH between the IPv6 header and IPv6 payload.
> 
> 3) The SRH contains a SID list and SIDs are numbered from IPv6 address space. However, the SID addressing architecture is not defined in draft-ietf-6man-segment-routing-header. It is defined in draft-filfils-spring-srv6-network-programming.
> 
> 4) Draft-filfils-spring-srv6-network-programming contains content that might surprise 6man participants
> 
> For example, Draft-filfils-spring-srv6-network-programming describes several scenarios in which the IPv6 header is followed by two instances of the SRH (See sections 4.13 and 5.2). RFC 8200 recommends against this
> 
> Furthermore, draft-filfils-spring-srv6-network-programming defines several SID types that can only occur as the final member of a SID list. 6man should examine whether the information in these SIDs should be encoded in a routing extension header or as an IPv6 destination option. This also may require coordination with the BESS WG, as many of these SIDs are redundant with MPLS VPN labels that have already been defined in BESS.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------