Subject: Re: [Status] Updated charter - version 3 and maybe 4

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 Oct 2013 11:12:57 +0100

Yeah, good catch.

The previous text had gone too far the other way since there is going to be some
small amount of state maintained (otherwise forwarding is going to be really
hard).

I think it is the "per flow state" that will not be needed, and we can add that
back in.

Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rob Shakir
> Sent: 01 October 2013 10:41
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Status] Updated charter - version 3 and maybe 4
> 
> Hi Stewart, {SPRING,STATUS},
> 
> One thing that has gone missing from the charter is the specification of where
> state should be maintained in the solution. I think (and I think the feelings
of the
> list are) that this is an absolute fundamental of the architecture, so it
would be
> good to have this specified in the charter.
> 
> Kind regards,
> r.
> 
> 
> 
> On 30 Sep 2013, at 16:52, Stewart Bryant <[email-masked]> wrote:
> 
> > Adrian and I took a close look the SPRING charter
> > and have edited it to get text that we think is more
> > likely to get through the review cycles.
> >
> > The intent of the changes is not change the work
> > programme, the deliverables or the networks. The
> > purpose of the changes is to generate what we think
> > is a viable charter that matches the intent of
> > this list.
> >
> > First we added a summary of what spring is and
> > why it is needed - that is covered by the first
> > paragraph, the list of *example* and the following
> > paragraph.
> >
> > We then note that we need bot strict and loose
> > path specification.
> >
> > We then discuss the trust model
> >
> > We then say we start with single AS but must be
> > able to multi-AS
> >
> > We call out centralized and distributed path comp.
> >
> > We then call out SPRING as an OAM and the need
> > to manage SPRING.
> >
> > Then for data plane, control plane and management
> > we say, try to use existing, but if that does
> > not work we specify the process for change.
> > Note that we talk about data planes in the plural.
> >
> > We then provide the deliverable as an edited
> > version of the delivery plan.
> >
> > We do not explicitly call out either MPLS or
> > IPv6 (or any other data plane), because,
> >
> > 1) That emerges from the use cases.
> > 2) The charter says use the dataplanes (note the
> > plural) and protocols that are derived from
> > the use cases.
> >
> > The charter therefore set a strong expectation
> > that whatever dataplanes need to to be used
> > to satisfy the network need is in scope.
> >
> > Comments please
> >
> > Stewart
> >
> > PS you may see -04 with some cosmetic/layout changes.
> >
> >
> >
> > _______________________________________________
> > status mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/status
> 
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

---

From: Rob Shakir <[email-masked]>
Date: Tue, 1 Oct 2013 11:21:08 +0100

Hi Adrian,

Thanks. The key point (for me) is that the architecture MUST NOT require per-flow state on the mid-points (of course, the head-end of an LSP is likely to need some form of state relating each path it wants to use).

Kind regards,
r.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 01 Oct 2013 12:17:55 +0100

All

Version 4 is posted here:

https://datatracker.ietf.org/doc/charter-ietf-spring/

and incorporates changes to address the various
comments received overnight.

Please remember that you can use

http://datatracker.ietf.org/doc/charter-ietf-spring/history/

to see what changes were made.

- Stewart

---

From: Loa Andersson <[email-masked]>
Date: Tue, 01 Oct 2013 19:28:21 +0800

Stewart,

this is almost there, but I still have the isue from before.

Not being a native English speaker, I have no sense for what
conjunction means in this type of text. Looking in dictionaries
does not help, it seems to imply some rather weak coordination;
like joint wg last call.

Anyone that can help out.

/Loa

-- 

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

---

From: <[email-masked]>
Date: Tue, 1 Oct 2013 13:50:13 +0200

Hi Stewart,

thanks. Your latest draft looks fine to me.

A question for clarification:

   The SPRING working group will define procedures that
   will allow a node to steer a packet along an explicit
   route using information attached to the packet and
   without the need for per-flow state information to be
   held at transit nodes.

By that definition it is clear that the WG is chartered to enable
extension of IGPs to gain MPLS topology awareness for all nodes
within a SPRING domain?

If yes, then the above is fine. If not, the charter should include
a statement allowing for IGP extensions resulting in MPLS topology
awareness of all nodes within a SPRING domain.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, October 01, 2013 1:18 PM
To: [email-masked]
Subject: Re: [Status] Updated charter - version 3 and maybe 4

All

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 01 Oct 2013 13:42:12 +0100

Loa

Ah I  see we fixed the first case and then left a hole
with:

Modification to
existing control plane protocols must be done in
conjunction with the responsible IETF working group.

I have changes this to

Modification to
existing control plane protocols must be done in
conjunction with the responsible IETF working group
using the procedure described above.

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 1 Oct 2013 12:49:16 +0000

On 10/1/13 7:28 AM, "Loa Andersson" <[email-masked]> wrote:

Loa:

Hi!

>does not help, it seems to imply some rather weak coordination;

I agree with you and think we should be more specific.  In looking at the
charter there are at least a 2 places where interaction with other WGs is
mentioned:

[8th paragraph]

SPRING should avoid modification to existing..  Any
modification of or extension to existing architectures,
data planes, or protocols must be carried out in the
working groups responsible for the architecture, data
plane, or protocol being modified and in co-ordination
with this working group, but may be done in this
working group after agreement with all the relevant
WG chairs and responsible Area Directors.

** and **

[third chartered item]

 o Definition of any new control plane mechanism
   needed to enable the use cases. Modification to
   existing control plane protocols must be done in
   conjunction with the responsible IETF working group.

Because both snippets refer to the same topic (modifications to existing
things), I interpret "in conjunction" to mean "carried out" in the
responsible WGs.  Unless agreed in advance (as the 8th paragraph says).

I want to then propose a couple of changes:

1. Consistency in the language: we should be specific and write that the
work should be carried out in the responsible WG.

2. If the work is to be done in a different WG, then it really means that
SPRING will be developing requirements for them (not the solutions).  Even
though the list of documents  does mention requirement documents, it is
not clear from the list of chartered items what needs to be done.

To avoid repetition, I would like to see the following text instead
(starting with the 8th paragraph):

SPRING should avoid modification to existing data
planes that would make them incompatible with
existing deployments. Where possible, existing control
and management plane protocols must be used within existing
architectures to implement the SPRING function. Any
modification of or extension to existing architectures,
data planes, or control or management plane protocols must be carried out
in the
working groups responsible for the architecture, data
plane, or control or management plane protocol being modified and in
co-ordination
with this working group.  The work may be done in this
working group after agreement with all the relevant
WG chairs and responsible Area Directors.

The SPRING working group is chartered for the following
list of items:

o Identification and evaluation of use cases for SPRING .
  These use cases must include a definition of the
  data plane for the environment in which they are to be
  deployed.

 o Definition of requirements and/or any new data plane encodings and
   procedures, required to implement the use cases. Such
   procedures must include the necessary security
   considerations.

 o Definition of requirements and/or any new control plane mechanism
   needed to enable the use cases.

o Definition of requirements and/or management  plane mechanism needed to
  manage and operate a SPRING enabled network.

Changes:  

1. The text in the 8th paragraph seemed to use "protocols" to refer to
both "control plane" and "management plane" protocols, so I explicitly
mentioned "control and management plane" to avoid any confusion and make
it consistent with the rest of the text.

2. Split the last sentence in the 8th paragraph for readability.
3. The chartered items now read: "Definition of requirements and/or new.."
to account for both cases of the work being done somewhere else or in this
WG.
4. Took out the "in conjunction" sentence because the 8th paragraph
already tells us what to do.

Alvaro.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 01 Oct 2013 13:53:36 +0100

> extension of IGPs to gain MPLS topology awareness for all nodes
My interpretation of the words is yes. If SPRING considers
that to the the best approach, then, subject only to
the rules about how they work with other WGs, they
are free to pursue the lables in IGP mechanism and/or
any other reasonable approach that addresses the
use cases.

Stewart
> .

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 01 Oct 2013 14:04:59 +0100

I have updated the text in line with this suggestion.

I think that this now makes it unambiguous how
SPRING will engage with other WGs.

Stewart

---

From: <[email-masked]>
Date: Wed, 2 Oct 2013 09:34:27 +0200

Stewart, Alvaro,

thanks again for the effort. I think, the draft is good as it is.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, October 01, 2013 3:05 PM
To: Alvaro Retana (aretana)
Cc: [email-masked]; Loa Andersson
Subject: Re: [Status] Updated charter - version 3 and maybe 4

Stewart