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

From: Ron Bonica <[email-masked]>
Date: Thu, 15 Mar 2018 17:59:13 +0000

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.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 16 Mar 2018 23:09:20 +0000

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 <[email-masked]> wrote:
> 
> Folks,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Sat, 17 Mar 2018 20:37:23 +0000

Hi Darren,

Again, I am generally supportive of SRv6 and think that it is worth the effort to produce good specification. I am even prepared to dedicate considerable time and effort to the project.

At this point, a description of all applications is not required. Nor is a description of the control plane. However, a complete description of the forwarding plane *is* required. This is much more than a description of the SRH. 

Sections 3 and 4 of draft-filsfils-spring-srv6-network-programming offer much insight regarding SRv6 forwarding plane operation. This information should be brought forward into draft-ietf-6man-segment-routing-header. When we do this, several omissions, surprises, and points of contradictions will be exposed. Once exposed, they are easily addressed. 

This doesn't have to take a long time. I suspect that we can get it done before the next IETF.

                                                                          Ron

P.S. We can debate the points below in London. For the purposes of this thread, the high order bits are most important.

> -----Original Message-----
> From: Darren Dukes (ddukes) [mailto:[email-masked]]
> Sent: Friday, March 16, 2018 7:09 PM
> To: Ron Bonica <[email-masked]>
> Cc: [email-masked]
> Subject: Re: draft-ietf-6man-segment-routing-header
> 
> - For example RFC3032 defined MPLS back in 2001 and there are many other
> documents defining label usage and signalling.  RFC 8200 is similar IMO.
> 
> 
> 
> 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.
> 
> 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
> 
> 
> 
> > 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
> 
> > 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
> 
> >
> 
> > 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.
> 
> >
> 
> > 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.
> 
> >
> 
> >
> 
> > Administrative Requests:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=aR3xxmgMd9Gr6bhM_erlD9sZLhGQlC-
> N85d8lwYmoRU&s=M81XqCC7UzZ3eV_ic9aLjoM64B5Y3ualuAQtOubRfYo&e=
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 19 Mar 2018 07:59:08 +0000

Thanks for referencing section 3 and 4 Ron, and calling attention to network-programming.

I re-read those sections and believe they are nearly fully captured in the following sections of draft-ietf-6man-segment-routing-header, as was intended.
Section 3 of network-programming is nearly fully contained in section 2.3 of segment-routing-header.
Section 4 of network-programming is nearly fully contained in section 4 of segment-routing-header.

Of course Section 4 of network-programming contains a large number of SID types with different behaviors, while the segment-routing-header draft contains only END and END.X behaviors.  This is again intentional as there will be many SIDs defined with unique behavior per application (L3VPN, etc).

Thanks for talking yesterday, we need to continue that as you are implementing the SRH draft.

Darren

On Mar 17, 2018, at 4:37 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Hi Darren,

                                                                         Ron

-----Original Message-----
From: Darren Dukes (ddukes) [mailto:[email-masked]]
Sent: Friday, March 16, 2018 7:09 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-6man-segment-routing-header

- There are many successful definitions of a dataplane protocol without
defining all the potential applications.

1 - It is possible to build a node that processes a Segment Routing Extension
Header entirely from this draft.

No further definition of SIDs, nor SRH, is required for the application at A::1
and F::1 to function.

Thanks

 Darren

On Mar 15, 2018, at 1:59 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

- Keep the two drafts separate, but last call them simultaneously in the
6man WG

Rational follows:

2) Draft-filfils-spring-srv6-network-programming occasionally contradicts
draft-ietf-6man-segment-routing-header

 [RFC8200].  For example:

4) Draft-filfils-spring-srv6-network-programming contains content that
might surprise 6man participants

[email-masked]<mailto:[email-masked]>

Administrative Requests: