Subject: [Status] Summary of STATUS BOF and the next steps

From: Stewart Bryant <[email-masked]>
Date: Fri, 30 Aug 2013 18:39:52 +0100

The STATUS BOF met on 29th July and the minutes are
available here:

http://www.ietf.org/proceedings/87/minutes/minutes-87-status

Following the BOF I discussed the outcome with the I*
and with Adrian, and I  present my conclusion on the
way that I think we need to move forward.

1) There was overwhelming support for work on MPLS Source
Routing (SR), with many use cases presented.

2) Whilst the use cases presented were not as extensive for
IPv6 as they were for MPLS, and whilst the level of support
for IPv6 SR was less, there was none the less an interest
in an IPv6 SR solution.

3) An SR solution will require protocol work in at least 7 working
groups in RTG and with IPv6 one or two in the INT area.  This
will require significant co-ordination to ensure a consistent
design for the protocol suit. That in turn will require the
chartering of a WG that is tasked with publishing the core
document set, in particular the use-cases, requirements
and framework (plus any SR documents that have no other
good home), and to act as a co-ordination point to ensure
the consistency of SR work necessarily done elsewhere in
the IETF.

4) Although there was some suggestion that the  central
work might be done in RTGWG, the function of RTGWG
is small short term work items, which does not map well
to the SR task. A new WG focused solely on SR therefore
needs to be created, and this needs to be ready to meet in
Vancouver.

There are therefore two tasks that we need to undertake
in advance of Vancouver, the first and larger task is to
work on the charter. Charter proposals and discussion
needs to take place on this list.  In writing the charter
I think that it would be wise to ensure that as much of
the work as possible is data plane agnostic. It would also
be wise to, whilst ensuring the generality of technology,
prioritize some of the use cases so as to keep the
work and the complexity to a manageable level.

As a reminder a tentative charter was posted here
http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87
but that is very much just an initial starting point.

The second task, which hopefully should be relatively easy,
is to find a better working name for the WG, since it has
been put to me a number of times that STATUS is going to
be confusing in text and a difficult search term.

- Stewart
(STATUS sponsoring AD)

---

From: Acee Lindem <[email-masked]>
Date: Fri, 30 Aug 2013 18:27:52 +0000

We can call the new WG - Dynamic Internet Source Routing Using Perverse Tunneling (DISRUPT). 

The "Perverse" is assuming a new IPv6 source routing header... 

Acee

On Aug 30, 2013, at 1:39 PM, Stewart Bryant wrote:

> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 30 Aug 2013 11:49:15 -0700

I would suggest the name SORT - SOurce Routed Tunnels.

- Sri

On Fri, Aug 30, 2013 at 10:39 AM, Stewart Bryant <[email-masked]> wrote:

> http://www.ietf.org/**proceedings/87/minutes/**minutes-87-status<http://www.ietf.org/proceedings/87/minutes/minutes-87-status>
>
> http://trac.tools.ietf.org/**bof/trac/wiki/BofIETF87<http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87>
> ______________________________**_________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/status<https://www.ietf.org/mailman/listinfo/status>
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 30 Aug 2013 18:54:17 +0000

Segment Routing WG

Sent from my iPhone

---

From: "Santiago Alvarez (saalvare)" <[email-masked]>
Date: Fri, 30 Aug 2013 21:25:26 +0000

+1

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alvaro Retana (aretana)
> Sent: Friday, August 30, 2013 11:54 AM
> To: Stewart Bryant (stbryant)
> Cc: Adrian Farrel; [email-masked]; John G. Scudder
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
> 
> Segment Routing WG
> 
> Sent from my iPhone
> 
> > The second task, which hopefully should be relatively easy, is to
> find
> > a better working name for the WG, since it has been put to me a
> number
> > of times that STATUS is going to be confusing in text and a difficult
> > search term.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 30 Aug 2013 21:26:30 +0000

Same here

Regards,
Jeff

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 30 Aug 2013 21:36:10 +0000

Stuart, assuming we wish to be agnostic to data paths and stealing some BOF intro text then something *beginning* like this?

-------------------------------

SRV2 ( Source Routing - Version 2.0 )

The IETF currently has two packet-based forwarding technologies capable of source routing IP and MPLS.

IPv4 and IPv6 previously had source-based routing mechanisms made available through an IP Option. These mechanisms have, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all. 

The ability of a device to influence or control the forwarding path of an individual packet or all the packets of a given flow is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, backup (bypass tunnels, Remote Loop-Free Alternates) routing, and control performance enhancements. This can be achieved by facilitating source-initiated selection of routes/hops to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. The SR mechanisms can also be used statically or with central control.

The SRV2 working group will define a generalized SR data plane which is independent of existing SR capable data planes including IP options and MPLS label stacks. The generalized SR data plane would be a superset of existing SR capable data planes and be flexible in the sizing of its various fields to ensure longevity.

The SRV2 working group will define mappings from the idealized SR data plane to MPLS label stacks and to IP V6 SR options.

The SRV2 working group will define control/management plane extensions in conjunction with the relevant working groups. 

The control/management plane extensions will be specified in terms of the generalized SR data plane to ensure compatibility with future more generalized SR capable hardware. 

The SRV2 working group will initially target control/management plane extensions for 
     TBD ......

------------------------------

Cheers,

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, August 30, 2013 1:40 PM
To: [email-masked]
Cc: Alvaro Retana; John G. Scudder; Adrian Farrel
Subject: [Status] Summary of STATUS BOF and the next steps

- Stewart
(STATUS sponsoring AD)

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 30 Aug 2013 14:43:04 -0700

Is there a plan to support multicast, or is the initial effort for unicast
only?

Anoop

On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPeter <
[email-masked]> wrote:

> Stuart, assuming we wish to be agnostic to data paths and stealing some
> BOF intro text then something *beginning* like this?
>
> IPv4 and IPv6 previously had source-based routing mechanisms made
> available through an IP Option. These mechanisms have, however, not been
> widely used and has a number of issues that make its use inadvisable, and
> other mechanisms (such as RFC 1940) do not appear to have been implemented
> at all.
>
> The ability of a device to influence or control the forwarding path of an
> individual packet or all the packets of a given flow is a desirable feature
> for a number of reasons including Label Switched Path stitching, egress
> protection, explicit routing, egress ASBR link selection, backup (bypass
> tunnels, Remote Loop-Free Alternates) routing, and control performance
> enhancements. This can be achieved by facilitating source-initiated
> selection of routes/hops to complement the route selection provided by
> existing routing protocols for both inter-domain and intra-domain routes.
> The SR mechanisms can also be used statically or with central control.
>
> The SRV2 working group will define a generalized SR data plane which is
> independent of existing SR capable data planes including IP options and
> MPLS label stacks. The generalized SR data plane would be a superset of
> existing SR capable data planes and be flexible in the sizing of its
> various fields to ensure longevity.
>
> The SRV2 working group will define mappings from the idealized SR data
> plane to MPLS label stacks and to IP V6 SR options.
>
> The SRV2 working group will define control/management plane extensions in
> conjunction with the relevant working groups.
>
> The control/management plane extensions will be specified in terms of the
> generalized SR data plane to ensure compatibility with future more
> generalized SR capable hardware.
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 30 Aug 2013 22:00:24 +0000

Most of the stateless multicast solutions  are not practical except head end replication. ie still research as far as I know.

Header encodings are big of course and bloom filters suffer false positives.

Peter

On Aug 30, 2013, at 5:43 PM, "Anoop Ghanwani" <[email-masked]<mailto:[email-masked]>> wrote:

Is there a plan to support multicast, or is the initial effort for unicast only?

Anoop

On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>> wrote:
Stuart, assuming we wish to be agnostic to data paths and stealing some BOF intro text then something *beginning* like this?

Cheers,

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stewart Bryant
Sent: Friday, August 30, 2013 1:40 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Alvaro Retana; John G. Scudder; Adrian Farrel
Subject: [Status] Summary of STATUS BOF and the next steps

- Stewart
(STATUS sponsoring AD)

_______________________________________________
status mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/status
_______________________________________________
status mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/status

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 30 Aug 2013 16:02:37 -0700

Thanks Peter.  I think it would be useful to have an explicit statement
about multicast in the charter, one way or another.

Anoop

On Fri, Aug 30, 2013 at 3:00 PM, AshwoodsmithPeter <
[email-masked]> wrote:

>  Most of the stateless multicast solutions  are not practical except head
> end replication. ie still research as far as I know.
>
> On Aug 30, 2013, at 5:43 PM, "Anoop Ghanwani" <[email-masked]>
> wrote:
>

---

From: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Sat, 31 Aug 2013 18:33:00 +0000

I agree, m/c should be included in the charter, although I think it wound be a mistake to allow it to gate unicast.

S

Sent from my iPad

On 31 Aug 2013, at 00:02, "Anoop Ghanwani" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Peter.  I think it would be useful to have an explicit statement about multicast in the charter, one way or another.

Anoop

On Fri, Aug 30, 2013 at 3:00 PM, AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>> wrote:
Most of the stateless multicast solutions  are not practical except head end replication. ie still research as far as I know.

Peter

Anoop

Cheers,

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Stewart Bryant
Sent: Friday, August 30, 2013 1:40 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Alvaro Retana; John G. Scudder; Adrian Farrel
Subject: [Status] Summary of STATUS BOF and the next steps

- Stewart
(STATUS sponsoring AD)

---

From: Christian Martin <[email-masked]>
Date: Sat, 31 Aug 2013 14:48:49 -0400

Agreed.  We should outline m/c but keep it separate from unicast.

+1 for Segment Routing WG

Cheers
Chris

Sent from my iPhone

On Aug 31, 2013, at 2:33 PM, "Stewart Bryant (stbryant)" <[email-masked]> wrote:

> On 31 Aug 2013, at 00:02, "Anoop Ghanwani" <[email-masked]> wrote:
> 
>> On Fri, Aug 30, 2013 at 3:00 PM, AshwoodsmithPeter <[email-masked]> wrote:
>>> On Aug 30, 2013, at 5:43 PM, "Anoop Ghanwani" <[email-masked]> wrote:
>>> 
>>>> On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPeter <[email-masked]> wrote:

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Sat, 31 Aug 2013 22:51:33 +0000

Roberta

Sent from my iPad