Subject: [Status] Updated Merged Charter.

From: Rob Shakir <[email-masked]>
Date: Thu, 12 Sep 2013 22:11:49 +0100

Hi STATUS, Hannes, Stefano,

Following some discussion with Stephane, I tried to consolidate the wording from the various threads into one charter proposal, which can be found below this message.

I would specifically draw your attention to the following paragraph:

> The <Name-TBD> architecture has been postulated to be applicable to multiple data planes (e.g., MPLS, 
> IPv6), and hence the working group should strive to create a single <Name-TBD> framework which 
> maintains data plane independence where possible. Where use cases are documented, care should be taken 
> to define the data plane requirements for the environment within which they are to be implemented. The > <Name-TBD> architecture should avoid modifications to the MPLS data-plane, in order to remain 
> compatible with existing extensive deployments of MPLS.

There are of course a number of different opinions relating to the network deployments in which different operators would like to deploy the technology that will be developed by this effort. In my humble opinion, the debates as to the exact requirements can (and should) be done in the working group as we develop on the use cases. I have therefore tried to make sure that the wording in the charter does not pre-judge the result of such debates, but does not close the door on them in the future (should consensus exist to work on them). I believe this also captures the points relating to data-planes that the ADs noted in the evaluation of the BoF.

Your feedback on this proposal would be very much appreciated (and thanks to Stephane for his initial proposal and help with this)!

Kind regards,
r.

Name: <TBD>

A number of use cases, including:
    o Path computation based on awareness of utilisation or performance
      data, within both centralised and distributed environments,
    o Multi-topology routing (dual planes, disjoint trees),
    o Simplification and reduction of signalling,
    o Combined application and network-layer path specification.
    o Full coverage LFA FRR,
    o Topology Aware OAM,  
have triggered work on the definition of a new architecture and protocol extensions, allowing nodes to steer packets through a network, allowing combination of well-known shortest-path based routing paradigms with source or explicit routing methods. Some of the extensions allowing steering of packets in this manner have already been implemented.

The <Name-TBD> working group will define an architecture allowing a node to steer a packet through a network, or set of networks, on any path without requiring state to be maintained by transited nodes (but rather at the source device). The source node may send any packet along a path within the <Name-TBD> domain through specifying the identifiers referring to this path. Subsequent downstream nodes along the path within the <Name-TBD> domain will forward packets according to the instructions inserted by the head-end.

Within the <Name-TBD> architecture, a node may be of any type - including routers and appliances. A set of such nodes sharing a common trust model form a <Name-TBD> domain. The architecture defined by this working group will allow steering of packets between any source and destination node within the <Name-TBD> domain, which may be formed of one or more networks, on any path (shortest, non-shortest, explicit, or based on other resources or characteristics specified by segment identifiers).

The <Name-TBD> architecture should support both centralised and distributed path computation - through both existing routing protocols (IGP, BGP) and new approaches to such path calculation. The architecture should also support OAM functions.

The <Name-TBD> architecture has been postulated to be applicable to multiple data planes (e.g., MPLS, IPv6), and hence the working group should strive to create a single <Name-TBD> framework which maintains data plane independence where possible. Where use cases are documented, care should be taken to define the data plane requirements for the environment within which they are to be implemented. The <Name-TBD> architecture should avoid modifications to the MPLS data-plane, in order to remain compatible with existing extensive deployments of MPLS.

The <Name-TBD> working group is chartered for the following (ordered) list of items:
    o Identification of use-cases for the <Name-TBD> architecture for which
      there is consensus within the WG.
    o Definition of an architectural framework, which must cover
      security considerations (including the relationship between networks
      forming the <Name-TBD> domain).
    o Having identified use-cases, and developed a framework, the WG will
      identify gaps in currently available technologies, and define
      requirements for extensions or new functionality that is required.
    o The <Name-TBD> working group will then develop solutions - focusing 
      initially on intra-domain forwarding implementations. Where such
      solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this will
      be done in conjunction with the responsible IETF working group. Work
      on new protocols may be carried out by the <Name-TBD> working group.
      
The working group will develop the following documents:
    o One or more documents describing <Name-TBD> use cases,
    o A <Name-TBD> architecture,
    o A set of one or more protocol extensions requirements documents,
    o Inter-operability reports pertaining to the implementation of extensions
      supporting <Name-TBD>.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Sep 2013 23:55:49 +0200

Hi Rob,

>       data, within both centralised and distributed environments,

I think the above is a very important statement. In fact perhaps we
could explicitly mentioned there that such paths could be p2p as well
as p2mp.

>       requirements for extensions or new functionality that is required.

As said before I disagree that we need to work off "gaps". Imagine if
we all in IETF/networking would be walled to work off *gaps* we will
be still improving FDDI, Token Ring, ATM and Frame Relay technologies.
You can do a lot with RSVP-TE .. but there is not only control plane
complexity associated with this, but also unnecessary state. Same for
LDP.

I would recommend to rephrase the above:

o Having identified use-cases, and developed a framework, the WG will
work on proposing a new architectures which substantially improve
current technologies identify gaps in currently available technologies
and define requirements for extensions or new functionality in
existing routing protocols and/or I2RS protocol.

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Sep 2013 00:19:33 +0200

Apologies ... fixed the below due to copy error:

> current technologies and define requirements for extensions or new
> functionality in existing routing protocols and/or I2RS protocol.

r.

---

From: Rob Shakir <[email-masked]>
Date: Thu, 12 Sep 2013 23:23:07 +0100

>> functionality in existing routing protocols and/or I2RS protocol.

Hi Robert,

Sure - I have no problems with this. I think the key is to ensure that we are working on problems that need solutions, either through omissions of current technologies, or where there is scope for improvement. I'll merge the change.

On the p2p/p2mp case, I'm not clear that we need to explicitly define this in the charter. The text currently makes no reference to the type of path, since these should be defined within the use case documents IMHO.

Updated text is below.

Thanks,
r.

Name: <TBD>

      functionality in existing routing protocols and/or I2RS protocols.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Sep 2013 02:55:39 +0000

To make this work move forward, it'd better for us to focus on those items which have gained wide consensus while leaving aside those uncertain and controversial items. Once there are some sketches for the latter, we could evaluate whether it's worthwhile to recharter for them at that time.

Best regards,
Xiaohu 

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Rob
> Shakir
> 发送时间: 2013年9月13日 5:12
> 收件人: [email-masked]; Hannes Gredler; sprevidi
> 抄送: <[email-masked]>
> 主题: [Status] Updated Merged Charter.
> 
> Following some discussion with Stephane, I tried to consolidate the wording
> from the various threads into one charter proposal, which can be found below
> this message.
> 
> > to define the data plane requirements for the environment within which they
> are to be implemented. The > <Name-TBD> architecture should avoid
> modifications to the MPLS data-plane, in order to remain
> There are of course a number of different opinions relating to the network
> deployments in which different operators would like to deploy the technology
> that will be developed by this effort. In my humble opinion, the debates as to
> the exact requirements can (and should) be done in the working group as we
> develop on the use cases. I have therefore tried to make sure that the wording
> in the charter does not pre-judge the result of such debates, but does not close
> the door on them in the future (should consensus exist to work on them). I
> believe this also captures the points relating to data-planes that the ADs noted
> in the evaluation of the BoF.
> 
> Your feedback on this proposal would be very much appreciated (and thanks to
> Stephane for his initial proposal and help with this)!
> 
> Kind regards,
> r.
> 
> Name: <TBD>
> 
> have triggered work on the definition of a new architecture and protocol
> extensions, allowing nodes to steer packets through a network, allowing
> combination of well-known shortest-path based routing paradigms with source
> or explicit routing methods. Some of the extensions allowing steering of packets
> in this manner have already been implemented.
> 
> The <Name-TBD> working group will define an architecture allowing a node to
> steer a packet through a network, or set of networks, on any path without
> requiring state to be maintained by transited nodes (but rather at the source
> device). The source node may send any packet along a path within the
> <Name-TBD> domain through specifying the identifiers referring to this path.
> Subsequent downstream nodes along the path within the <Name-TBD> domain
> will forward packets according to the instructions inserted by the head-end.
> 
> Within the <Name-TBD> architecture, a node may be of any type - including
> routers and appliances. A set of such nodes sharing a common trust model form
> a <Name-TBD> domain. The architecture defined by this working group will
> allow steering of packets between any source and destination node within the
> <Name-TBD> domain, which may be formed of one or more networks, on any
> path (shortest, non-shortest, explicit, or based on other resources or
> characteristics specified by segment identifiers).
> 
> The <Name-TBD> architecture should support both centralised and distributed
> path computation - through both existing routing protocols (IGP, BGP) and new
> approaches to such path calculation. The architecture should also support OAM
> functions.
> 
> The <Name-TBD> architecture has been postulated to be applicable to multiple
> data planes (e.g., MPLS, IPv6), and hence the working group should strive to
> create a single <Name-TBD> framework which maintains data plane
> independence where possible. Where use cases are documented, care should be
> taken to define the data plane requirements for the environment within which
> they are to be implemented. The <Name-TBD> architecture should avoid
> modifications to the MPLS data-plane, in order to remain compatible with
> existing extensive deployments of MPLS.
> 
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

---

From: <[email-masked]>
Date: Fri, 13 Sep 2013 08:16:32 +0200

Rob, Stephane and Robert,

thanks again for your constructive input. I support your proposal.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob Shakir
Sent: Friday, September 13, 2013 12:23 AM
To: Robert Raszuk
Cc: Hannes Gredler; [email-masked]; sprevidi; <[email-masked]>
Subject: Re: [Status] Updated Merged Charter.

Hi Robert,

Updated text is below.

Thanks,
r.

Name: <TBD>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 13 Sep 2013 10:07:45 +0000

Hi Rob, Stephane, Robert,

Thanks for the effort. I think we're in the good direction.

I support your proposal of updated charter and I'd propose "SEGROUTE" 
as WG name since it reflects pretty well the architecture that has 
been proposed (SR) and it's inline with RFC2460 which uses "segments" 
and "ordered list of segments" terminology in the framework of source 
routing (section 4.4).

s.

---

From: "Field, Brian" <[email-masked]>
Date: Fri, 13 Sep 2013 11:50:13 +0000

I support the updated charter as proposed by Rob and I am particularly
interested in an end-to-end IPv6 solution.

Brian

On 9/13/13 4:07 AM, "Stefano Previdi (sprevidi)" <[email-masked]>
wrote:

>> Sure - I have no problems with this. I think the key is to ensure that
>>we are working on problems that need solutions, either through omissions
>>of current technologies, or where there is scope for improvement. I'll
>>merge the change.
>> 
>> On the p2p/p2mp case, I'm not clear that we need to explicitly define
>>this in the charter. The text currently makes no reference to the type
>>of path, since these should be defined within the use case documents
>>IMHO.
>> 
>> Updated text is below.
>> 
>> Thanks,
>> r.
>> 
>> Name: <TBD>
>> 
>> have triggered work on the definition of a new architecture and
>>protocol extensions, allowing nodes to steer packets through a network,
>>allowing combination of well-known shortest-path based routing paradigms
>>with source or explicit routing methods. Some of the extensions allowing
>>steering of packets in this manner have already been implemented.
>> 
>> The <Name-TBD> working group will define an architecture allowing a
>>node to steer a packet through a network, or set of networks, on any
>>path without requiring state to be maintained by transited nodes (but
>>rather at the source device). The source node may send any packet along
>>a path within the <Name-TBD> domain through specifying the identifiers
>>referring to this path. Subsequent downstream nodes along the path
>>within the <Name-TBD> domain will forward packets according to the
>>instructions inserted by the head-end.
>> 
>> Within the <Name-TBD> architecture, a node may be of any type -
>>including routers and appliances. A set of such nodes sharing a common
>>trust model form a <Name-TBD> domain. The architecture defined by this
>>working group will allow steering of packets between any source and
>>destination node within the <Name-TBD> domain, which may be formed of
>>one or more networks, on any path (shortest, non-shortest, explicit, or
>>based on other resources or characteristics specified by segment
>>identifiers).
>> 
>> The <Name-TBD> architecture should support both centralised and
>>distributed path computation - through both existing routing protocols
>>(IGP, BGP) and new approaches to such path calculation. The architecture
>>should also support OAM functions.
>> 
>> The <Name-TBD> architecture has been postulated to be applicable to
>>multiple data planes (e.g., MPLS, IPv6), and hence the working group
>>should strive to create a single <Name-TBD> framework which maintains
>>data plane independence where possible. Where use cases are documented,
>>care should be taken to define the data plane requirements for the
>>environment within which they are to be implemented. The <Name-TBD>
>>architecture should avoid modifications to the MPLS data-plane, in order
>>to remain compatible with existing extensive deployments of MPLS.
>>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 13 Sep 2013 13:23:52 +0000

Support,

However suggest that "Some of the extensions allowing steering of packets in this manner have already been implemented" is not really relevant to the charter as consensus and working code is a back end requirement.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, September 13, 2013 2:17 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Status] Updated Merged Charter.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob Shakir
Sent: Friday, September 13, 2013 12:23 AM
To: Robert Raszuk
Cc: Hannes Gredler; [email-masked]; sprevidi; <[email-masked]>
Subject: Re: [Status] Updated Merged Charter.

Hi Robert,

Updated text is below.

Thanks,
r.

Name: <TBD>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 13 Sep 2013 13:27:55 +0000

Hi Peter,

> However suggest that "Some of the extensions allowing steering of packets in this manner have already been implemented" is not really relevant to the charter as consensus and working code is a back…

indeed. However, it's a way to illustrate that requirements (even if 
not yet documented) do exist. Obviously, they must be documented 
appropriately and we are working on it.

Thanks for your support.
s.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 13 Sep 2013 13:40:04 +0000

Fine, as long as that's not used as an argument that something has already been implemented and therefore can't be changed.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
Sent: Friday, September 13, 2013 9:28 AM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: Re: [Status] Updated Merged Charter.

Hi Peter,

Thanks for your support.
s.