Subject: [Status] TBD Charter - ready of RTG AD review yes/no

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Sep 2013 16:24:35 +0100

Thanks to those that have worked on pulling together the
charter text.

I now need to check whether there is consensus that this
represents the right starting point for the Routing ADs
to engage with the list and polish it to the point where
we are confident that it will gain the approval of the IESG.

Some notes on timeline are appropriate. In order to meet
as a WG in Vancouver this needs to be approved for
external review at the IESG telechat  on 10th October.
This means that we have to add it to the agenda by 26th
September. This means that we (the Routing ADs) need
to have a view that the text of 26th September is likely
to be acceptable to both the community and the IESG.
It also mean an active dialog with members of the IESG
regarding review comments raised in the period up to
10th October.

For reference, I am about to put a placeholder for this
on the BOF page, in order for an agenda slot to be
reserved for this work, hopefully to meet as a WG,
but otherwise to meet to finish of the charter.

So back to the question, is there consensus that text
below is now at the point where the RTG ADs should
actively engage to get it ready for IESG approval
- yes/no?

Thanks

Stewart

=================

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
       work on proposing a new architectures which substantially improve
       current technologies and define requirements for extensions or new
       functionality in existing routing protocols and/or I2RS protocols.
     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: Rob Shakir <[email-masked]>
Date: Fri, 13 Sep 2013 16:40:25 +0100

Hi Stewart,

> actively engage to get it ready for IESG approval

Thanks, I believe that this charter is ready for the examination of the routing ADs, and forward for IESG approval.

Kind regards,
r.

---

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

> actively engage to get it ready for IESG approval

yes.

s.

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Sep 2013 20:14:01 +0200

> - yes/no?

Yes.

Thx,
R.

---

From: "John G. Scudder" <[email-masked]>
Date: Sun, 15 Sep 2013 17:09:34 -0400

Stewart,

I have a number of mostly-editorial comments. They're in line below. There is one substantive but relatively small change, which is called out. I've appended a version of the draft charter that consolidates my proposed edits, at the bottom.

Going through the exercise of doing this has reminded me of one significant concern, though. The first work item for the WG in the proposed charter is:

This leads to the simple question: until we've identified use cases, how can we say we need a new architecture? We are presupposing the outcome. If the agreed use cases end up being things that are supportable within the existing MPLS architecture, that is great. Note I'm not saying the use cases shouldn't be addressed, merely that their solutions may, or may not, rise to the level of "architecture". I would be interested in discussion of this question before we close on a charter.

The rest is in line below.

> actively engage to get it ready for IESG approval

The foregoing does/did add something to the mailing list discussion, but I think should be omitted from the charter. After all, the first work item listed in the charter is exactly to produce a list of "use-cases ... for which there is consensus". By definition there can't be any consensus in the WG yet since there is no WG yet. This is an easy edit; the charter reads just fine starting from the below paragraph and there are no normative (as it were) changes.

(Also, an editorial nit: "use case" is conventionally not hyphenated -- a search-and-replace will fix this.)

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

The two forgoing paragraphs have a lot of redundancy, probably due to the multiple revision cycles they've been through. Here is a potential rewrite merging the two but attempting to maintain all the content:

The <Name-TBD> working group will define an architecture that will allow a node to steer a packet between any source and destination through a <Name-TBD> domain on any path without requiring state to be maintained by transited nodes, but rather at the source device. A <Name-TBD> domain is a network or set of networks comprised of nodes (which may be of any type, including routers and appliances) that share a common trust model. The path may be shortest, non-shortest, explicit, or based on other resources or characteristics specified by segment identifiers.

Some comments on this --

- I'm not actually sure what "set of networks" really adds. AFAIK it has no well-defined meaning distinct from that of "network".
- I don't think the final sentence actually adds anything since the first sentence says "any path" and "any" takes in the entire universe of possibilities already. The final sentence also uses the term "segment identifiers" which is not defined in the charter.

IMO neither of these actually detracts (other than the undefined term), but neither do they add, so my preference would be to leave them out (I generally favor the "perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away" heuristic). So:

The <Name-TBD> working group will define an architecture that will allow a node to steer a packet between any source and destination through a <Name-TBD> domain on any path without requiring state to be maintained by transited nodes, but rather at the source device. A <Name-TBD> domain is a network comprised of nodes (which may be of any type, including routers and appliances) that share a common trust model.

I actually think "which may be of any type, including routers and appliances" is in the same category (it's implicit) but I realize that others will probably disagree so I haven't proposed eliding it. I'd be happy to though, if I am mistaken.

> 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 ar…

The first sentence is puzzlingly broad, especially when you get to "... and new approaches to path calculation." The best I can parse it is "we haven't decided how to do this yet but everything should be on the table". I think it could be trimmed to "The <Name-TBD> architecture should support both centralised and distributed path computation" without loss of generality.

> The <Name-TBD> architecture has been postulated to be applicable to multiple data planes (e.g., MPLS, IPv6), and hence 

The paragraphs preceding this one state that the WG will define the <Name-TBD> architecture. This means that by definition there isn't a <Name-TBD> architecture yet. As such I don't see how it can be postulated to be much of anything, and would suggest that the foregoing clause be cut. I think that again, this can be done without loss of generality since the following text captures the intent.

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

I suggest adding "It is anticipated the <Name-TBD> architecture may need to propose modifications to the IPv6 data plane." (One could use "extensions" in place of "modifications", though I prefer it as written.) I also suggest that a work item be added,

  o Document impact (if any) of any proposed IPv6 data plane modifications  
    on existing deployment of IPv6.

I believe this is the only substantive change I've proposed, the rest being editorial.

>    work on proposing a new architectures which substantially improve

"a new architecture that substantially improves upon"

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

I'm a little confused why all routing protocols would be taken in but only i2rs among management protocols, and besides isn't it still TBD if i2rs will even end up defining a protocol? Thus, how about "existing routing and management protocols"?

>  o Inter-operability reports pertaining to the implementation of extensions

Finally I have a question, or observation: Where we are talking about modifying/extending a data plane (IPv6) there may be implications to inter-domain forwarding. Thus the initial focus on intra-domain forwarding, above, is a little concerning -- one can easily imagine a sequence like

- Define intra-domain forwarding,
- Define new v6 data plane,
- Publish specs,
- Recharter to include inter-domain, 
- Define inter-domain forwarding,
- Oops, we need to further extend the v6 data plane.

Since the cost of extending the v6 data plane may end up being non-trivial, it seems as though it would be desirable to avoid this kind of iteration. Do others agree and if so how should we capture this in the charter?

Thanks,

--John

Consolidated edits below:

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

Name: <TBD>

The <Name-TBD> working group will define an architecture that will allow a node to steer a packet between any source and destination through a <Name-TBD> domain on any path without requiring state to be maintained by transited nodes, but rather at the source device. A <Name-TBD> domain is a network comprised of nodes (which may be of any type, including routers and appliances) that share a common trust model.

The <Name-TBD> architecture should support both centralised and distributed path computation. The architecture should also support OAM functions.

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. It is anticipated the <Name-TBD> architecture may need to propose modifications to the IPv6 data plane.

 o Document impact (if any) of any proposed IPv6 data plane modifications  
   on existing deployment of IPv6,

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Sun, 15 Sep 2013 22:51:45 +0000

On 9/13/13 9:24 AM, "Stewart Bryant (stbryant)" <[email-masked]> wrote:

Stewart:

Hi!

Just a couple of comments:

...
>The <Name-TBD> working group is chartered for the following (ordered)

What do we mean by "ordered"?

I guess that it is just referring to the "natural" order of things: define
use cases, architecture, solutions, etc..which is obvious to me.  I may
have not been paying close attention, but I haven't seen "ordered"
mentioned in other WG charters.

There was some discussion on the list about the order of events and the
milestones between them.  I just want to make sure that "ordered" does not
have different meanings to different people.

>     o Inter-operability reports pertaining to the implementation of

Comparing the list of items to the documents, I think we're missing an
architectural framework document.

Thanks!

Alvaro.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 16 Sep 2013 03:00:11 +0200

> architectural framework document.

I hope we are not setting ourselves up for an architectural framework *and* architecture document though (on top of the obligatory use-case documents). One architecture document (which itself certainly would need to provide a solution framework) should suffice. I understand how the charter as written leads the reader on to think these are separate, let's fix that instead.

- Mark

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 16 Sep 2013 01:07:45 +0000

That works for me.  The point was more about pointing at the differences.

Thanks!

Alvaro.

Sent from my iPhone

---

From: Mark Townsley <[email-masked]>
Date: Mon, 16 Sep 2013 03:22:52 +0200

> This leads to the simple question: until we've identified use cases, how can we say we need a new architecture? We are presupposing the outcome. If the agreed use cases end up being things that are…

Also, there is the suggestion in the current text that "new architectures" will "substantially improve current technologies" .. I don't see how an architecture on its own can do a thing to improve current technology, it only provides a framework to operate in so that technological improvements can be made. Let me suggest some text to be completely clear (which also incorporates another suggestion from John Scudder)

OLD:

NEW:

The <Name-TBD> working group is chartered for the following items:

o Identification and evaluation of <Name-TBD> use-cases  
o Definition of a <Name-TBD> Architecture, driven by the use cases and underlying technology 
o The <Name-TBD> Architecture must cover security considerations (including the relationship between networks forming the <Name-TBD> domain) and allow for solutions which substantially improve upon current technologies by defining requirements, extensions, or new functionality in existing routing, l2rs or other protocols.

Thanks,

- Mark

---

From: Rob Shakir <[email-masked]>
Date: Mon, 16 Sep 2013 09:18:38 +0100

Hi John,

A few comments in-line, marked rjs>.

On 15 Sep 2013, at 22:09, John G. Scudder <[email-masked]> wrote:

>> […snip…]

rjs> I think that "set of networks" is required here -- if we consider this from a wider view than purely 
technical (e.g., operational or administrative separation), then the overall <Name-TBD> domain may be made up of multiple different underlying separate administrative entities ("networks"). The key thing (for me) is that these networks have a model whereby the source can be wholly trusted to steer a packet through the domain.

> I actually think "which may be of any type, including routers and appliances" is in the same category (it's implicit) but I realize that others will probably disagree so I haven't proposed eliding…

rjs> In both these cases, the intention of the wording is to provide some form of example of the kind of functionality that is required from the new architecture.

rjs> If we lose the first paragraph which gives a set of example use-cases for this technology, then I think it would be good to include the types of nodes/paths that are envisaged. I think this helps support the distinction between a domain-wide protocol to determine the route, and a head-end being able to pick an arbitrary path without any knowledge of the transit nodes as to the means by which it was calculated.

> The first sentence is puzzlingly broad, especially when you get to "... and new approaches to path calculation." The best I can parse it is "we haven't decided how to do this yet but everything sho…

rjs> I'm OK with this, the intention was to try and ensure that there is no direct tie only to today's protocols/approaches to this (so that we can retain the generality of the data plane instantiation).

> The paragraphs preceding this one state that the WG will define the <Name-TBD> architecture. This means that by definition there isn't a <Name-TBD> architecture yet. As such I don't see how it can…

rjs> I don't agree with cutting this sentence in its entirety.

rjs> I would suggest:

"Mechanisms allowing a source node to steer a packet through an arbitrary set of nodes/links (without transit modes maintaining state) have been postulated to be applicable to multiple data planes (e.g., MPLS, IPv6), and hence…"

rjs> the reason being that we have already had debate (on this list) as to what data planes are of interest for the drafts which triggered the BoF. The problem you highlighted is that there is perhaps the jump that infers that these proposals may form the architecture - which may not be the case, so I'm happy to remove the "The <Name-TBD> architecture…".  However, I would like to ensure that there is something in the charter that captures that there are operators who are interested in >1 data plane.

> I believe this is the only substantive change I've proposed, the rest being editorial.

rjs> I don't see an issue with including this.

> I'm a little confused why all routing protocols would be taken in but only i2rs among management protocols, and besides isn't it still TBD if i2rs will even end up defining a protocol? Thus, how ab…

rjs> Again, I'm OK with this.

> Since the cost of extending the v6 data plane may end up being non-trivial, it seems as though it would be desirable to avoid this kind of iteration. Do others agree and if so how should we capture…

rjs> Is this not down to what the definition of "domain" is (see: "network" vs. "set of networks" discussion above). Do we envisage that intra-*<Name-TBD>-domain* forwarding will really be radically different to inter-"<Name-TBD>-domain"? The key difference between the two would appear to me to be trust model, rather than anything else?

rjs> One possible fix is to strike the wording which asks for focus on intra-domain forwarding -- however, if we look at the use-cases that triggered this work, there does not appear (to me) to be any that really asks for inter-domain yet, so I can't support having to address the plethora of issues that exist when extending source-routing into environments that do not have a common trust model before we can proceed with anything to do with intra-domain forwarding (where there are a number of well-established use-cases).

Cheers,
r.

---

From: <[email-masked]>
Date: Mon, 16 Sep 2013 08:41:19 +0000

Hi,

>  o Document impact (if any) of any proposed IPv6 data plane modifications on existing deployment of IPv6,
>  o Inter-operability reports pertaining to the implementation of extensions supporting <Name-TBD>.

There may be a need for a specific MPLS document, to define MPLS specific aspects, in particular the interworking with existing MPLS signaling protocols (LDP, RSVP-TE) (during the transition period).
It's not clear to me where such MPLS specific work will be done:
- MPLS WG? But there is no expected protocol extension in the MPLS dataplane, MPLS architecture, LDP and RSVP-TE. Hence "A set of one or more protocol extensions requirements documents" may not apply.
- <Name-TBD> WG? But there is no mention of an MPLS specific document (while during the BOF, "There was overwhelming support for work on MPLS Source Routing (SR)")

Regarding the home of such a document, IMHO I would favor the <Name-TBD> WG where there is a priori a better chance for combined MPLS & <Name-TBD> knowledge.

Regards,
Bruno

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Stewart Bryant
>Sent: Friday, September 13, 2013 5:25 PM
>To: [email-masked]
>Cc: Adrian Farrel
>Subject: [Status] TBD Charter - ready of RTG AD review yes/no
>
>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.
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 16 Sep 2013 13:30:17 +0000

On 9/16/13 4:18 AM, "Rob Shakir" <[email-masked]> wrote:

Rob:

Hi!

>>
>>- I don't think the final sentence actually adds anything since the
>>first sentence says "any path" and "any" takes in the entire universe of
>>possibilities already. The final sentence also uses the term "segment
>>identifiers" which is not defined in the charter.
>>IMO neither of these actually detracts (other than the undefined term),
>>but neither do they add, so my preference would be to leave them out (I
>>generally favor the "perfection is achieved, not when there is nothing
>>more to add, but when there is nothing left to take away" heuristic). So:
>>The <Name-TBD> working group will define an architecture that will allow
>>a node to steer a packet between any source and destination through a
>><Name-TBD> domain on any path without requiring state to be maintained
>>by transited nodes, but rather at the source device. A <Name-TBD> domain
>>is a network comprised of nodes (which may be of any type, including
>>routers and appliances) that share a common trust model.
>>I actually think "which may be of any type, including routers and
>>appliances" is in the same category (it's implicit) but I realize that
>>others will probably disagree so I haven't proposed eliding it. I'd be
>>happy to though, if I am mistaken.
>
>rjs> In both these cases, the intention of the wording is to provide some
>form of example of the kind of functionality that is required from the
>new architecture.
>
>rjs> If we lose the first paragraph which gives a set of example
>use-cases for this technology, then I think it would be good to include
>the types of nodes/paths that are envisaged. I think this helps support
>the distinction between a domain-wide protocol to determine the route,
>and a head-end being able to pick an arbitrary path without any knowledge
>of the transit nodes as to the means by which it was calculated.

I agree with John on this.  While the examples seem to help clarify, that
is what the use cases (the complete description, not just the list) are
for: to explicitly tell us (the WG) what needs to be solved..and that
should be the first chartered step anyway.

My 1c.

Alvaro.

---

From: John E Drake <[email-masked]>
Date: Mon, 16 Sep 2013 14:50:56 +0000

John,

Would it make sense to change the word 'architecture' to the word 'paradigm' in your proposed charter text, below?

Yours Irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of John G. Scudder
> Sent: Sunday, September 15, 2013 2:10 PM
> To: [email-masked]
> Cc: Adrian Farrel; [email-masked]
> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no
> 
> Stewart,
> 
> I have a number of mostly-editorial comments. They're in line below. There is
> one substantive but relatively small change, which is called out. I've
> appended a version of the draft charter that consolidates my proposed edits,
> at the bottom.
> 
> Going through the exercise of doing this has reminded me of one significant
> concern, though. The first work item for the WG in the proposed charter is:
> 
> This leads to the simple question: until we've identified use cases, how can
> we say we need a new architecture? We are presupposing the outcome. If
> the agreed use cases end up being things that are supportable within the
> existing MPLS architecture, that is great. Note I'm not saying the use cases
> shouldn't be addressed, merely that their solutions may, or may not, rise to
> the level of "architecture". I would be interested in discussion of this
> question before we close on a charter.
> 
> > Thanks to those that have worked on pulling together the charter text.
> >
> > I now need to check whether there is consensus that this represents
> > the right starting point for the Routing ADs to engage with the list
> > and polish it to the point where we are confident that it will gain
> > the approval of the IESG.
> >
> > Some notes on timeline are appropriate. In order to meet as a WG in
> > Vancouver this needs to be approved for external review at the IESG
> > telechat  on 10th October.
> > This means that we have to add it to the agenda by 26th September.
> > This means that we (the Routing ADs) need to have a view that the text
> > of 26th September is likely to be acceptable to both the community and
> > the IESG.
> > It also mean an active dialog with members of the IESG regarding
> > review comments raised in the period up to 10th October.
> >
> > For reference, I am about to put a placeholder for this on the BOF
> > page, in order for an agenda slot to be reserved for this work,
> > hopefully to meet as a WG, but otherwise to meet to finish of the
> > charter.
> >
> > So back to the question, is there consensus that text below is now at
> > the point where the RTG ADs should actively engage to get it ready for
> > IESG approval
> > - yes/no?
> >
> > Thanks
> >
> > Stewart
> >
> > =================
> >
> > Name: <TBD>
> >
> >    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,
> 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 foregoing does/did add something to the mailing list discussion, but I
> think should be omitted from the charter. After all, the first work item listed
> in the charter is exactly to produce a list of "use-cases ... for which there is
> consensus". By definition there can't be any consensus in the WG yet since
> there is no WG yet. This is an easy edit; the charter reads just fine starting
> from the below paragraph and there are no normative (as it were) changes.
> 
> > 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
> 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 two forgoing paragraphs have a lot of redundancy, probably due to the
> multiple revision cycles they've been through. Here is a potential rewrite
> merging the two but attempting to maintain all the content:
> 
> The <Name-TBD> working group will define an architecture that will allow a
> node to steer a packet between any source and destination through a
> is a network or set of networks comprised of nodes (which may be of any
> type, including routers and appliances) that share a common trust model.
> The path may be shortest, non-shortest, explicit, or based on other
> resources or characteristics specified by segment identifiers.
> 
> Some comments on this --
> 
> - I'm not actually sure what "set of networks" really adds. AFAIK it has no
> well-defined meaning distinct from that of "network".
> - I don't think the final sentence actually adds anything since the first
> sentence says "any path" and "any" takes in the entire universe of
> IMO neither of these actually detracts (other than the undefined term), but
> neither do they add, so my preference would be to leave them out (I
> generally favor the "perfection is achieved, not when there is nothing more
> to add, but when there is nothing left to take away" heuristic). So:
> 
> The <Name-TBD> working group will define an architecture that will allow a
> node to steer a packet between any source and destination through a
> I actually think "which may be of any type, including routers and appliances"
> is in the same category (it's implicit) but I realize that others will probably
> disagree so I haven't proposed eliding it. I'd be happy to though, if I am
> mistaken.
> 
> > 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 first sentence is puzzlingly broad, especially when you get to "... and new
> approaches to path calculation." The best I can parse it is "we haven't
> decided how to do this yet but everything should be on the table". I think it
> could be trimmed to "The <Name-TBD> architecture should support both
> centralised and distributed path computation" without loss of generality.
> 
> > The <Name-TBD> architecture has been postulated to be applicable to
> > multiple data planes (e.g., MPLS, IPv6), and hence
> 
> The paragraphs preceding this one state that the WG will define the <Name-
> TBD> architecture. This means that by definition there isn't a <Name-TBD>
> architecture yet. As such I don't see how it can be postulated to be much of
> anything, and would suggest that the foregoing clause be cut. I think that
> again, this can be done without loss of generality since the following text
> captures the intent.
> 
> > 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
> I suggest adding "It is anticipated the <Name-TBD> architecture may need to
> propose modifications to the IPv6 data plane." (One could use "extensions"
> in place of "modifications", though I prefer it as written.) I also suggest that a
> work item be added,
> 
> I'm a little confused why all routing protocols would be taken in but only i2rs
> among management protocols, and besides isn't it still TBD if i2rs will even
> end up defining a protocol? Thus, how about "existing routing and
> management protocols"?
> 
> >  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>.
> 
> Finally I have a question, or observation: Where we are talking about
> modifying/extending a data plane (IPv6) there may be implications to inter-
> domain forwarding. Thus the initial focus on intra-domain forwarding, above,
> is a little concerning -- one can easily imagine a sequence like
> 
> Since the cost of extending the v6 data plane may end up being non-trivial, it
> seems as though it would be desirable to avoid this kind of iteration. Do
> others agree and if so how should we capture this in the charter?
> 
> Thanks,
> 
> --John
> 
> The <Name-TBD> working group will define an architecture that will allow a
> node to steer a packet between any source and destination through a
> The <Name-TBD> architecture should support both centralised and
> distributed path computation. The architecture should also support OAM
> functions.
> 
> 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
> deployments of MPLS. It is anticipated the <Name-TBD> architecture may
> need to propose modifications to the IPv6 data plane.
> 
>  o One or more documents describing <Name-TBD> use cases,  o A <Name-
> TBD> architecture,  o Document impact (if any) of any proposed IPv6 data
> plane modifications
>  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: John G.Scudder <[email-masked]>
Date: Tue, 17 Sep 2013 10:21:36 -0400

All,

Here's another attempt. It tries to address the 'architecture' issue I raised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name-TBD> region' relieves the ambiguity that was present in earlier versions.

--John

---------------------------------------------------------
Name: <TBD>

The <Name-TBD> working group will define procedures that will allow
a node to steer a packet between any source and destination through
a <Name-TBD> region on any path without requiring state to be
maintained by transited nodes, but rather at the source device.  A
<Name-TBD> region is a network comprised of nodes (which may be of
any type, including routers and appliances) that share the following
trust model: any node in the <Name-TBD> region is trusted to steer 
a packet through any of the other nodes within the region. The 
<Name-TBD> region may comprise one or more ASes, or even less than a 
single AS. Although a region may comprise more than one AS, initial 
work will focus on the intra-domain, that is, single AS, scenario.

The procedures should support both centralised and distributed path
computation. The procedures should also cover support for OAM
functions.

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 procedures should avoid modifications to
the MPLS data plane, in order to remain compatible with existing
extensive deployments of MPLS. It is anticipated that the procedures
may require modifications to the IPv6 data plane.  While the initial
focus of the <Name-TBD> WG is on the intra-domain deployment scenarios
(see below), the modifications to the IPv6 data plane must support
both intra and inter-domain deployment scenarios.

The <Name-TBD> working group is chartered for the following (ordered)
list of items:

o Identification and evaluation of use cases for which there 
  is consensus within the WG.
o Definition of new procedures, driven by the use cases and underlying 
  technology. The new procedures must cover security considerations 
  (including the relationship between networks forming the <Name-TBD> 
  region) and allow for solutions which substantially improve upon 
  current technologies by defining requirements, extensions, or new
  functionality in existing routing, management or other protocols.
o Determine whether the above mentioned procedures require
  modification/changes to the existing MPLS architecture, and
  if so, then document such modifications/changes.
o Determine whether the above mentioned procedures require
  modification/changes to the existing IPv6 architecture, and
  if so, then document such modifications/changes.
o The <Name-TBD> working group will then develop solutions, focusing
  initially on intra-domain deployment scenarios. Where such
  solutions utilize 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.

o One or more documents describing <Name-TBD> use cases,
o Specification of new procedures to support <Name-TBD> use cases,
o Changes to MPLS architecture, if needed
o Changes to IPv6 architecture, if needed
o Document interworking and co-existence between the new procedures
  and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
o Document impact (if any) of any proposed IPv6 data plane modifications  
  on existing deployment of IPv6,
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: Gregory Mirsky <[email-masked]>
Date: Tue, 17 Sep 2013 23:36:31 +0000

Hi John, et. al,
I think that because of second paragraph, "... support both centralized and distributed path computation", a change is needed to specify that state must be maintained not necessarily at the source device but at the path computing device (closing of the first sentence of the first paragraph).

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John G.Scudder
Sent: Tuesday, September 17, 2013 7:22 AM
To: [email-masked]
Cc: Adrian Farrel; [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

All,

--John

The <Name-TBD> working group will define procedures that will allow a node to steer a packet between any source and destination through a <Name-TBD> region on any path without requiring state to be maintained by transited nodes, but rather at the source device.  A <Name-TBD> region is a network comprised of nodes (which may be of any type, including routers and appliances) that share the following trust model: any node in the <Name-TBD> region is trusted to steer a packet through any of the other nodes within the region. The <Name-TBD> region may comprise one or more ASes, or even less than a single AS. Although a region may comprise more than one AS, initial work will focus on the intra-domain, that is, single AS, scenario.

The procedures should support both centralised and distributed path computation. The procedures should also cover support for OAM functions.

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 procedures should avoid modifications to the MPLS data plane, in order to remain compatible with existing extensive deployments of MPLS. It is anticipated that the procedures may require modifications to the IPv6 data plane.  While the initial focus of the <Name-TBD> WG is on the intra-domain deployment scenarios (see below), the modifications to the IPv6 data plane must support both intra and inter-domain deployment scenarios.

o One or more documents describing <Name-TBD> use cases, o Specification of new procedures to support <Name-TBD> use cases, o Changes to MPLS architecture, if needed o Changes to IPv6 architecture, if needed o Document interworking and co-existence between the new procedures
  and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Document impact (if any) of any proposed IPv6 data plane modifications
  on existing deployment of IPv6,
o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of extensions
  supporting <Name-TBD>.
_______________________________________________
status mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/status

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 18 Sep 2013 03:03:03 +0200

Hi Gregory,

Wouldn't it be simpler to say that state is not kept in those network
elements which are acting as transit nodes rather then enumerating all
elements which may impose headers or compute paths ?

Thx,
R.

---

From: <[email-masked]>
Date: Wed, 18 Sep 2013 10:13:14 +0200

Hello John, Greg and Rob,

John, thanks for your draft, which I support.

I recognise the point raised by Greg, but currently have
no preference whether to pick Gregs or Robs proposed text.
I'd prefer something short and generic maintaining the
spirit that the source node maintains at least standard
routing state and additional routing state may be present
locally or in other path computation systems outside of
the <Name-TBD> region (as no packets are steered through
centralised or distributed path computation elements,
that statement shouldn't be wrong).

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, September 18, 2013 3:03 AM
To: Gregory Mirsky
Cc: John G.Scudder; Adrian Farrel; [email-masked]; [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi Gregory,

Thx,
R.

---

From: Rob Shakir <[email-masked]>
Date: Wed, 18 Sep 2013 10:49:09 +0100

Hi John, STATUS,

I'd just like to voice my support for this revised wording - I think it addresses my previous comments.

I would agree with Robert - that we should not attempt to enumerate where state might need to be held within this charter. The fundamental here is that it is not on the mid-point. For some cases, the only state that will be held is at the head-end (where the forwarding state is the set of segment identifiers that it has calculated itself, or has been provided to it by a PCE), in other cases, such as where CAC/co-routing is being performed by a centralised entity (such as stateful PCE) then we will need the head-end to have the forwarding state, and the PCE will need to hold some state. Given there are a number of combinations of such cases, we should leave use-case documents to describe exactly the deployment which is envisaged. 

Thanks,
r.

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 18 Sep 2013 18:00:20 +0000

Hi Robert,
I think that intuitively we all understand what and who the transit nodes of <Name_TBD> region are. But I wonder if this understanding is common. And I think that "transit node" characterization is more in path scope rather than on regional scale. If that is not the case and there is clear distinction between edge of head nodes and core or transit nodes, then, I think, we'll need to capture that and then put into architectural document.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, September 17, 2013 6:03 PM
To: Gregory Mirsky
Cc: John G.Scudder; [email-masked]; Adrian Farrel; [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Hi Gregory,

Wouldn't it be simpler to say that state is not kept in those network elements which are acting as transit nodes rather then enumerating all elements which may impose headers or compute paths ?

Thx,
R.

---

From: <[email-masked]>
Date: Thu, 19 Sep 2013 08:33:52 +0200

John,

> The <Name-TBD> working group is chartered for the following (ordered) list of items:
....

I'd expect work related to MPLS based SR to start relatively soon, while work on IPv6 based SR may require a more thorough analysis. The "(ordered)" therefore should be removed or the  order should be adapted to express that:

  o Determine whether the above mentioned procedures require
    modification/changes to the existing MPLS architecture, and
    if so, then document such modifications/changes.
  o Determine whether the above mentioned procedures require
    modification/changes to the existing IPv6 architecture, and
    if so, then document such modifications/changes.
    In parallel, the <Name-TBD> working group will develop
    solutions for a MPLS architecture, focusing initially on
    intra-domain deployment scenarios. Where such solutions
    utilize 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.
  o The <Name-TBD> working group will then develop solutions for an IPv6
    architecture, focusing initially on intra-domain deployment scenarios.
    Where such solutions utilize 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.

Regards,

Ruediger

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 19 Sep 2013 06:47:29 +0000

Hi Ruediger, John,

On Sep 19, 2013, at 8:33 AM, <[email-masked]> wrote:
> I'd expect work related to MPLS based SR to start relatively soon, while work on IPv6 based SR may require a more thorough analysis.

I agree.

We already have use-cases, architecture and protocol extensions 
drafts (ISIS/OSPF) that have been submitted a while ago and we 
should not defer the work on these just because we mandate an 
ordered list.

> The "(ordered)" therefore should be removed or the  order should be adapted to express that:

yes, I'd just remove the "ordered" term. I believe the WG audience 
will figure out what work can proceed without having to mandate any 
"order".

Thanks.
s.

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 19 Sep 2013 06:52:39 +0000

Agree with Ruediger, also the order put looks about right.

Regards,
Jeff

---

From: Mark Townsley <[email-masked]>
Date: Thu, 19 Sep 2013 09:17:40 +0200

+1. 

Also, any expected ordering can be reflected in the WG milestones that can be updated based on the pace and output of the WG without going through the entire IETF consensus process the charter text must go through. 

- Mark

---

From: <[email-masked]>
Date: Thu, 19 Sep 2013 07:49:38 +0000

John,

Thank you for the proposed charter which looks fine to me.

Nonetheless, +1 to Ruediger's comment: the last 3 points (MPLS forwarding plane, IPv6 forwarding plane, generic control plane) may be done in no particular order, including in parallel.
(and at the very least, if an order is mandatory, it would ease the WG life/work to favor an order based on maturity & consensus, i.e. starting with MPLS and not putting IPv6 forwarding plane extension on the critical path)

Regards,
Bruno

>From: [email-masked]
>
>John,
>
>I'd expect work related to MPLS based SR to start relatively soon, while
>work on IPv6 based SR may require a more thorough analysis. The "(ordered)"
>therefore should be removed or the  order should be adapted to express that:
>
>> Here's another attempt. It tries to address the 'architecture' issue I
>raised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob
>Shakir's comments. With luck the change from '<Name-TBD> domain' to '<Name-
>TBD> region' relieves the ambiguity that was present in earlier versions.
>>
>> --John
>>
>> The <Name-TBD> working group will define procedures that will allow a node
>to steer a packet between any source and destination through a <Name-TBD>
>region on any path without requiring state to be maintained by transited
>nodes, but rather at the source device.  A <Name-TBD> region is a network
>comprised of nodes (which may be of any type, including routers and
>appliances) that share the following trust model: any node in the <Name-TBD>
>region is trusted to steer a packet through any of the other nodes within
>the region. The <Name-TBD> region may comprise one or more ASes, or even
>less than a single AS. Although a region may comprise more than one AS,
>initial work will focus on the intra-domain, that is, single AS, scenario.
>>
>computation. The procedures should also cover support for OAM functions.
>>
>> 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 procedures should avoid modifications to the MPLS data
>plane, in order to remain compatible with existing extensive deployments of
>MPLS. It is anticipated that the procedures may require modifications to the
>IPv6 data plane.  While the initial focus of the <Name-TBD> WG is on the
>intra-domain deployment scenarios (see below), the modifications to the IPv6
>data plane must support both intra and inter-domain deployment scenarios.
>>
>> o One or more documents describing <Name-TBD> use cases, o Specification
>of new procedures to support <Name-TBD> use cases, o Changes to MPLS
>architecture, if needed o Changes to IPv6 architecture, if needed o Document
>interworking and co-existence between the new procedures
>>   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o
>Document impact (if any) of any proposed IPv6 data plane modifications

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 19 Sep 2013 09:45:37 -0400

On Sep 19, 2013, at 2:33 AM, [email-masked] wrote:

> The "(ordered)" therefore should be removed or the  order should be adapted

That would be just fine with me.

--John

---

From: Loa Andersson <[email-masked]>
Date: Thu, 19 Sep 2013 17:48:37 +0200

Ruediger,

it depends on what you mean with "document such modifications/changes".
Almost everything we do in the IETF is documents - we are documenting.

In this case I assume you mean "document the requirements for such
changes" and then let the the working group that owns the particular
data plane specify the actual changes.

Otherwise this look pretty good.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: <[email-masked]>
Date: Fri, 20 Sep 2013 08:31:33 +0200

Hi John,

Loa's comment below refers to a piece of text of your draft charter
which I didn't change. So I think you should pick up his comment.

Regards,

Ruediger

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, September 19, 2013 5:49 PM
To: Geib, Rüdiger
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no

Ruediger,

/Loa

--

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 20 Sep 2013 15:18:42 -0400

[Thanks, Ruediger, for reminding me of this]

Loa,

I think your proposed change is good.

Thanks,

--John