Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B660611E819F for ; Sat, 31 Aug 2013 15:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W9K6RdtWGSY for ; Sat, 31 Aug 2013 15:51:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EA1F311E8166 for ; Sat, 31 Aug 2013 15:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=683; q=dns/txt; s=iport; t=1377989498; x=1379199098; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=me6epfcrpezd2iK6ZD+I616pJFGM+6UM6znZ8yqByt8=; b=VwpNUh2dt3MxneF7FO2uYtUvCi879F5/hHirt48Xp2632za1PSZpuyak /lqo1FJoeFLv8ZZlq05rMc1blrtxw2nevRl4AfTzGox4e6GAxFlNZyVso A77WFJNJGVYaUDOAy0EuOMl/t8Oftr0nqcmdv7KDMmch4he8Zxpdka9wG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFADJyIlKtJV2c/2dsb2JhbABagwc1RYJsvguBHhZ0giQBAQEDAQEBATc0CwULAgEIGB4QJwslAgQOBYd8Bgy5XgSPTDMHgx2BAAOXdZFmgyA X-IronPort-AV: E=Sophos;i="4.89,999,1367971200"; d="scan'208";a="254194665" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 31 Aug 2013 22:51:35 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7VMpY3d019172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 31 Aug 2013 22:51:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.31]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sat, 31 Aug 2013 17:51:33 -0500 From: "Roberta Maglione (robmgl)" To: "Alvaro Retana (aretana)" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOppyjTDLCbDqFuU+imabYB363rw== Date: Sat, 31 Aug 2013 22:51:33 +0000 Message-ID: <4FF0BAF2-CA67-422F-8DAB-66704C6A590A@cisco.com> References: <5220D8E8.6070508@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adrian Farrel , "status@ietf.org" , "John G. Scudder" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 22:51:42 -0000 +1 for Segment Routing WG Roberta Sent from my iPad On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" wr= ote: > Segment Routing WG >=20 > Sent from my iPhone >=20 > On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" wrote: >=20 >> 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 > status@ietf.org > https://www.ietf.org/mailman/listinfo/status Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86BA21E80E3 for ; Sat, 31 Aug 2013 11:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.038 X-Spam-Level: X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG2x+F5cygM8 for ; Sat, 31 Aug 2013 11:48:55 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 77AF121E80D8 for ; Sat, 31 Aug 2013 11:48:55 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id cm18so327080qab.13 for ; Sat, 31 Aug 2013 11:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=yMbErJ7DwRnK1voI6EyqFaErWNpexp2HTJA8XijWjjo=; b=FIasJNSsgHW/tUxswHrDNVIDA1QsbOOrEZ87NtivEDS1PRym5D7wDHMI9JAW7SfIep wI5q4r02hogVzh9IOozF7bmUMIXSK/punifKXDMvatx+WkHDwtdYk8I7g7U9Nb108sYI OvJqSrYr9F4v9Awyke1Pfyp9AgQvgDuHeI8weEHU2u5yFaB7ALvFgAdh6TDkygB5G+h+ A1CLoB3MbptkoLZA4xc3EFBsh8FoNUBE6xc1/x/RvNvq+VLKwMH6GvIEVwT9mLO8LRwg u4wzcSP80d5aBl4wWnSchDw5HkZpq1flFBN9w5xYTX2yAcIZq7zmMvlmyrA6B+Em3U2p WUQg== X-Received: by 10.224.114.11 with SMTP id c11mr19999573qaq.37.1377974931923; Sat, 31 Aug 2013 11:48:51 -0700 (PDT) Received: from [192.168.1.6] (pool-108-35-174-136.nwrknj.fios.verizon.net. [108.35.174.136]) by mx.google.com with ESMTPSA id q4sm6886453qah.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Aug 2013 11:48:50 -0700 (PDT) References: <5220D8E8.6070508@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E200C@dfweml513-mbb.china.huawei.com> <2ACFDFE4-415A-4F1F-A1AF-4F0306A3F144@cisco.com> In-Reply-To: <2ACFDFE4-415A-4F1F-A1AF-4F0306A3F144@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1975CF1B-A47E-4315-AF37-0C930BE2AF20 Message-Id: <5048B2B4-BF6D-401D-A302-9127A5BD032B@gmail.com> X-Mailer: iPhone Mail (10B146) From: Christian Martin Date: Sat, 31 Aug 2013 14:48:49 -0400 To: "Stewart Bryant (stbryant)" Cc: AshwoodsmithPeter , Anoop Ghanwani , "John G. Scudder" , Adrian Farrel , "Alvaro Retana \(aretana\)" , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 18:48:56 -0000 --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)" wrote: > I agree, m/c should be included in the charter, although I think it wound b= e a mistake to allow it to gate unicast. >=20 > S >=20 > Sent from my iPad >=20 > On 31 Aug 2013, at 00:02, "Anoop Ghanwani" wrote: >=20 >> Thanks Peter. I think it would be useful to have an explicit statement a= bout multicast in the charter, one way or another. >>=20 >> Anoop >>=20 >>=20 >> On Fri, Aug 30, 2013 at 3:00 PM, AshwoodsmithPeter wrote: >>> Most of the stateless multicast solutions are not practical except head= end replication. ie still research as far as I know.=20 >>>=20 >>> Header encodings are big of course and bloom filters suffer false positi= ves. >>>=20 >>> Peter >>>=20 >>> On Aug 30, 2013, at 5:43 PM, "Anoop Ghanwani" wr= ote: >>>=20 >>>> Is there a plan to support multicast, or is the initial effort for unic= ast only? >>>>=20 >>>> Anoop >>>>=20 >>>>=20 >>>> On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPeter wrote: >>>>> Stuart, assuming we wish to be agnostic to data paths and stealing som= e BOF intro text then something *beginning* like this? >>>>>=20 >>>>> ------------------------------- >>>>>=20 >>>>> SRV2 ( Source Routing - Version 2.0 ) >>>>>=20 >>>>> The IETF currently has two packet-based forwarding technologies capabl= e of source routing IP and MPLS. >>>>>=20 >>>>> IPv4 and IPv6 previously had source-based routing mechanisms made avai= lable through an IP Option. These mechanisms have, however, not been widely u= sed and has a number of issues that make its use inadvisable, and other mech= anisms (such as RFC 1940) do not appear to have been implemented at all. >>>>>=20 >>>>> 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 feat= ure for a number of reasons including Label Switched Path stitching, egress p= rotection, explicit routing, egress ASBR link selection, backup (bypass tunn= els, Remote Loop-Free Alternates) routing, and control performance enhanceme= nts. This can be achieved by facilitating source-initiated selection of rout= es/hops to complement the route selection provided by existing routing proto= cols for both inter-domain and intra-domain routes. The SR mechanisms can al= so be used statically or with central control. >>>>>=20 >>>>> The SRV2 working group will define a generalized SR data plane which i= s independent of existing SR capable data planes including IP options and MP= LS label stacks. The generalized SR data plane would be a superset of existi= ng SR capable data planes and be flexible in the sizing of its various field= s to ensure longevity. >>>>>=20 >>>>> The SRV2 working group will define mappings from the idealized SR data= plane to MPLS label stacks and to IP V6 SR options. >>>>>=20 >>>>> The SRV2 working group will define control/management plane extensions= in conjunction with the relevant working groups. >>>>>=20 >>>>> The control/management plane extensions will be specified in terms of t= he generalized SR data plane to ensure compatibility with future more genera= lized SR capable hardware. >>>>>=20 >>>>> The SRV2 working group will initially target control/management plane e= xtensions for >>>>> TBD ...... >>>>>=20 >>>>> ------------------------------ >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Peter >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Beha= lf Of Stewart Bryant >>>>> Sent: Friday, August 30, 2013 1:40 PM >>>>> To: status@ietf.org >>>>> Cc: Alvaro Retana; John G. Scudder; Adrian Farrel >>>>> Subject: [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>> The STATUS BOF met on 29th July and the minutes are >>>>> available here: >>>>>=20 >>>>> http://www.ietf.org/proceedings/87/minutes/minutes-87-status >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 1) There was overwhelming support for work on MPLS Source >>>>> Routing (SR), with many use cases presented. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> - Stewart >>>>> (STATUS sponsoring AD) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > 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
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)" <stbryant@cisco.com> 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" <anoop@alumni.duke.edu> 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 <Peter.AshwoodSmith@huawei.com> 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" <anoop@alumni.duke.edu> 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 <Peter.AshwoodSmith@huawei.com> 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: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, August 30, 2013 1:40 PM
To: status@ietf.org
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
status@ietf.org
https://www.ietf.org/mailman/listinfo/status
_______________________________________________
status mailing list
status@ietf.org
https://www.ietf.org/mailman/listinfo/status


_______________________________________________
status mailing list
status@ietf.org
https://www.ietf.org/mailman/listinfo/status
--Apple-Mail-1975CF1B-A47E-4315-AF37-0C930BE2AF20-- Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E612621E80D5 for ; Sat, 31 Aug 2013 11:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.978 X-Spam-Level: X-Spam-Status: No, score=-109.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkWU31zBakmV for ; Sat, 31 Aug 2013 11:33:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B941521E809A for ; Sat, 31 Aug 2013 11:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15491; q=dns/txt; s=iport; t=1377973982; x=1379183582; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GjJaO10DcDbMa49y0h4Jmc0UsV7dJvkc4QeU6anWCEY=; b=dzqr0pqyVzZDa0pmNRM2mFuu30MX3T+zhrB+0VG7ZjExva75kWeGGenw aIcH0JQp8QalhPFJYKdVE3SLyMO/5kRZFi+gmUIFGl3fURC5CHTgTwZRE z5qc2jFjvPA1wSm0xpvcrF9jehpx9R8IkwlGOJKB2GPYDvELTs88fBi/h s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAD02IlKtJXG8/2dsb2JhbABaDoJ5NbhxiEuBHhZ0giQBAQEEAQEBawsMBAIBCBEEAQEoBycLFAkIAgQOBQkSh2cMuXGOLYEnJwQHBoMXgQADl3WBL5A3gmE/ X-IronPort-AV: E=Sophos;i="4.89,998,1367971200"; d="scan'208,217";a="254172188" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 31 Aug 2013 18:33:02 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7VIX23v026434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 31 Aug 2013 18:33:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.201]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sat, 31 Aug 2013 13:33:01 -0500 From: "Stewart Bryant (stbryant)" To: Anoop Ghanwani Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpagR8kslgYCLCUGB6LpPx3C/KpmuGvOAgACBXgCAAATYAIAAEWKAgADzL2s= Date: Sat, 31 Aug 2013 18:33:00 +0000 Message-ID: <2ACFDFE4-415A-4F1F-A1AF-4F0306A3F144@cisco.com> References: <5220D8E8.6070508@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E200C@dfweml513-mbb.china.huawei.com> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2ACFDFE4415A4F1FA1AF4F0306A3F144ciscocom_" MIME-Version: 1.0 Cc: "Alvaro Retana \(aretana\)" , Adrian Farrel , "status@ietf.org" , "John G. Scudder" , AshwoodsmithPeter Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 18:33:08 -0000 --_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 b= e a mistake to allow it to gate unicast. S Sent from my iPad On 31 Aug 2013, at 00:02, "Anoop Ghanwani" > wrote: Thanks Peter. I think it would be useful to have an explicit statement abo= ut multicast in the charter, one way or another. Anoop On Fri, Aug 30, 2013 at 3:00 PM, AshwoodsmithPeter > wrote: Most of the stateless multicast solutions are not practical except head en= d 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" > 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 > 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 mechan= isms (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 i= ndividual packet or all the packets of a given flow is a desirable feature = for a number of reasons including Label Switched Path stitching, egress pro= tection, explicit routing, egress ASBR link selection, backup (bypass tunne= ls, Remote Loop-Free Alternates) routing, and control performance enhanceme= nts. This can be achieved by facilitating source-initiated selection of rou= tes/hops to complement the route selection provided by existing routing pro= tocols 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 ind= ependent of existing SR capable data planes including IP options and MPLS l= abel 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 plan= e to MPLS label stacks and to IP V6 SR options. The SRV2 working group will define control/management plane extensions in c= onjunction with the relevant working groups. The control/management plane extensions will be specified in terms of the g= eneralized SR data plane to ensure compatibility with future more generaliz= ed SR capable hardware. The SRV2 working group will initially target control/management plane exten= sions for TBD ...... ------------------------------ Cheers, Peter -----Original Message----- From: status-bounces@ietf.org [mailto:statu= s-bounces@ietf.org] On Behalf Of Stewart Br= yant Sent: Friday, August 30, 2013 1:40 PM To: status@ietf.org 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 status@ietf.org https://www.ietf.org/mailman/listinfo/status _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status --_000_2ACFDFE4415A4F1FA1AF4F0306A3F144ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree, m/c should be included in the charter, although I think it wo= und be a mistake to allow it to gate unicast.

S

Sent from my iPad

On 31 Aug 2013, at 00:02, "Anoop Ghanwani" <anoop@alumni.duke.edu> 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, AshwoodsmithPet= er <Pete= r.AshwoodSmith@huawei.com> wrote:
Most of the stateless multicast solutions  are not practical exce= pt head end replication. ie still research as far as I know. 

Header encodings are big of course and bloom filters suffer false posi= tives.

Peter

On Aug 30, 2013, at 5:43 PM, "Anoop Ghanwani" <anoop@alumni.duke.edu> w= rote:

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

Anoop


On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPet= er <Pete= r.AshwoodSmith@huawei.com> 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 mechan= isms (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 i= ndividual packet or all the packets of a given flow is a desirable feature = for a number of reasons including Label Switched Path stitching, egress pro= tection, explicit routing, egress ASBR link selection, backup (bypass tunnels, Remote Loop-Free Alternates) = routing, and control performance enhancements. This can be achieved by faci= litating 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 ind= ependent of existing SR capable data planes including IP options and MPLS l= abel 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 plan= e to MPLS label stacks and to IP V6 SR options.

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

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

The SRV2 working group will initially target control/management plane exten= sions for
     TBD ......

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

Cheers,

Peter



-----Original Message-----
From: status-b= ounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, August 30, 2013 1:40 PM
To: status@ietf.org
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-statu= s

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
status@ietf.org = https://www.ietf.org/mailman/listinfo/status
_______________________________________________
status mailing list
status@ietf.org = https://www.ietf.org/mailman/listinfo/status


--_000_2ACFDFE4415A4F1FA1AF4F0306A3F144ciscocom_-- Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1736521E8053 for ; Fri, 30 Aug 2013 16:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEgmkGAHFKxv for ; Fri, 30 Aug 2013 16:02:38 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4092E21E8050 for ; Fri, 30 Aug 2013 16:02:38 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b12so101424wgh.2 for ; Fri, 30 Aug 2013 16:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kzz2dz94FvuOOIiZLZeH8qalsZHRF0IqeI9NNfQiouA=; b=Os+aPkBRFCQAItf0Mtw57Ce+DfBqOCPB4+Uhqkq6ozLEKKPWSOB/zIZk/TlFc8Sy3P vCragCVBRfvOuc5CFtdfKLEDYba03AGnYJhKp1ueq/4q7wUGk+Gfmu9B+eX81GkCz3sC rNQGevpGIUZYPrAEXVEAcPLTRcJJhqPnuqXG3oT3dbbnNPTyH/otPbZdnEO4iFp+Li1K SHS/QK7uZlwD/Z34leP5jWxj4yi2JhCg2LBN16w3XKn6xb4S8v4CxIKGn62SuBR9l1TU 0NFx873dQAtkg/G/QA64M0OPqRQg2SctpQ5q7wWDsq7E5/qCa/xdJ6Tp1r79bnBXSkdv i41w== MIME-Version: 1.0 X-Received: by 10.180.75.16 with SMTP id y16mr4286928wiv.59.1377903757370; Fri, 30 Aug 2013 16:02:37 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.64.67 with HTTP; Fri, 30 Aug 2013 16:02:37 -0700 (PDT) In-Reply-To: References: <5220D8E8.6070508@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E200C@dfweml513-mbb.china.huawei.com> Date: Fri, 30 Aug 2013 16:02:37 -0700 X-Google-Sender-Auth: 8pXvc190aetwizUpqAQJ4YaQGe8 Message-ID: From: Anoop Ghanwani To: AshwoodsmithPeter Content-Type: multipart/alternative; boundary=f46d043c7d22fe2bf804e5323740 Cc: Alvaro Retana , Adrian Farrel , "status@ietf.org" , "John G. Scudder" , "stbryant@cisco.com" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 23:02:40 -0000 --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 < Peter.AshwoodSmith@huawei.com> 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" > 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 < > Peter.AshwoodSmith@huawei.com> 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: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf >> Of Stewart Bryant >> Sent: Friday, August 30, 2013 1:40 PM >> To: status@ietf.org >> 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 >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> > > --f46d043c7d22fe2bf804e5323740 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Peter. =A0I think it would be useful to have an exp= licit statement about multicast in the charter, one way or another.
Anoop


On Fri, Aug 30, 2013 at 3:00 PM, AshwoodsmithPeter <Peter.Ashw= oodSmith@huawei.com> wrote:
Most of the stateless multicast solutions =A0are not practical except = head end replication. ie still research as far as I know.=A0

Header encodings are big of course and bloom filters suffer false posi= tives.

Peter

On Aug 30, 2013, at 5:43 PM, "Anoop Ghanwani" <anoop@alumni.duke.edu> w= rote:

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

Anoop


On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPet= er <Pete= r.AshwoodSmith@huawei.com> 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 mechan= isms (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 i= ndividual packet or all the packets of a given flow is a desirable feature = for a number of reasons including Label Switched Path stitching, egress pro= tection, explicit routing, egress ASBR link selection, backup (bypass tunnels, Remote Loop-Free Alternates) = routing, and control performance enhancements. This can be achieved by faci= litating 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 ind= ependent of existing SR capable data planes including IP options and MPLS l= abel 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 plan= e to MPLS label stacks and to IP V6 SR options.

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

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

The SRV2 working group will initially target control/management plane exten= sions for
=A0 =A0 =A0TBD ......

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

Cheers,

Peter



-----Original Message-----
From: status-b= ounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Friday, August 30, 2013 1:40 PM
To: status@ietf.org
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-statu= s

Following the BOF I discussed the outcome with the I*
and with Adrian, and I =A0present 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. =A0This
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 =A0central
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. =A0In 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
status@ietf.org = https://www.ietf.org/mailman/listinfo/status
_______________________________________________
status mailing list
status@ietf.org = https://www.ietf.org/mailman/listinfo/status


--f46d043c7d22fe2bf804e5323740-- Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D872121F9D8D for ; Fri, 30 Aug 2013 15:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwECMIppohev for ; Fri, 30 Aug 2013 15:00:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0F021F99B8 for ; Fri, 30 Aug 2013 15:00:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUX22986; Fri, 30 Aug 2013 22:00:29 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 30 Aug 2013 23:00:27 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 30 Aug 2013 23:00:29 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.219]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Fri, 30 Aug 2013 15:00:24 -0700 From: AshwoodsmithPeter To: Anoop Ghanwani Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpagRotKJfq4IsUG7NNIGBBc3kJmuGvOAgACi5QD//4+ATQ== Date: Fri, 30 Aug 2013 22:00:24 +0000 Message-ID: References: <5220D8E8.6070508@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E200C@dfweml513-mbb.china.huawei.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A4847FB5AB8142E7AAF48C561E67C308huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Alvaro Retana , Adrian Farrel , "status@ietf.org" , "John G. Scudder" , "stbryant@cisco.com" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 22:00:39 -0000 --_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 en= d 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" > 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 > 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 mechan= isms (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 i= ndividual packet or all the packets of a given flow is a desirable feature = for a number of reasons including Label Switched Path stitching, egress pro= tection, explicit routing, egress ASBR link selection, backup (bypass tunne= ls, Remote Loop-Free Alternates) routing, and control performance enhanceme= nts. This can be achieved by facilitating source-initiated selection of rou= tes/hops to complement the route selection provided by existing routing pro= tocols 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 ind= ependent of existing SR capable data planes including IP options and MPLS l= abel 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 plan= e to MPLS label stacks and to IP V6 SR options. The SRV2 working group will define control/management plane extensions in c= onjunction with the relevant working groups. The control/management plane extensions will be specified in terms of the g= eneralized SR data plane to ensure compatibility with future more generaliz= ed SR capable hardware. The SRV2 working group will initially target control/management plane exten= sions for TBD ...... ------------------------------ Cheers, Peter -----Original Message----- From: status-bounces@ietf.org [mailto:statu= s-bounces@ietf.org] On Behalf Of Stewart Br= yant Sent: Friday, August 30, 2013 1:40 PM To: status@ietf.org 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 status@ietf.org https://www.ietf.org/mailman/listinfo/status _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status --_000_A4847FB5AB8142E7AAF48C561E67C308huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Most of the stateless multicast solutions  are not practical exce= pt head end replication. ie still research as far as I know. 

Header encodings are big of course and bloom filters suffer false posi= tives.

Peter

On Aug 30, 2013, at 5:43 PM, "Anoop Ghanwani" <anoop@alumni.duke.edu> wrote:

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

Anoop


On Fri, Aug 30, 2013 at 2:36 PM, AshwoodsmithPet= er <Pete= r.AshwoodSmith@huawei.com> 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 mechan= isms (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 i= ndividual packet or all the packets of a given flow is a desirable feature = for a number of reasons including Label Switched Path stitching, egress pro= tection, explicit routing, egress ASBR link selection, backup (bypass tunnels, Remote Loop-Free Alternates) = routing, and control performance enhancements. This can be achieved by faci= litating 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 ind= ependent of existing SR capable data planes including IP options and MPLS l= abel 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 plan= e to MPLS label stacks and to IP V6 SR options.

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

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

The SRV2 working group will initially target control/management plane exten= sions for
     TBD ......

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

Cheers,

Peter



-----Original Message-----
From: status-bounces@ietf.org [mailto:status-bounces@ietf.or= g] On Behalf Of Stewart Bryant
Sent: Friday, August 30, 2013 1:40 PM
To: status@ietf.org
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-statu= s

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
status@ietf.org
= https://www.ietf.org/mailman/listinfo/status
_______________________________________________
status mailing list
status@ietf.org
= https://www.ietf.org/mailman/listinfo/status

--_000_A4847FB5AB8142E7AAF48C561E67C308huaweicom_-- Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5004F21F9F0A for ; Fri, 30 Aug 2013 14:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.357 X-Spam-Level: X-Spam-Status: No, score=-1.357 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3IXE8Tw8Ybg for ; Fri, 30 Aug 2013 14:43:07 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DEC1221F9D42 for ; Fri, 30 Aug 2013 14:43:05 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w60so2090437wes.29 for ; Fri, 30 Aug 2013 14:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=L3DFpe65Yfm2UL0ajj4mSH6A3XtbtIFCi/nVNncwBsM=; b=oapfNwBVxjTMp0w6sm7Ycs53dgx8oUVKq9EQdBL7GVco54FlnUifLbVmEKT7p8VIKK q7Ae3/k7t+KC7bTDQiGl/MzqXwlP0LO6gzY8s8iDjWz5Vkmin7VXTzXdwyFcNoPwKZwP /LllynG2reDF36jenSleG794ljcMm1/o8MT13Y+WbcgweJUU9umuP+UjBfW6cii5tDcX qfdcdlb/8Zr+vJ4e3RDWNoGbW8v76b0rPptF2RN9U7SQD9ZTRybGUN0aQrV+M42wKZnR zAot4nj0T/LG+q8z+1krYs1L2SoUCAtztIIEEfdbnMhcVfqHJGSw6EvOlJuDB/sLx27E Y4rA== MIME-Version: 1.0 X-Received: by 10.180.77.80 with SMTP id q16mr4119136wiw.17.1377898984972; Fri, 30 Aug 2013 14:43:04 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.64.67 with HTTP; Fri, 30 Aug 2013 14:43:04 -0700 (PDT) In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E200C@dfweml513-mbb.china.huawei.com> References: <5220D8E8.6070508@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E200C@dfweml513-mbb.china.huawei.com> Date: Fri, 30 Aug 2013 14:43:04 -0700 X-Google-Sender-Auth: iuaogmUykmUwFzI7wPKa2cXwyuM Message-ID: From: Anoop Ghanwani To: AshwoodsmithPeter Content-Type: multipart/alternative; boundary=f46d0438906d892abe04e5311b25 Cc: Alvaro Retana , Adrian Farrel , "status@ietf.org" , "John G. Scudder" , "stbryant@cisco.com" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 21:43:08 -0000 --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 < Peter.AshwoodSmith@huawei.com> 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: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf > Of Stewart Bryant > Sent: Friday, August 30, 2013 1:40 PM > To: status@ietf.org > 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 > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > --f46d0438906d892abe04e5311b25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is there a plan to support multicast, or is the initial ef= fort for unicast only?

Anoop


On Fri, Aug 30, 2013 at 2:36 = PM, AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com> wrote:
Stuart, assuming we wish to be agnostic to d= ata 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 mechan= isms (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 i= ndividual packet or all the packets of a given flow is a desirable feature = for a number of reasons including Label Switched Path stitching, egress pro= tection, explicit routing, egress ASBR link selection, backup (bypass tunne= ls, Remote Loop-Free Alternates) routing, and control performance enhanceme= nts. This can be achieved by facilitating source-initiated selection of rou= tes/hops to complement the route selection provided by existing routing pro= tocols 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 ind= ependent of existing SR capable data planes including IP options and MPLS l= abel 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 plan= e to MPLS label stacks and to IP V6 SR options.

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

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

The SRV2 working group will initially target control/management plane exten= sions for
=A0 =A0 =A0TBD ......

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

Cheers,

Peter



-----Original Message-----
From: status-bounces@ietf.org [mailto:status-bounces@ietf.or= g] On Behalf Of Stewart Bryant
Sent: Friday, August 30, 2013 1:40 PM
To: status@ietf.org
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-statu= s

Following the BOF I discussed the outcome with the I*
and with Adrian, and I =A0present 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. =A0This
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 =A0central
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. =A0In 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
status@ietf.org
= https://www.ietf.org/mailman/listinfo/status
_______________________________________________
status mailing list
status@ietf.org
= https://www.ietf.org/mailman/listinfo/status

--f46d0438906d892abe04e5311b25-- Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5C021F9E91 for ; Fri, 30 Aug 2013 14:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1roBllOLFzn for ; Fri, 30 Aug 2013 14:36:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8099C21F9E8B for ; Fri, 30 Aug 2013 14:36:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUX22111; Fri, 30 Aug 2013 21:36:18 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 30 Aug 2013 22:36:14 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 30 Aug 2013 22:36:16 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.219]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Fri, 30 Aug 2013 14:36:10 -0700 From: AshwoodsmithPeter To: "stbryant@cisco.com" , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpagRotKJfq4IsUG7NNIGBBc3kJmuGvOA Date: Fri, 30 Aug 2013 21:36:10 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E200C@dfweml513-mbb.china.huawei.com> References: <5220D8E8.6070508@cisco.com> In-Reply-To: <5220D8E8.6070508@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Alvaro Retana , "John G. Scudder" , Adrian Farrel Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 21:36:26 -0000 Stuart, assuming we wish to be agnostic to data paths and stealing some BOF= intro text then something *beginning* like this? ------------------------------- SRV2 ( Source Routing - Version 2.0 ) The IETF currently has two packet-based forwarding technologies capable of = source routing IP and MPLS. IPv4 and IPv6 previously had source-based routing mechanisms made available= through an IP Option. These mechanisms have, however, not been widely used= and has a number of issues that make its use inadvisable, and other mechan= isms (such as RFC 1940) do not appear to have been implemented at all.=20 The ability of a device to influence or control the forwarding path of an i= ndividual packet or all the packets of a given flow is a desirable feature = for a number of reasons including Label Switched Path stitching, egress pro= tection, explicit routing, egress ASBR link selection, backup (bypass tunne= ls, Remote Loop-Free Alternates) routing, and control performance enhanceme= nts. This can be achieved by facilitating source-initiated selection of rou= tes/hops to complement the route selection provided by existing routing pro= tocols 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 ind= ependent of existing SR capable data planes including IP options and MPLS l= abel 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 plan= e to MPLS label stacks and to IP V6 SR options. The SRV2 working group will define control/management plane extensions in c= onjunction with the relevant working groups.=20 The control/management plane extensions will be specified in terms of the g= eneralized SR data plane to ensure compatibility with future more generaliz= ed SR capable hardware.=20 The SRV2 working group will initially target control/management plane exten= sions for=20 TBD ...... ------------------------------ Cheers, Peter -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Friday, August 30, 2013 1:40 PM To: status@ietf.org 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 status@ietf.org https://www.ietf.org/mailman/listinfo/status Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A1421F9E83 for ; Fri, 30 Aug 2013 14:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKPR+hF2gTuy for ; Fri, 30 Aug 2013 14:26:57 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7F05E21F9E6A for ; Fri, 30 Aug 2013 14:26:56 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-b9-52210e1925c4 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 36.6A.09414.91E01225; Fri, 30 Aug 2013 23:26:50 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Fri, 30 Aug 2013 17:26:31 -0400 From: Jeff Tantsura To: "Santiago Alvarez (saalvare)" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpceX/DA3iHCYu0aUo038OOsVYA== Date: Fri, 30 Aug 2013 21:26:30 +0000 Message-ID: <553F5DA7-50DC-4E76-A2EC-57DC0793A80B@ericsson.com> References: <5220D8E8.6070508@cisco.com> , <0C8935EE66D53445A3D3982BD9BE54681F26A140@xmb-aln-x09.cisco.com> In-Reply-To: <0C8935EE66D53445A3D3982BD9BE54681F26A140@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPiK4Un2KQwYb5fBY/em4wW/z9uZXR YuP/HewWs+cbWbxuvshkce7pHEYHNo8l3e+ZPKb83sjqsWTJTyaPFZtXMgawRHHZpKTmZJal FunbJXBlzD7/nrVgPmdFz+4LbA2MF9m7GDk5JARMJKZcf8AKYYtJXLi3nq2LkYtDSOAoo8SL mdcZuxg5gJzljBJ79EBq2AQMJP5/O84CYosImElcu/ifFaSeWaCdSeLq/MVsIAlhATuJni+X mCCK7CXOn70HZetJTOudxgoyk0VAVWJTYxFImBeo5OOBxawQe+cwSpz91ge2gFPAV2L73s/M IDYj0HHfT60Bm8MsIC5x68l8JoijBSSW7DnPDGGLSrx8/I8VokZHYsHuT2wQtrbEsoWvmSGW CUqcnPmEZQKj6Cwko2YhaZmFpGUWkpYFjCyrGDlKi1PLctONDDYxAuPomASb7g7GPS8tDzFK c7AoifOu0jsTKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRfts240jm1v89y+YzTPhpOb2B zyvR0vkY98pC5rXz94VzSErL5Np7ppepH3o3sUAoij/dMkQyMn5zcdAm5ptWP/O9V893nciR /Opv/fO7dj8mOVc/jnpyfab03CM1t8sMOczesd6XKfVweCG80UJScsP1BSsVjsn6brnoXt20 duUx+/kyBq+VWIozEg21mIuKEwEyK03/cQIAAA== Cc: "Santiago Alvarez \(saalvare\)" , "John G. Scudder" , Adrian Farrel , "Alvaro Retana \(aretana\)" , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 21:27:03 -0000 Same here Regards, Jeff On Aug 30, 2013, at 11:25 PM, "Santiago Alvarez (saalvare)" wrote: > +1 >=20 >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >> Behalf Of Alvaro Retana (aretana) >> Sent: Friday, August 30, 2013 11:54 AM >> To: Stewart Bryant (stbryant) >> Cc: Adrian Farrel; status@ietf.org; John G. Scudder >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>=20 >> Segment Routing WG >>=20 >> Sent from my iPhone >>=20 >> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >> wrote: >>=20 >>> 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 >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A47221F8FF5 for ; Fri, 30 Aug 2013 14:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-9eNAu+0uGI for ; Fri, 30 Aug 2013 14:25:28 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 08E0C21F997B for ; Fri, 30 Aug 2013 14:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=890; q=dns/txt; s=iport; t=1377897928; x=1379107528; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=smVindXCj5X8hdn+I7/drY9hvlOR3b+OoPA4hf4g5tI=; b=S8OYEjc0OBZI3taznqOVp2+sn0VEpF4KF3kUlyOUBwSz37qNTio+IhH6 ALSa11oOkjsl5zncBommm3fqvYWunF56Uzm9IezOASSolf2gNaK0fo4Dk OULVw66YVDC0pIav2x9T965NqRuFLO18MpkDzuZXE2nf+xICfI+RMEpaS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAM4MIVKtJV2b/2dsb2JhbABagwc1RQyCYL4EgR8WdIIkAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiHeQy6IwSPPTEHBoMWgQADqVuDIIIq X-IronPort-AV: E=Sophos;i="4.89,993,1367971200"; d="scan'208";a="253920240" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 30 Aug 2013 21:25:27 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7ULPR7j002643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Aug 2013 21:25:27 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.11]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 30 Aug 2013 16:25:26 -0500 From: "Santiago Alvarez (saalvare)" To: "Alvaro Retana (aretana)" , "Stewart Bryant (stbryant)" Thread-Topic: Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJustdKs1xusUai9Qvo2+MEQpmuQ3KA Date: Fri, 30 Aug 2013 21:25:26 +0000 Message-ID: <0C8935EE66D53445A3D3982BD9BE54681F26A140@xmb-aln-x09.cisco.com> References: <5220D8E8.6070508@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adrian Farrel , "status@ietf.org" , "John G. Scudder" , "Santiago Alvarez \(saalvare\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 21:25:36 -0000 +1 > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On > Behalf Of Alvaro Retana (aretana) > Sent: Friday, August 30, 2013 11:54 AM > To: Stewart Bryant (stbryant) > Cc: Adrian Farrel; status@ietf.org; John G. Scudder > Subject: Re: [Status] Summary of STATUS BOF and the next steps >=20 > Segment Routing WG >=20 > Sent from my iPhone >=20 > On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" > wrote: >=20 > > 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 > status@ietf.org > https://www.ietf.org/mailman/listinfo/status Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC9E11E8111 for ; Fri, 30 Aug 2013 11:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUh1fMxQ8OqR for ; Fri, 30 Aug 2013 11:54:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5D73821F9E00 for ; Fri, 30 Aug 2013 11:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=373; q=dns/txt; s=iport; t=1377888858; x=1379098458; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LD+N/EK+paT9uLe1Pd+C525JaYoo+pp/UqIm5stIPXw=; b=I26uHt32CoR/i1a5vr/Bl25BIasRrGxnrWTeA8vIx8JvIU3Tc9RztFlq tZdYukqgijyjdXSgiIlufhjm5SAPcFZdTKeEkPx5kb+SeWjJD3/CasB58 M9ZL8aTr8vmQjoSYIjL6tFEA4G/lqPB1VGapoDK791COTOxQFJIOX1XN6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAN/pIFKtJV2a/2dsb2JhbABagwd6gmy9foEeFnSCJAEBAQMBOj8FCwIBCDYQMiUCBA4Fh3sGuhyPOzMHgxyBAAOXdZFmgyA X-IronPort-AV: E=Sophos;i="4.89,992,1367971200"; d="scan'208";a="253839386" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 30 Aug 2013 18:54:18 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7UIsH7N027218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Aug 2013 18:54:17 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.182]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 30 Aug 2013 13:54:17 -0500 From: "Alvaro Retana (aretana)" To: "Stewart Bryant (stbryant)" Thread-Topic: Summary of STATUS BOF and the next steps Thread-Index: AQHOpafy8kslgYCLCUGB6LpPx3C/KpmuGVgy Date: Fri, 30 Aug 2013 18:54:17 +0000 Message-ID: References: <5220D8E8.6070508@cisco.com> In-Reply-To: <5220D8E8.6070508@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adrian Farrel , "status@ietf.org" , "John G. Scudder" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 18:54:32 -0000 Segment Routing WG Sent from my iPhone On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" 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. Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C693B21F9FF9 for ; Fri, 30 Aug 2013 11:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.929 X-Spam-Level: X-Spam-Status: No, score=0.929 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjw85cTJRS92 for ; Fri, 30 Aug 2013 11:49:47 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4AC21E805F for ; Fri, 30 Aug 2013 11:49:46 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so2208329pdj.26 for ; Fri, 30 Aug 2013 11:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=M5/p2i3qexlLazYbNIDI62WJd3OWHD3PVDWPJyaRBqk=; b=GUtTkt7/sy1DPefhrkJpCSN34HaG+t5/JKaMGQAAqt4E4Xedq1eZ0W7mFNez1gZ5TH jlpYu+XIwk/ky2aW3M3TMqbSMwH9bex7L/gV1G1+peBQ0MFzQLvcBkcuAZTkFNTIy5uw 7bMiSW0EetT1yc8OpOkkN7k+pE5/OWex6xzAi1diYS9e1YGA9H2O4NrfUk7Q4ucVntVp lKknPG5kJHrRdn5qZ+DB2n3hcLsecstWM9EExLJdh/M0kfKkhrjZhl3xqG0iT1v7SuBi tjuiPSxtAdbV7XbwMn+cK0pjrkZET8L54RV0+vOKZ1SMnGiErTxqCuz5QKY/hFSMwp0x 9+jw== X-Received: by 10.68.220.1 with SMTP id ps1mr11656868pbc.30.1377888585915; Fri, 30 Aug 2013 11:49:45 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.13.129 with HTTP; Fri, 30 Aug 2013 11:49:15 -0700 (PDT) In-Reply-To: <5220D8E8.6070508@cisco.com> References: <5220D8E8.6070508@cisco.com> From: Sriganesh Kini Date: Fri, 30 Aug 2013 11:49:15 -0700 X-Google-Sender-Auth: UBIm7UvJW5RJJCeIFeg0CVBOSWI Message-ID: To: "Stewart Bryant (stbryant)" Content-Type: multipart/alternative; boundary=e89a8ff1ca78b4252204e52eaf85 Cc: Alvaro Retana , "status@ietf.org" , "John G. Scudder" , Adrian Farrel Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 18:49:47 -0000 --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 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 > status@ietf.org > https://www.ietf.org/mailman/**listinfo/status > --e89a8ff1ca78b4252204e52eaf85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would suggest the name SORT - SOurce Routed Tunnels= .

- Sri



On Fri, Aug 30, 2013 at 10:39 AM, Stewart Bryant <stbrya= nt@cisco.com> wrote:
The STATUS BOF met on 29th July and the minu= tes are
available here:

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

Following the BOF I discussed the outcome with the I*
and with Adrian, and I =C2=A0present 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. =C2=A0This
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 =C2=A0central
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. =C2=A0In 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
status@ietf.org = https://www.ietf.org/mailman/listinfo/status

--e89a8ff1ca78b4252204e52eaf85-- Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC1811E8114 for ; Fri, 30 Aug 2013 11:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1WoPNHQn4ko for ; Fri, 30 Aug 2013 11:27:58 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C271311E810E for ; Fri, 30 Aug 2013 11:27:58 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-c7-5220e42d1c8f Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 26.AC.03458.D24E0225; Fri, 30 Aug 2013 20:27:58 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Fri, 30 Aug 2013 14:27:53 -0400 From: Acee Lindem To: "" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpagMSTgdDM0LuESOJSCrgW/p0pmuVQQA Date: Fri, 30 Aug 2013 18:27:52 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4703038B6A@eusaamb101.ericsson.se> References: <5220D8E8.6070508@cisco.com> In-Reply-To: <5220D8E8.6070508@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <4194550DBF734D419EDA743544066BB1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXSPt67eE4Ugg0UXuS1+9Nxgtvj7cyuj xcb/O9gtXjdfZLI493QOowOrx5Lu90weU35vBLKW/GTyWLF5JWMASxSXTUpqTmZZapG+XQJX RuuzV8wFL8Qqdl69z9TA2C/UxcjJISFgIrHn/iVGCFtM4sK99WxdjFwcQgJHGSVmN35kBUkI CSxnlDg5VQPEZhPQkXj+6B8ziC0ioC9x5MNOZpAGZoHJjBK3jmxjAkkIC9hJ9Hy5xARRZC9x /uw9KNtI4uuS52BDWQRUJaZ8nMkCYvMK+Erced7HDrFMQ+LmtjYwm1NAU+Lm15tg1zECXff9 1BqwOcwC4hK3nsxngrhaQGLJnvPMELaoxMvH/1ghbGWJJU/2s0DU60gs2P2JDcK2ltjy5ReU rS2xbOFrZogbBCVOznzCMoFRfBaSFbOQtM9C0j4LSfssJO0LGFlXMXKUFqeW5aYbGW5iBEbi MQk2xx2MCz5ZHmKU5mBREufdoHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMjz+kd95Qj 5B6kzNnc6eg+RfYZh9yrkCPhEWtO/tCcMHGegH3bjlvrFiw5mzOD3+5V/TJ2j8h5MU+Uwv3c Lp7M08/dcYx189ZHTw1iZlVfsu8949bMuIpH7eK+VxmXJf+9jdh+rOjOl+w5gSEuHstSE01e Tda5Y/fyTdIcH/fFHEsiw149tr5srMRSnJFoqMVcVJwIAN5xGSuSAgAA Cc: Alvaro Retana , "" , "John G. Scudder" , Adrian Farrel Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 18:28:10 -0000 We can call the new WG - Dynamic Internet Source Routing Using Perverse Tun= neling (DISRUPT).=20 The "Perverse" is assuming a new IPv6 source routing header...=20 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: >=20 > http://www.ietf.org/proceedings/87/minutes/minutes-87-status >=20 > 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. >=20 > 1) There was overwhelming support for work on MPLS Source > Routing (SR), with many use cases presented. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > - Stewart > (STATUS sponsoring AD) >=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D16B21F99BF for ; Fri, 30 Aug 2013 10:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.979 X-Spam-Level: X-Spam-Status: No, score=-109.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4qF++Z30dxO for ; Fri, 30 Aug 2013 10:40:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E837421F9E04 for ; Fri, 30 Aug 2013 10:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2394; q=dns/txt; s=iport; t=1377884397; x=1379093997; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=eTsWY0ii3QwAsKgjPO+BshRFFL9uQFZQIojz4F637ZE=; b=aiAQZ12L+QPAXc+hAWTjdgBW/gJdPdTn+nfVAfS+B+WmYrbN0EoY2Al+ iPEua8Wfw8V6DMhyBwWc0dXZfzrX9qNKON4Ok/iWPw5hCZ8Y8WqXpTo4B Nptl6lGWGcTo6BPzi4lTIp4DxonQn2qFFK82GA+8bGyh+bm1Oc+kE3/48 0=; X-IronPort-AV: E=Sophos;i="4.89,992,1367971200"; d="scan'208";a="159087105" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2013 17:39:55 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7UHdr2X024094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 17:39:54 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r7UHdqQV000154; Fri, 30 Aug 2013 18:39:52 +0100 (BST) Message-ID: <5220D8E8.6070508@cisco.com> Date: Fri, 30 Aug 2013 18:39:52 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: status@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alvaro Retana , "John G. Scudder" , Adrian Farrel Subject: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 17:40:36 -0000 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)