Subject: Re: [Status] Summary of STATUS BOF and the next steps
From: "Roberta Maglione (robmgl)" <[email-masked]>
To: "Alvaro Retana (aretana)" <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Date: Sat, 31 Aug 2013 22:51:33 +0000
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>

+1 for Segment Routing WG

Roberta

Sent from my iPad

On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" <[email-masked]> wrote:

> Segment Routing WG
> 
> Sent from my iPhone
> 
> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" <[email-masked]> wrote:
> 
>> 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.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: Christian Martin <[email-masked]>
Date: Sat, 31 Aug 2013 14:48:49 -0400
To: "Stewart Bryant (stbryant)" <[email-masked]>
Cc: AshwoodsmithPeter <[email-masked]>, Anoop Ghanwani <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--Apple-Mail-1975CF1B-A47E-4315-AF37-0C930BE2AF20
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

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:

> 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]> 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]> wrote:
>>> 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]> 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]> wrote:
>>>>> 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
>>>>> 
>>>>> 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)
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
>>>>> _______________________________________________
>>>>> status mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

--Apple-Mail-1975CF1B-A47E-4315-AF37-0C930BE2AF20
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Agreed. &nbsp;We should outline m/c but keep it separate from unicast.</div><div><br></div><div>+1 for Segment Routing WG</div><div><br></div><div>Cheers</div><div>Chris<br><br>Sent from my iPhone</div><div><br>On Aug 31, 2013, at 2:33 PM, "Stewart Bryant (stbryant)" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

<div>I agree, m/c should be included in the charter, although I think it wound be a mistake to allow it to gate unicast.</div>
<div><br>
</div>
<div>S<br>
<br>
Sent from my iPad</div>
<div><br>
On 31 Aug 2013, at 00:02, "Anoop Ghanwani" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Thanks Peter. &nbsp;I think it would be useful to have an explicit statement about multicast in the charter, one way or another.
<div><br>
</div>
<div>Anoop</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Aug 30, 2013 at 3:00 PM, AshwoodsmithPeter <span dir="ltr">
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>Most of the stateless multicast solutions &nbsp;are not practical except head end replication. ie still research as far as I know.&nbsp;</div>
<div><br>
</div>
<div>Header encodings are big of course and bloom filters suffer false positives.</div>
<div><br>
Peter</div>
<div>
<div class="h5">
<div><br>
On Aug 30, 2013, at 5:43 PM, "Anoop Ghanwani" &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Is there a plan to support multicast, or is the initial effort for unicast only?
<div><br>
</div>
<div>Anoop</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPeter <span dir="ltr">
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Stuart, assuming we wish to be agnostic to data paths and stealing some BOF intro text then something *beginning* like this?<br>
<br>
-------------------------------<br>
<br>
SRV2 ( Source Routing - Version 2.0 )<br>
<br>
The IETF currently has two packet-based forwarding technologies capable of source routing IP and MPLS.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
The SRV2 working group will define mappings from the idealized SR data plane to MPLS label stacks and to IP V6 SR options.<br>
<br>
The SRV2 working group will define control/management plane extensions in conjunction with the relevant working groups.<br>
<br>
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.<br>
<br>
The SRV2 working group will initially target control/management plane extensions for<br>
&nbsp; &nbsp; &nbsp;TBD ......<br>
<br>
------------------------------<br>
<br>
Cheers,<br>
<br>
Peter<br>
<div>
<div><br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Stewart Bryant<br>
Sent: Friday, August 30, 2013 1:40 PM<br>
To: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
Cc: Alvaro Retana; John G. Scudder; Adrian Farrel<br>
Subject: [Status] Summary of STATUS BOF and the next steps<br>
<br>
The STATUS BOF met on 29th July and the minutes are<br>
available here:<br>
<br>
<a href="http://www.ietf.org/proceedings/87/minutes/minutes-87-status" target="_blank">http://www.ietf.org/proceedings/87/minutes/minutes-87-status</a><br>
<br>
Following the BOF I discussed the outcome with the I*<br>
and with Adrian, and I &nbsp;present my conclusion on the<br>
way that I think we need to move forward.<br>
<br>
1) There was overwhelming support for work on MPLS Source<br>
Routing (SR), with many use cases presented.<br>
<br>
2) Whilst the use cases presented were not as extensive for<br>
IPv6 as they were for MPLS, and whilst the level of support<br>
for IPv6 SR was less, there was none the less an interest<br>
in an IPv6 SR solution.<br>
<br>
3) An SR solution will require protocol work in at least 7 working<br>
groups in RTG and with IPv6 one or two in the INT area. &nbsp;This<br>
will require significant co-ordination to ensure a consistent<br>
design for the protocol suit. That in turn will require the<br>
chartering of a WG that is tasked with publishing the core<br>
document set, in particular the use-cases, requirements<br>
and framework (plus any SR documents that have no other<br>
good home), and to act as a co-ordination point to ensure<br>
the consistency of SR work necessarily done elsewhere in<br>
the IETF.<br>
<br>
4) Although there was some suggestion that the &nbsp;central<br>
work might be done in RTGWG, the function of RTGWG<br>
is small short term work items, which does not map well<br>
to the SR task. A new WG focused solely on SR therefore<br>
needs to be created, and this needs to be ready to meet in<br>
Vancouver.<br>
<br>
There are therefore two tasks that we need to undertake<br>
in advance of Vancouver, the first and larger task is to<br>
work on the charter. Charter proposals and discussion<br>
needs to take place on this list. &nbsp;In writing the charter<br>
I think that it would be wise to ensure that as much of<br>
the work as possible is data plane agnostic. It would also<br>
be wise to, whilst ensuring the generality of technology,<br>
prioritize some of the use cases so as to keep the<br>
work and the complexity to a manageable level.<br>
<br>
As a reminder a tentative charter was posted here<br>
<a href="http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87" target="_blank">http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87</a><br>
but that is very much just an initial starting point.<br>
<br>
The second task, which hopefully should be relatively easy,<br>
is to find a better working name for the WG, since it has<br>
been put to me a number of times that STATUS is going to<br>
be confusing in text and a difficult search term.<br>
<br>
- Stewart<br>
(STATUS sponsoring AD)<br>
<br>
<br>
<br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>

</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>status mailing list</span><br><span><a href="mailto:[email-masked]">[email-masked]</a></span><br><span><a href="https://www.ietf.org/mailman/listinfo/status">https://www.ietf.org/mailman/listinfo/status</a></span><br></div></blockquote></body></html>
--Apple-Mail-1975CF1B-A47E-4315-AF37-0C930BE2AF20--

From: "Stewart Bryant (stbryant)" <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Accept-Language: en-GB, en-US
Cc: "Alvaro Retana \(aretana\)" <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>, AshwoodsmithPeter <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--_000_2ACFDFE4415A4F1FA1AF4F0306A3F144ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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.

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?

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

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]> [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

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)

_______________________________________________
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

--_000_2ACFDFE4415A4F1FA1AF4F0306A3F144ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>I agree, m/c should be included in the charter, although I think it wound be a mistake to allow it to gate unicast.</div>
<div><br>
</div>
<div>S<br>
<br>
Sent from my iPad</div>
<div><br>
On 31 Aug 2013, at 00:02, &quot;Anoop Ghanwani&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Thanks Peter. &nbsp;I think it would be useful to have an explicit statement about multicast in the charter, one way or another.
<div><br>
</div>
<div>Anoop</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Aug 30, 2013 at 3:00 PM, AshwoodsmithPeter <span dir="ltr">
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>Most of the stateless multicast solutions &nbsp;are not practical except head end replication. ie still research as far as I know.&nbsp;</div>
<div><br>
</div>
<div>Header encodings are big of course and bloom filters suffer false positives.</div>
<div><br>
Peter</div>
<div>
<div class="h5">
<div><br>
On Aug 30, 2013, at 5:43 PM, &quot;Anoop Ghanwani&quot; &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Is there a plan to support multicast, or is the initial effort for unicast only?
<div><br>
</div>
<div>Anoop</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPeter <span dir="ltr">
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Stuart, assuming we wish to be agnostic to data paths and stealing some BOF intro text then something *beginning* like this?<br>
<br>
-------------------------------<br>
<br>
SRV2 ( Source Routing - Version 2.0 )<br>
<br>
The IETF currently has two packet-based forwarding technologies capable of source routing IP and MPLS.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
The SRV2 working group will define mappings from the idealized SR data plane to MPLS label stacks and to IP V6 SR options.<br>
<br>
The SRV2 working group will define control/management plane extensions in conjunction with the relevant working groups.<br>
<br>
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.<br>
<br>
The SRV2 working group will initially target control/management plane extensions for<br>
&nbsp; &nbsp; &nbsp;TBD ......<br>
<br>
------------------------------<br>
<br>
Cheers,<br>
<br>
Peter<br>
<div>
<div><br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Stewart Bryant<br>
Sent: Friday, August 30, 2013 1:40 PM<br>
To: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
Cc: Alvaro Retana; John G. Scudder; Adrian Farrel<br>
Subject: [Status] Summary of STATUS BOF and the next steps<br>
<br>
The STATUS BOF met on 29th July and the minutes are<br>
available here:<br>
<br>
<a href="http://www.ietf.org/proceedings/87/minutes/minutes-87-status" target="_blank">http://www.ietf.org/proceedings/87/minutes/minutes-87-status</a><br>
<br>
Following the BOF I discussed the outcome with the I*<br>
and with Adrian, and I &nbsp;present my conclusion on the<br>
way that I think we need to move forward.<br>
<br>
1) There was overwhelming support for work on MPLS Source<br>
Routing (SR), with many use cases presented.<br>
<br>
2) Whilst the use cases presented were not as extensive for<br>
IPv6 as they were for MPLS, and whilst the level of support<br>
for IPv6 SR was less, there was none the less an interest<br>
in an IPv6 SR solution.<br>
<br>
3) An SR solution will require protocol work in at least 7 working<br>
groups in RTG and with IPv6 one or two in the INT area. &nbsp;This<br>
will require significant co-ordination to ensure a consistent<br>
design for the protocol suit. That in turn will require the<br>
chartering of a WG that is tasked with publishing the core<br>
document set, in particular the use-cases, requirements<br>
and framework (plus any SR documents that have no other<br>
good home), and to act as a co-ordination point to ensure<br>
the consistency of SR work necessarily done elsewhere in<br>
the IETF.<br>
<br>
4) Although there was some suggestion that the &nbsp;central<br>
work might be done in RTGWG, the function of RTGWG<br>
is small short term work items, which does not map well<br>
to the SR task. A new WG focused solely on SR therefore<br>
needs to be created, and this needs to be ready to meet in<br>
Vancouver.<br>
<br>
There are therefore two tasks that we need to undertake<br>
in advance of Vancouver, the first and larger task is to<br>
work on the charter. Charter proposals and discussion<br>
needs to take place on this list. &nbsp;In writing the charter<br>
I think that it would be wise to ensure that as much of<br>
the work as possible is data plane agnostic. It would also<br>
be wise to, whilst ensuring the generality of technology,<br>
prioritize some of the use cases so as to keep the<br>
work and the complexity to a manageable level.<br>
<br>
As a reminder a tentative charter was posted here<br>
<a href="http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87" target="_blank">http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87</a><br>
but that is very much just an initial starting point.<br>
<br>
The second task, which hopefully should be relatively easy,<br>
is to find a better working name for the WG, since it has<br>
been put to me a number of times that STATUS is going to<br>
be confusing in text and a difficult search term.<br>
<br>
- Stewart<br>
(STATUS sponsoring AD)<br>
<br>
<br>
<br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</body>
</html>

--_000_2ACFDFE4415A4F1FA1AF4F0306A3F144ciscocom_--

Sender: [email-masked]
Date: Fri, 30 Aug 2013 16:02:37 -0700
From: Anoop Ghanwani <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--f46d043c7d22fe2bf804e5323740
Content-Type: text/plain; charset=ISO-8859-1

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.
>
>  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]>
> 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]> wrote:
>
>> 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
>>
>> 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)
>>
>>
>>
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
>>
>
>

--f46d043c7d22fe2bf804e5323740
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir="ltr">Thanks Peter. �I think it would be useful to have an explicit statement about multicast in the charter, one way or another.<div><br></div><div>Anoop</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Aug 30, 2013 at 3:00 PM, AshwoodsmithPeter <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="auto">
<div>Most of the stateless multicast solutions �are not practical except head end replication. ie still research as far as I know.�</div>
<div><br>
</div>
<div>Header encodings are big of course and bloom filters suffer false positives.</div>
<div><br>
Peter</div><div><div class="h5">
<div><br>
On Aug 30, 2013, at 5:43 PM, &quot;Anoop Ghanwani&quot; &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Is there a plan to support multicast, or is the initial effort for unicast only?
<div><br>
</div>
<div>Anoop</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPeter <span dir="ltr">
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Stuart, assuming we wish to be agnostic to data paths and stealing some BOF intro text then something *beginning* like this?<br>
<br>
-------------------------------<br>
<br>
SRV2 ( Source Routing - Version 2.0 )<br>
<br>
The IETF currently has two packet-based forwarding technologies capable of source routing IP and MPLS.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
The SRV2 working group will define mappings from the idealized SR data plane to MPLS label stacks and to IP V6 SR options.<br>
<br>
The SRV2 working group will define control/management plane extensions in conjunction with the relevant working groups.<br>
<br>
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.<br>
<br>
The SRV2 working group will initially target control/management plane extensions for<br>
� � �TBD ......<br>
<br>
------------------------------<br>
<br>
Cheers,<br>
<br>
Peter<br>
<div>
<div><br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Stewart Bryant<br>
Sent: Friday, August 30, 2013 1:40 PM<br>
To: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
Cc: Alvaro Retana; John G. Scudder; Adrian Farrel<br>
Subject: [Status] Summary of STATUS BOF and the next steps<br>
<br>
The STATUS BOF met on 29th July and the minutes are<br>
available here:<br>
<br>
<a href="http://www.ietf.org/proceedings/87/minutes/minutes-87-status" target="_blank">http://www.ietf.org/proceedings/87/minutes/minutes-87-status</a><br>
<br>
Following the BOF I discussed the outcome with the I*<br>
and with Adrian, and I �present my conclusion on the<br>
way that I think we need to move forward.<br>
<br>
1) There was overwhelming support for work on MPLS Source<br>
Routing (SR), with many use cases presented.<br>
<br>
2) Whilst the use cases presented were not as extensive for<br>
IPv6 as they were for MPLS, and whilst the level of support<br>
for IPv6 SR was less, there was none the less an interest<br>
in an IPv6 SR solution.<br>
<br>
3) An SR solution will require protocol work in at least 7 working<br>
groups in RTG and with IPv6 one or two in the INT area. �This<br>
will require significant co-ordination to ensure a consistent<br>
design for the protocol suit. That in turn will require the<br>
chartering of a WG that is tasked with publishing the core<br>
document set, in particular the use-cases, requirements<br>
and framework (plus any SR documents that have no other<br>
good home), and to act as a co-ordination point to ensure<br>
the consistency of SR work necessarily done elsewhere in<br>
the IETF.<br>
<br>
4) Although there was some suggestion that the �central<br>
work might be done in RTGWG, the function of RTGWG<br>
is small short term work items, which does not map well<br>
to the SR task. A new WG focused solely on SR therefore<br>
needs to be created, and this needs to be ready to meet in<br>
Vancouver.<br>
<br>
There are therefore two tasks that we need to undertake<br>
in advance of Vancouver, the first and larger task is to<br>
work on the charter. Charter proposals and discussion<br>
needs to take place on this list. �In writing the charter<br>
I think that it would be wise to ensure that as much of<br>
the work as possible is data plane agnostic. It would also<br>
be wise to, whilst ensuring the generality of technology,<br>
prioritize some of the use cases so as to keep the<br>
work and the complexity to a manageable level.<br>
<br>
As a reminder a tentative charter was posted here<br>
<a href="http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87" target="_blank">http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87</a><br>
but that is very much just an initial starting point.<br>
<br>
The second task, which hopefully should be relatively easy,<br>
is to find a better working name for the WG, since it has<br>
been put to me a number of times that STATUS is going to<br>
be confusing in text and a difficult search term.<br>
<br>
- Stewart<br>
(STATUS sponsoring AD)<br>
<br>
<br>
<br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div></div></div>

</blockquote></div><br></div>

--f46d043c7d22fe2bf804e5323740--

From: AshwoodsmithPeter <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Date: Fri, 30 Aug 2013 22:00:24 +0000
Accept-Language: en-US, zh-CN
Cc: Alvaro Retana <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--_000_A4847FB5AB8142E7AAF48C561E67C308huaweicom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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?

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

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]> [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

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)

_______________________________________________
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

--_000_A4847FB5AB8142E7AAF48C561E67C308huaweicom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>Most of the stateless multicast solutions &nbsp;are not practical except head end replication. ie still research as far as I know.&nbsp;</div>
<div><br>
</div>
<div>Header encodings are big of course and bloom filters suffer false positives.</div>
<div><br>
Peter</div>
<div><br>
On Aug 30, 2013, at 5:43 PM, &quot;Anoop Ghanwani&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Is there a plan to support multicast, or is the initial effort for unicast only?
<div><br>
</div>
<div>Anoop</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPeter <span dir="ltr">
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Stuart, assuming we wish to be agnostic to data paths and stealing some BOF intro text then something *beginning* like this?<br>
<br>
-------------------------------<br>
<br>
SRV2 ( Source Routing - Version 2.0 )<br>
<br>
The IETF currently has two packet-based forwarding technologies capable of source routing IP and MPLS.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
The SRV2 working group will define mappings from the idealized SR data plane to MPLS label stacks and to IP V6 SR options.<br>
<br>
The SRV2 working group will define control/management plane extensions in conjunction with the relevant working groups.<br>
<br>
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.<br>
<br>
The SRV2 working group will initially target control/management plane extensions for<br>
&nbsp; &nbsp; &nbsp;TBD ......<br>
<br>
------------------------------<br>
<br>
Cheers,<br>
<br>
Peter<br>
<div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:[email-masked]">[email-masked]</a> [mailto:<a href="mailto:[email-masked]">[email-masked]</a>] On Behalf Of Stewart Bryant<br>
Sent: Friday, August 30, 2013 1:40 PM<br>
To: <a href="mailto:[email-masked]">[email-masked]</a><br>
Cc: Alvaro Retana; John G. Scudder; Adrian Farrel<br>
Subject: [Status] Summary of STATUS BOF and the next steps<br>
<br>
The STATUS BOF met on 29th July and the minutes are<br>
available here:<br>
<br>
<a href="http://www.ietf.org/proceedings/87/minutes/minutes-87-status" target="_blank">http://www.ietf.org/proceedings/87/minutes/minutes-87-status</a><br>
<br>
Following the BOF I discussed the outcome with the I*<br>
and with Adrian, and I &nbsp;present my conclusion on the<br>
way that I think we need to move forward.<br>
<br>
1) There was overwhelming support for work on MPLS Source<br>
Routing (SR), with many use cases presented.<br>
<br>
2) Whilst the use cases presented were not as extensive for<br>
IPv6 as they were for MPLS, and whilst the level of support<br>
for IPv6 SR was less, there was none the less an interest<br>
in an IPv6 SR solution.<br>
<br>
3) An SR solution will require protocol work in at least 7 working<br>
groups in RTG and with IPv6 one or two in the INT area. &nbsp;This<br>
will require significant co-ordination to ensure a consistent<br>
design for the protocol suit. That in turn will require the<br>
chartering of a WG that is tasked with publishing the core<br>
document set, in particular the use-cases, requirements<br>
and framework (plus any SR documents that have no other<br>
good home), and to act as a co-ordination point to ensure<br>
the consistency of SR work necessarily done elsewhere in<br>
the IETF.<br>
<br>
4) Although there was some suggestion that the &nbsp;central<br>
work might be done in RTGWG, the function of RTGWG<br>
is small short term work items, which does not map well<br>
to the SR task. A new WG focused solely on SR therefore<br>
needs to be created, and this needs to be ready to meet in<br>
Vancouver.<br>
<br>
There are therefore two tasks that we need to undertake<br>
in advance of Vancouver, the first and larger task is to<br>
work on the charter. Charter proposals and discussion<br>
needs to take place on this list. &nbsp;In writing the charter<br>
I think that it would be wise to ensure that as much of<br>
the work as possible is data plane agnostic. It would also<br>
be wise to, whilst ensuring the generality of technology,<br>
prioritize some of the use cases so as to keep the<br>
work and the complexity to a manageable level.<br>
<br>
As a reminder a tentative charter was posted here<br>
<a href="http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87" target="_blank">http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87</a><br>
but that is very much just an initial starting point.<br>
<br>
The second task, which hopefully should be relatively easy,<br>
is to find a better working name for the WG, since it has<br>
been put to me a number of times that STATUS is going to<br>
be confusing in text and a difficult search term.<br>
<br>
- Stewart<br>
(STATUS sponsoring AD)<br>
<br>
<br>
<br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</body>
</html>

--_000_A4847FB5AB8142E7AAF48C561E67C308huaweicom_--

Sender: [email-masked]
Date: Fri, 30 Aug 2013 14:43:04 -0700
From: Anoop Ghanwani <[email-masked]>
To: AshwoodsmithPeter <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--f46d0438906d892abe04e5311b25
Content-Type: text/plain; charset=ISO-8859-1

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?
>
> -------------------------------
>
> 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
>
> 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)
>
>
>
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status
>

--f46d0438906d892abe04e5311b25
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir="ltr">Is there a plan to support multicast, or is the initial effort for unicast only?<div><br></div><div>Anoop</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPeter <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Stuart, assuming we wish to be agnostic to data paths and stealing some BOF intro text then something *beginning* like this?<br>

<br>
-------------------------------<br>
<br>
SRV2 ( Source Routing - Version 2.0 )<br>
<br>
The IETF currently has two packet-based forwarding technologies capable of source routing IP and MPLS.<br>
<br>
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.<br>

<br>
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.<br>

<br>
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.<br>

<br>
The SRV2 working group will define mappings from the idealized SR data plane to MPLS label stacks and to IP V6 SR options.<br>
<br>
The SRV2 working group will define control/management plane extensions in conjunction with the relevant working groups.<br>
<br>
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.<br>
<br>
The SRV2 working group will initially target control/management plane extensions for<br>
� � �TBD ......<br>
<br>
------------------------------<br>
<br>
Cheers,<br>
<br>
Peter<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:[email-masked]">[email-masked]</a> [mailto:<a href="mailto:[email-masked]">[email-masked]</a>] On Behalf Of Stewart Bryant<br>
Sent: Friday, August 30, 2013 1:40 PM<br>
To: <a href="mailto:[email-masked]">[email-masked]</a><br>
Cc: Alvaro Retana; John G. Scudder; Adrian Farrel<br>
Subject: [Status] Summary of STATUS BOF and the next steps<br>
<br>
The STATUS BOF met on 29th July and the minutes are<br>
available here:<br>
<br>
<a href="http://www.ietf.org/proceedings/87/minutes/minutes-87-status" target="_blank">http://www.ietf.org/proceedings/87/minutes/minutes-87-status</a><br>
<br>
Following the BOF I discussed the outcome with the I*<br>
and with Adrian, and I �present my conclusion on the<br>
way that I think we need to move forward.<br>
<br>
1) There was overwhelming support for work on MPLS Source<br>
Routing (SR), with many use cases presented.<br>
<br>
2) Whilst the use cases presented were not as extensive for<br>
IPv6 as they were for MPLS, and whilst the level of support<br>
for IPv6 SR was less, there was none the less an interest<br>
in an IPv6 SR solution.<br>
<br>
3) An SR solution will require protocol work in at least 7 working<br>
groups in RTG and with IPv6 one or two in the INT area. �This<br>
will require significant co-ordination to ensure a consistent<br>
design for the protocol suit. That in turn will require the<br>
chartering of a WG that is tasked with publishing the core<br>
document set, in particular the use-cases, requirements<br>
and framework (plus any SR documents that have no other<br>
good home), and to act as a co-ordination point to ensure<br>
the consistency of SR work necessarily done elsewhere in<br>
the IETF.<br>
<br>
4) Although there was some suggestion that the �central<br>
work might be done in RTGWG, the function of RTGWG<br>
is small short term work items, which does not map well<br>
to the SR task. A new WG focused solely on SR therefore<br>
needs to be created, and this needs to be ready to meet in<br>
Vancouver.<br>
<br>
There are therefore two tasks that we need to undertake<br>
in advance of Vancouver, the first and larger task is to<br>
work on the charter. Charter proposals and discussion<br>
needs to take place on this list. �In writing the charter<br>
I think that it would be wise to ensure that as much of<br>
the work as possible is data plane agnostic. It would also<br>
be wise to, whilst ensuring the generality of technology,<br>
prioritize some of the use cases so as to keep the<br>
work and the complexity to a manageable level.<br>
<br>
As a reminder a tentative charter was posted here<br>
<a href="http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87" target="_blank">http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87</a><br>
but that is very much just an initial starting point.<br>
<br>
The second task, which hopefully should be relatively easy,<br>
is to find a better working name for the WG, since it has<br>
been put to me a number of times that STATUS is going to<br>
be confusing in text and a difficult search term.<br>
<br>
- Stewart<br>
(STATUS sponsoring AD)<br>
<br>
<br>
<br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
_______________________________________________<br>
status mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/listinfo/status</a><br>
</div></div></blockquote></div><br></div>

--f46d0438906d892abe04e5311b25--

From: AshwoodsmithPeter <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 30 Aug 2013 21:36:10 +0000
Accept-Language: en-US, zh-CN
Cc: Alvaro Retana <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

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

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)

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

From: Jeff Tantsura <[email-masked]>
To: "Santiago Alvarez (saalvare)" <[email-masked]>
Date: Fri, 30 Aug 2013 21:26:30 +0000
Accept-Language: en-US
Cc: "Santiago Alvarez \(saalvare\)" <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>, "Alvaro Retana \(aretana\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Stewart Bryant \(stbryant\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Same here

Regards,
Jeff

On Aug 30, 2013, at 11:25 PM, "Santiago Alvarez (saalvare)" <[email-masked]> wrote:

> +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
>> 
>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>> <[email-masked]> wrote:
>> 
>>> 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.
>> _______________________________________________
>> status mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: "Santiago Alvarez (saalvare)" <[email-masked]>
To: "Alvaro Retana (aretana)" <[email-masked]>, "Stewart Bryant (stbryant)" <[email-masked]>
Date: Fri, 30 Aug 2013 21:25:26 +0000
Accept-Language: en-US
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>, "Santiago Alvarez \(saalvare\)" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

+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
> 
> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
> <[email-masked]> wrote:
> 
> > 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.
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

From: "Alvaro Retana (aretana)" <[email-masked]>
To: "Stewart Bryant (stbryant)" <[email-masked]>
Date: Fri, 30 Aug 2013 18:54:17 +0000
Accept-Language: en-US
Cc: Adrian Farrel <[email-masked]>, "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Segment Routing WG

Sent from my iPhone

On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" <[email-masked]> wrote:

> 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.

Sender: [email-masked]
From: Sriganesh Kini <[email-masked]>
Date: Fri, 30 Aug 2013 11:49:15 -0700
To: "Stewart Bryant (stbryant)" <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

--e89a8ff1ca78b4252204e52eaf85
Content-Type: text/plain; charset=UTF-8

I would suggest the name SORT - SOurce Routed Tunnels.

- Sri

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

> The STATUS BOF met on 29th July and the minutes are
> available here:
>
> http://www.ietf.org/**proceedings/87/minutes/**minutes-87-status<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<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)
>
>
>
> ______________________________**_________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/status<https://www.ietf.org/mailman/listinfo/status>
>

--e89a8ff1ca78b4252204e52eaf85
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div>I would suggest the name SORT - SOurce Routed Tunnels.<br><br></div>- Sri<br><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 30, 2013 at 10:39 AM, Stewart Bryant <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The STATUS BOF met on 29th July and the minutes are<br>
available here:<br>
<br>
<a href="http://www.ietf.org/proceedings/87/minutes/minutes-87-status" target="_blank">http://www.ietf.org/<u></u>proceedings/87/minutes/<u></u>minutes-87-status</a><br>
<br>
Following the BOF I discussed the outcome with the I*<br>
and with Adrian, and I  present my conclusion on the<br>
way that I think we need to move forward.<br>
<br>
1) There was overwhelming support for work on MPLS Source<br>
Routing (SR), with many use cases presented.<br>
<br>
2) Whilst the use cases presented were not as extensive for<br>
IPv6 as they were for MPLS, and whilst the level of support<br>
for IPv6 SR was less, there was none the less an interest<br>
in an IPv6 SR solution.<br>
<br>
3) An SR solution will require protocol work in at least 7 working<br>
groups in RTG and with IPv6 one or two in the INT area.  This<br>
will require significant co-ordination to ensure a consistent<br>
design for the protocol suit. That in turn will require the<br>
chartering of a WG that is tasked with publishing the core<br>
document set, in particular the use-cases, requirements<br>
and framework (plus any SR documents that have no other<br>
good home), and to act as a co-ordination point to ensure<br>
the consistency of SR work necessarily done elsewhere in<br>
the IETF.<br>
<br>
4) Although there was some suggestion that the  central<br>
work might be done in RTGWG, the function of RTGWG<br>
is small short term work items, which does not map well<br>
to the SR task. A new WG focused solely on SR therefore<br>
needs to be created, and this needs to be ready to meet in<br>
Vancouver.<br>
<br>
There are therefore two tasks that we need to undertake<br>
in advance of Vancouver, the first and larger task is to<br>
work on the charter. Charter proposals and discussion<br>
needs to take place on this list.  In writing the charter<br>
I think that it would be wise to ensure that as much of<br>
the work as possible is data plane agnostic. It would also<br>
be wise to, whilst ensuring the generality of technology,<br>
prioritize some of the use cases so as to keep the<br>
work and the complexity to a manageable level.<br>
<br>
As a reminder a tentative charter was posted here<br>
<a href="http://trac.tools.ietf.org/bof/trac/wiki/BofIETF87" target="_blank">http://trac.tools.ietf.org/<u></u>bof/trac/wiki/BofIETF87</a><br>
but that is very much just an initial starting point.<br>
<br>
The second task, which hopefully should be relatively easy,<br>
is to find a better working name for the WG, since it has<br>
been put to me a number of times that STATUS is going to<br>
be confusing in text and a difficult search term.<br>
<br>
- Stewart<br>
(STATUS sponsoring AD)<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
status mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/status" target="_blank">https://www.ietf.org/mailman/<u></u>listinfo/status</a><br>
</blockquote></div><br></div></div>

--e89a8ff1ca78b4252204e52eaf85--

From: Acee Lindem <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Date: Fri, 30 Aug 2013 18:27:52 +0000
Accept-Language: en-US
Cc: Alvaro Retana <[email-masked]>, "<[email-masked]>" <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

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:

> 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)
> 
> 
> 
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

Date: Fri, 30 Aug 2013 18:39:52 +0100
From: Stewart Bryant <[email-masked]>
To: [email-masked]
Cc: Alvaro Retana <[email-masked]>, "John G. Scudder" <[email-masked]>, Adrian Farrel <[email-masked]>
Subject: [Status] Summary of STATUS BOF and the next steps
Reply-To: [email-masked]

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)