Subject: [Status] Chartering next steps

From: Stewart Bryant <[email-masked]>
Date: Fri, 20 Sep 2013 10:28:24 +0100

This note is a summary of where we are with chartering the
work that we are discussing on the STATUS list and
the next steps.

Firstly, as you know we (the ADs) had concerns with the
name "STATUS" being confusing. Having considered quite
a lot of possibilities, and not wanting the discussion
to bog down on a name,  Adrian and I have decided
that the name Source Packet Routing in NetworkinG is
as good as any. Thus SPRING is name that we are using
in the charter process and is that I am putting in the
data-tracker for formal processing.

Propose to start with the charter text that John Scudder
posted on 17/Sept with the following changes:

s/<TBD>/SPRING/

I removed "ordered" from ordered list, as I think there
was a consensus to do so in the following emails in
the thread.

I have not changed the state text, as I could not see
a consensus on what if any change I should make.

The charter is uploaded at

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

What we now need the list members to do is to propose
any necessary changes to the text, and I will reflect
the consensus of the group in revised charter text.
The differences in the version of the charter text will
be visible through the datatracker charter diff tool.

For continuity, discussion will continue on the STATUS
list until we have a chartered WG, at which point the
Secretariat will switch us over.

For reference the text I uploaded is as follows:

Name: Source Packet Routing in Networking (SPRING)

The SPRING working group will define procedures that will allow
a node to steer a packet between any source and destination through
a SPRING region on any path without requiring state to be
maintained by transited nodes, but rather at the source device.  A
SPRING 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 SPRING region is trusted to steer
a packet through any of the other nodes within the region. The
SPRING 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 SPRING 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 SPRING working group is chartered for the following 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 SPRING
   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 SPRING 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 SPRING working group.

The working group will develop the following documents:

o One or more documents describing SPRING use cases,
o Specification of new procedures to support SPRING 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 SPRING.

Please review and propose changes you think are necessary to the
list.

- Stewart

---

From: Loa Andersson <[email-masked]>
Date: Fri, 20 Sep 2013 13:29:42 +0200

Stewart,

SPRING is a nice name :).

The only thing that I don't find clear in this charter is
whether to specify modifications to the data planes and architectures
or if the group is supposed to act as a source for requirements for
such changes.

I hope we can agree to see SPRING as source for requirements for
modification where the data plane and architecture has been developed
by another active working group.

/Loa

On 2013-09-20 11:28, Stewart Bryant wrote:
> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

-- 

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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 20 Sep 2013 13:39:09 +0100

Hi Loa,

That is a good point, here is some text that might be considered for 
inclusion:

"Where possible, existing protocols must be used to implement the SPRING 
function. Any modification or extension of existing architectures or 
protocols must be carried out in the working groups responsible for the 
architectures or protocols being modified 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 ADs."

A good place to put this would be before: "The SPRING working group is 
chartered for the following list of items: "

Would this address your concern?

Stewart

-- 
For corporate legal information go to:

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

---

From: Pierre Francois <[email-masked]>
Date: Fri, 20 Sep 2013 14:53:26 +0200

Stewart,

It is already in John's text. At the end he writes that the work impacting protocols will be carried out in their respective working groups.

Cheers,

Pierre.

Sent from my iPhone

On Sep 20, 2013, at 2:39 PM, Stewart Bryant <[email-masked]> wrote:

> Hi Loa,
> 
> That is a good point, here is some text that might be considered for inclusion:
> 
> "Where possible, existing protocols must be used to implement the SPRING function. Any modification or       extension of existing architectures or protocols must be carried out in the working groups responsible for the architectures or protocols being modified 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 ADs."
> 
> A good place to put this would be before: "The SPRING working group is chartered for the following list of items: "
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 20 Sep 2013 14:17:42 +0100

Pierre

The last version of the charter that I pulled from the list
says:

   Where such

That is not as prescriptive as either your snippet, or mine, and Loa 
raised a concern.

What do others think?

Stewart

On 20/09/2013 13:53, Pierre Francois wrote:
> .

---

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

This is the text from my originally proposed charter:

. The WG will work on the definition of the architecture and protocol 
  extensions. No new protocol specification is expected within this WG. 
  No MPLS data-plane changes are expected either.

. Instead the standardization work should consist in extensions in well 
  established protocols (ISIS, OSPF, BGP, PCEP, ...).

. It is expected that the SEGROUTE WG will help in the orchestration 
  of protocol extensions specification with the existing IETF Working 
  Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...).

s.

On Sep 20, 2013, at 3:17 PM, Stewart Bryant wrote:

> That is not as prescriptive as either your snippet, or mine, and Loa raised a concern.
> 
> What do others think?
> 
> Stewart
>

---

From: John E Drake <[email-masked]>
Date: Fri, 20 Sep 2013 13:42:22 +0000

Hi,

I prefer Stewart's text.

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stefano Previdi (sprevidi)
> Sent: Friday, September 20, 2013 6:38 AM
> To: Stewart Bryant (stbryant)
> Cc: Pierre Francois; [email-masked]; Loa Andersson
> Subject: Re: [Status] Chartering next steps
> 
> >  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 SPRING working group.
> >
> >> It is already in John's text. At the end he writes that the work impacting
> protocols will be carried out in their respective working groups.
> >>
> >> Cheers,
> >>
> >> Pierre.
> >>
> >> Sent from my iPhone
> >>
> >>> "Where possible, existing protocols must be used to implement the
> SPRING function. Any modification or       extension of existing architectures
> or protocols must be carried out in the working groups responsible for the
> architectures or protocols being modified 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 ADs."
> >>>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 20 Sep 2013 14:50:26 +0100

Stef

Specification by partial list always gives problems. WGs
come and go, new protocols are noticed that need
changing. Much better for a charter to state a principle
that is likely to be true regardless of the IETF structure.

So, if you compare your text to mine, what operational
issue do you see arising that yours catches?

- Stewart

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 20 Sep 2013 13:56:47 +0000

>What do others think?

FWIW, I like the prescriptive nature of the text you proposed.

Thanks!

Alvaro.

>>>SPRING function. Any modification or       extension of existing
>>>architectures or protocols must be carried out in the working groups
>>>responsible for the architectures or protocols being modified 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
>>>ADs."
>>>

---

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

> that is likely to be true regardless of the IETF structure.

yes, the name of the WG was just as example (and not exhaustive) 
but in order not to hurt anyone sensibility, I'd agree with your 
text.

s.

---

From: Lou Berger <[email-masked]>
Date: Fri, 20 Sep 2013 10:00:52 -0400

Stewart,
	A comment and a question:
- You say:
  any path without requiring state to be maintained by transited nodes

I think it would be worth clarifying that no "per-path state" is
required to be maintained. The extensions eluded to below will certainly
control/install state per node, just not per path.

- You say:
  any node in the SPRING region is trusted to steer a packet
  through any of the other nodes within the region.

To me this limits "steering", and perhaps steering identifiers, to the
node level. Is steering at the interface/link level now excluded?  The
text should be clear that this is in scope.

Thanks,
Lou

---

From: Rob Shakir <[email-masked]>
Date: Fri, 20 Sep 2013 16:47:48 +0100

Hi Lou,

> control/install state per node, just not per path.

I think this is correct :-)

> text should be clear that this is in scope.

The previous wording that we had here is quoted below:

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

Thanks for picking up that this has changed somewhat -- I would suggest that we amend the wording to "Any node in the SPRING region is trusted to steer a packet along any path within the region" -- which allows for the possibility of the path being of identifiers which refer to nodes/links/subtopologies etc.

Kind regards,
r.

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 20 Sep 2013 12:01:27 -0700

> control/install state per node, just not per path.

That is an important distinction. Maybe worthwhile to be explicit that this
is applicable both to control and data plane state.

> text should be clear that this is in scope.

This could be worded as "steer a packet along an explicit path". That
should cover both.

---

From: Lou Berger <[email-masked]>
Date: Fri, 20 Sep 2013 15:42:27 -0400

Sriganesh,

See below.

On 9/20/2013 3:01 PM, Sriganesh Kini wrote:
> 
> 
> 
> On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Stewart,
> That is an important distinction. Maybe worthwhile to be explicit that
> this is applicable both to control and data plane state.
>  
> 
> 
>     - You say:

I think this overloads path by having it refer to an end-to-end
construct (e.g., shortest, non-shortest, explicit, ... ) and an
interface/segment construct.

How about "along an explicit route"?

Lou

>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 20 Sep 2013 13:05:46 -0700

I agree Lou. Your wording seems fine to me.

---

From: John E Drake <[email-masked]>
Date: Fri, 20 Sep 2013 20:17:35 +0000

Snipped, comment inline.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Friday, September 20, 2013 12:01 PM
To: Lou Berger
Cc: [email-masked]; [email-masked]; Stewart Bryant (stbryant)
Subject: Re: [Status] Chartering next steps

On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
Stewart,

That is an important distinction. Maybe worthwhile to be explicit that this is applicable both to control and data plane state.

- You say:

This could be worded as "steer a packet along an explicit path". That should cover both.

[JD]  We should probably use the RFC 3031 terminology so we should say “steer a packet along an explicit route through the SPRING region”.

Thanks,
Lou

---

From: Loa Andersson <[email-masked]>
Date: Mon, 23 Sep 2013 12:02:54 +0800

Stewart,

I think the proposed text is fine and would be a nice addition.

However, ....

What really concerns me is that there is a slight ambiguity in the list
that the SPRIBNG working group will be chartered for.

Propose that we change:

OLD

NEW
o Determine whether the above mentioned procedures require
   modification/changes to the existing MPLS architecture, and
   if so, then document requirements for such modifications/changes.
o Determine whether the above mentioned procedures require
   modification/changes to the existing IPv6 architecture, and
   if so, then document requirements for such modifications/changes.

OLD

NEW
o Requirements for changes to MPLS architecture, if needed
o Requirements for changes to IPv6 architecture, if needed

/Loa

On 2013-09-20 20:39, Stewart Bryant wrote:
>>> will

--

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Sep 2013 14:12:55 +0100

I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

The diffs are at

https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt

or if you prefer:

*http://tinyurl.com/o24a9lz*

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 23 Sep 2013 13:16:28 +0000

If we go deeper in the charter text discussion we'll end up defining the details of the solution...

s.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Stewart Bryant (stbryant) [[email-masked]]
Received: Monday, 23 Sep 2013, 15:13
To: [email-masked] [[email-masked]]
Subject: Re: [Status] Chartering next steps

The diffs are at

or if you prefer:

http://tinyurl.com/o24a9lz

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Sep 2013 14:36:33 +0100

I can take that text out if people wish.

One purpose that it serves is to educate those reviewing the charter 
that have not been following the detail.

I have also updated the BoF placeholder, and this can be found at:

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

Note that the purpose of the draft list is partially to educate people 
about the subject area and partially to demonstrate that the IETF has 
the energy work on this. I thus hoovered up all the relevant drafts, and 
make no comment about order, or priority, or which will be pursued and 
which will be dropped. If I missed any that was accidental.

- Stewart

On 23/09/2013 14:16, Stefano Previdi (sprevidi) wrote:
> *From:* Stewart Bryant (stbryant) [[email-masked]]
> *Received:* Monday, 23 Sep 2013, 15:13
> *To:* [email-masked] [[email-masked]]
> *Subject:* Re: [Status] Chartering next steps
>

---

From: John E Drake <[email-masked]>
Date: Mon, 23 Sep 2013 13:36:40 +0000

Stewart,

This looks fine.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: [email-masked]
Subject: Re: [Status] Chartering next steps

The diffs are at

or if you prefer:

- Stewart

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 23 Sep 2013 13:53:01 +0000

Seems reasonable to me too.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 9:37 AM
To: [email-masked]
Cc: Stefano Previdi (sprevidi)
Subject: Re: [Status] Chartering next steps

One purpose that it serves is to educate those reviewing the charter that have not been following the detail.

Note that the purpose of the draft list is partially to educate people about the subject area and partially to demonstrate that the IETF has the energy work on this. I thus hoovered up all the relevant drafts, and make no comment about order, or priority, or which will be pursued and which will be dropped. If I missed any that was accidental.

- Stewart

s.

Sent from my Android phone using TouchDown (www.nitrodesk.com<http://www.nitrodesk.com>)

-----Original Message-----
From: Stewart Bryant (stbryant) [[email-masked]<mailto:[email-masked]>]
Received: Monday, 23 Sep 2013, 15:13
To: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
Subject: Re: [Status] Chartering next steps

The diffs are at

https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt<https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go%21&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt>

or if you prefer:

- Stewart

--

---

From: John E Drake <[email-masked]>
Date: Mon, 23 Sep 2013 15:01:41 +0000

Stewart,

Upon reflection, I spoke too soon.  The use of the term 'explicit route' as suggested by Lou and myself is fine, but the sentence you added:

"Steering is achieved by specifying in the packet an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet."

has issues.  A packet *will not* have contain an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet, rather it will have a set of identifiers specifying resources within a SPRING region, and these specified resources *are not* limited to "nodes and/or links and/or shortest-path-next-hops"; they may also include, for example, forwarding adjacencies and services.

I suggest that we strike the sentence.  As Stefano points out, a charter is not a design specification.

Yours Irrespectively,

John

The diffs are at

or if you prefer:

- Stewart

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 23 Sep 2013 15:08:51 +0000

John,

To me, the text is ok as proposed in last email from Stewart. My comment applies more on your last comment.

s.

--
Sent from a device pretending to be smart.

-----Original Message-----
From: John E Drake [[email-masked]]
Received: Monday, 23 Sep 2013, 17:02
To: Stewart Bryant (stbryant) [[email-masked]]; [email-masked] [[email-masked]]
Subject: Re: [Status] Chartering next steps

Stewart,

Upon reflection, I spoke too soon.  The use of the term ‘explicit route’ as suggested by Lou and myself is fine, but the sentence you added:

“Steering is achieved by specifying in the packet an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet.”

has issues.  A packet *will not* have contain an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet, rather it will have a set of identifiers specifying resources within a SPRING region, and these specified resources *are not* limited to “nodes and/or links and/or shortest-path-next-hops”; they may also include, for example, forwarding adjacencies and services.

Yours Irrespectively,

John

The diffs are at

or if you prefer:

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Sep 2013 17:26:10 +0100

Maybe I will take the sentence out, because there
is more to identifiers than next hops. For example,
a PW label, which we may find on the stack, is an
instruction (decap, munge and sent to an interface),
so the concern is that the text might be unnecessarily
constraining which would outweigh its utility as
tutorial material.

Stewart

On 23/09/2013 16:01, John E Drake wrote:
>
> Stewart,
>
> Upon reflection, I spoke too soon.  The use of the term 'explicit 
> route' as suggested by Lou and myself is fine, but the sentence you added:
>
> "Steering is achieved by specifying in the packet an ordered set of 
> nodes and/or links and/or shortest-path-next-hops to be traversed by 
> the packet."
>
> has issues.  A packet **will not** have contain an ordered set of 
> nodes and/or links and/or shortest-path-next-hops to be traversed by 
> the packet, rather it will have a set of identifiers specifying 
> resources within a SPRING region, and these specified resources **are 
> not** limited to "nodes and/or links and/or shortest-path-next-hops"; 
> they may also include, for example, forwarding adjacencies and services.
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Stewart Bryant
> *Sent:* Monday, September 23, 2013 6:13 AM
> *To:* [email-masked]
> <https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go%21&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt>
>
> or if you prefer:
>

---

From: John E Drake <[email-masked]>
Date: Mon, 23 Sep 2013 17:43:31 +0000

Sent from my iPhone

On Sep 23, 2013, at 12:27 PM, "Stewart Bryant" <[email-masked]<mailto:[email-masked]>> wrote:

Stewart

Yours Irrespectively,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Status] Chartering next steps

The diffs are at

or if you prefer:

- Stewart

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

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 23 Sep 2013 10:44:03 -0700

>From RFC 3031, sec 3.21

   Explicit routing may be useful for a number of purposes, such as
   policy routing or traffic engineering.  In MPLS, the explicit route
   needs to be specified at the time that labels are assigned, but the
   explicit route does not have to be specified with each IP packet.
   This makes MPLS explicit routing much more efficient than the
   alternative of IP source routing.

If the "explicit-route" in SPRING is the same as explicit-route in RFC3031
then we are ruling out source-routing ! IMO we should call it
explicit-route but re-define it for SPRING. The definition could be "a set
of identifiers in the packet that allow it to be steered through the
network without having per flow information at each intermediate node".
However this re-definition need not be in the charter but could go in
another document (architecture document).

- Sri

On Mon, Sep 23, 2013 at 8:01 AM, John E Drake <[email-masked]> wrote:

>  Stewart,****
>
> ** **
>
> Upon reflection, I spoke too soon.  The use of the term ‘explicit route’
> as suggested by Lou and myself is fine, but the sentence you added:****
>
> ** **
>
> “Steering is achieved by specifying in the packet an ordered set of nodes
> and/or links and/or shortest-path-next-hops to be traversed by the packet.”
> ****
>
> ** **
>
> has issues.  A packet **will not** have contain an ordered set of nodes
> and/or links and/or shortest-path-next-hops to be traversed by the packet,
> rather it will have a set of identifiers specifying resources within a
> SPRING region, and these specified resources **are not** limited to
> “nodes and/or links and/or shortest-path-next-hops”; they may also include,
> for example, forwarding adjacencies and services.****
>
> ** **
>
> I suggest that we strike the sentence.  As Stefano points out, a charter
> is not a design specification. ****
>
> ** **
>
> Yours Irrespectively,****
>
> ** **
>
> John****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> *Subject:* Re: [Status] Chartering next steps****
>
>  ** **
>
> - Stewart****

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 19:50:22 +0200

The observation is that SR may not require explicit-route in all
scenarios. I can see cases of loose-routes yet based on segment based
routing paradigm.

Besides explicit route may be interpreted as hop-by-hop path which is
clearly not the case.

I would recommend to s/explicit route/defined path/

r.

On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini
<[email-masked]> wrote:
> then we are ruling out source-routing ! IMO we should call it explicit-route
> but re-define it for SPRING. The definition could be "a set of identifiers
> in the packet that allow it to be steered through the network without having
> per flow information at each intermediate node". However this re-definition
> need not be in the charter but could go in another document (architecture
> document).
>
> - Sri
>
>
>
>> as suggested by Lou and myself is fine, but the sentence you added:
>>
>>
>>
>> has issues.  A packet *will not* have contain an ordered set of nodes
>> SPRING region, and these specified resources *are not* limited to “nodes
>> and/or links and/or shortest-path-next-hops”; they may also include, for
>> example, forwarding adjacencies and services.
>>
>>
>>
>> is not a design specification.
>>
>>
>>
>> Yours Irrespectively,
>>
>>
>>
>> John
>>
>>
>>
>> Of Stewart Bryant

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 23 Sep 2013 18:02:19 +0000

Robert,

MPLS has defined "strict", "loose" and combinations of those in the
context of "explicit-routes". SPRING should be able to re-use/re-define it
as necessary.

Interpreting "explicit-route" as "hop-by-hop" seems like a stretch.

I don't see a strong reason for yet another term "defined path".

-- Sri

On 9/23/13 10:50 AM, "Robert Raszuk" <[email-masked]> wrote:

>>explicit-route
>>> Upon reflection, I spoke too soon.  The use of the term Œexplicit
>>>route¹
>>> ³Steering is achieved by specifying in the packet an ordered set of
>>>nodes
>>> and/or links and/or shortest-path-next-hops to be traversed by the
>>>packet.²
>>>
>>>
>>>
>>> SPRING region, and these specified resources *are not* limited to
>>>³nodes
>>> and/or links and/or shortest-path-next-hops²; they may also include,
>>>for
>>>https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fd
>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&subm
>>>it=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spri
>>>ng%2Fwithmilestones-00-01.txt
>>>
>>> or if you prefer:
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 20:04:37 +0200

But SPRING is not only about MPLS encapsulation ..

r.

On Mon, Sep 23, 2013 at 8:02 PM, Sriganesh Kini
<[email-masked]> wrote:
>>>>packet,

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 23 Sep 2013 18:05:24 +0000

Agree with Sri.
Strict and loose explicit routes define pretty well what SPRING does

Cheers,
Jeff

-----Original Message-----
From: Sriganesh Kini <[email-masked]>
Date: Monday, September 23, 2013 11:02 AM
To: "[email-masked]" <[email-masked]>
Cc: John Drake <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

---

From: Lou Berger <[email-masked]>
Date: Mon, 23 Sep 2013 14:07:43 -0400

Right. And RFC3031 isn't listed in the charter.

So I agree with Sri.

Lou

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 20:08:45 +0200

Hi Jeff,

If I want to use SPRING to get rid of LDP between my ingress and
egress PEs what is my "explicit-route" in that case ?

r.

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 23 Sep 2013 18:28:38 +0000

Hi Robert,

List of Node-SID's (loose), Adj-SID's optionally (strict)

Cheers,
Jeff

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, September 23, 2013 11:08 AM
To: Jeff Tantsura <[email-masked]>
Cc: Sriganesh Kini <[email-masked]>, John Drake
<[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [Status] Chartering next steps

>>>>>>https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%
>>>>>>2F
>>>>>>d
>>>>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&s
>>>>>>ub
>>>>>>m
>>>>>>it=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-s
>>>>>>pr
>>>>>>i

---

From: John E Drake <[email-masked]>
Date: Mon, 23 Sep 2013 19:14:20 +0000

Sri,

I completely agree.

Yours Irrespectively,

John

> From: Sriganesh Kini [mailto:[email-masked]]
> Sent: Monday, September 23, 2013 11:02 AM
> To: Robert Raszuk
> Cc: John E Drake; [email-masked]; [email-masked]
> MPLS has defined "strict", "loose" and combinations of those in the context
> of "explicit-routes". SPRING should be able to re-use/re-define it as
> necessary.
> 
> >>explicit-route  but re-define it for SPRING. The definition could be
> >>"a set of identifiers  in the packet that allow it to be steered
> >>through the network without having  per flow information at each
> >>intermediate node". However this re-definition  need not be in the
> >>charter but could go in another document (architecture  document).
> >>
> >> - Sri
> >>
> >>
> >>
> >>>route¹  as suggested by Lou and myself is fine, but the sentence you
> >>>added:
> >>>
> >>>
> >>>
> >>>the packet.²
> >>> has issues.  A packet *will not* have contain an ordered set of
> >>>resources within a  SPRING region, and these specified resources *are
> >>>not* limited to ³nodes  and/or links and/or shortest-path-next-hops²;
> >>>2Fd
> >>>ubm
> >>>pri

---

From: John E Drake <[email-masked]>
Date: Mon, 23 Sep 2013 19:14:40 +0000

And your point is?

Yours Irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> Raszuk
> Sent: Monday, September 23, 2013 11:05 AM
> To: Sriganesh Kini
> > context of "explicit-routes". SPRING should be able to
> > re-use/re-define it as necessary.
> >

---

From: John E Drake <[email-masked]>
Date: Mon, 23 Sep 2013 19:17:50 +0000

Directions, at a given level of detail, for getting from the ingress node to the egress node. 

Yours Irrespectively,

John

> Sent: Monday, September 23, 2013 11:09 AM
> To: Jeff Tantsura
> Cc: Sriganesh Kini; John E Drake; [email-masked]; [email-masked]
> If I want to use SPRING to get rid of LDP between my ingress and egress PEs
> what is my "explicit-route" in that case ?
> 
> r.
> 
> > Cc: John Drake <[email-masked]>, "[email-masked]"
> > <[email-masked]>, "[email-masked]" <[email-masked]>
> >>>>>route¹  as suggested by Lou and myself is fine, but the sentence
> >>>>>you added:
> >>>>>
> >>>>>
> >>>>>
> >>>>> ³Steering is achieved by specifying in the packet an ordered set
> >>>>>of nodes  and/or links and/or shortest-path-next-hops to be
> >>>>>traversed by the packet.²
> >>>>>
> >>>>>
> >>>>>
> >>>>>nodes  and/or links and/or shortest-path-next-hops to be traversed
> >>>>>by the packet,  rather it will have a set of identifiers specifying
> >>>>>resources within a  SPRING region, and these specified resources
> >>>>>*are not* limited to ³nodes  and/or links and/or
> >>>>>shortest-path-next-hops²; they may also include, for  example,
> >>>>>forwarding adjacencies and services.
> >>>>>
> >>>>>
> >>>>>
> >>>>>https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.o
> r
> >>>>>g%2F
> >>>>>d
> >>>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--
> html
> >>>>>&sub
> >>>>>m
> >>>>>it=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-
> ietf
> >>>>>-spr
> >>>>>i
> >>>>> "Steering is achieved by specifying in the packet an ordered set
> >>>>> of nodes and/or links and/or shortest-path-next-hops to be
> >>>>> traversed by the packet."
> >>>>>
> >>>>> - Stewart
> >>>>>
> >>>>>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 21:43:17 +0200

Such "directions" in the application of removing need for LDP for
unicast traffic are computed by OSPF/ISIS SPF.

Rgs,
R.

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 23 Sep 2013 13:07:53 -0700

If that is your application, then the (loose) explicit-route is the
shortest-path. In case of MPLS-SPRING the source will push a label that
results in the packet going along the shortest-path.

---

From: John E Drake <[email-masked]>
Date: Mon, 23 Sep 2013 20:53:42 +0000

You're getting the hang of this.

Sent from my iPhone

> On Sep 23, 2013, at 3:43 PM, "Robert Raszuk" <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 23 Sep 2013 22:53:59 +0200

Last email on this ...

rfc3031 says:

      -  Sometimes it is desirable to force a packet to follow a
         particular route which is explicitly chosen at or before the
         time the packet enters the network, rather than being chosen by
         the normal dynamic routing algorithm as the packet travels
         through the network.

My example application is to use normal dynamic routing algorithm
which based on the above text does not fall under term of "explicit"
it is neither loose ERO or strict ERO - there is no ERO.

Best,
R.

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 23 Sep 2013 21:06:16 +0000

Robert, as has been said on the list before, RFC 3031 is not listed in the
charter. But there are definitions in it that are useful to be adapted for
SPRING. 

-- Sri

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 24 Sep 2013 01:03:29 +0200

> it is neither loose ERO or strict ERO - there is no ERO.

there is always an ERO.
for hop-by-hop LSPs the ERO admittedly is as 'loose' as 'loose' can get -
which is consisting of a single 'loose' hop denominating the egress point.

just ask yourself how is e.g. 
a RSVP/SR LSP: 192.168.1.1 'L' ERO different than 
a LDP LSP: FEC 192.168.1.1 ?

/hannes

---

From: <[email-masked]>
Date: Tue, 24 Sep 2013 08:40:02 +0200

Hannes, all,

thanks for pointing out. I think SPRING's objective is to enhance hop-by-hop routing to additionally allow explicit routing without state maintainance at transit nodes.

Robert indicated, that changes in routing protocols required by SPRING are not limited to features required to set up such explicit routes. And he's absolutely correct with that.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Gredler
Sent: Tuesday, September 24, 2013 1:03 AM
To: Robert Raszuk
Cc: John E Drake; [email-masked]; [email-masked]; Jeff Tantsura; Sriganesh Kini
Subject: Re: [Status] Chartering next steps

there is always an ERO.

/hannes

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 24 Sep 2013 11:00:02 +0100

A one hop loose source route with the next hop = the egress PE.

Stewart

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 24 Sep 2013 14:12:08 +0200

On Tue, Sep 24, 2013 at 08:40:02AM +0200, [email-masked] wrote:
| thanks for pointing out. I think SPRING's objective is to enhance hop-by-hop routing to additionally allow explicit routing without state maintainance at transit nodes.

my read is that it its the other way around.
there is enough exisiting protocols which support hop-by-hop routing. 

what i am looking for the spot which is not covered by 
existing protocols (read: explicit routing at scale,
w/o tracking midpoint state)

| Robert indicated, that changes in routing protocols required by SPRING are not limited to features required to set up such explicit routes. And he's absolutely correct with that.

thats fine - note that in all the exisiting IGP MPLS drafts there is both support for
explicit routes and hop-by-hop LSPs, mostly to avoid T-LDP sessions
such that you can learn transport labels from non adjacent routers.

/hannes

| 
| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Gredler
| Sent: Tuesday, September 24, 2013 1:03 AM
| To: Robert Raszuk
| Cc: John E Drake; [email-masked]; [email-masked]; Jeff Tantsura; Sriganesh Kini
| Subject: Re: [Status] Chartering next steps
| 
| 
| On Sep 23, 2013, at 10:53 PM, Robert Raszuk wrote:
| 
| > Last email on this ...
| >
| > rfc3031 says:
| >
| >      -  Sometimes it is desirable to force a packet to follow a
| >         particular route which is explicitly chosen at or before the
| >         time the packet enters the network, rather than being chosen by
| >         the normal dynamic routing algorithm as the packet travels
| >         through the network.
| >
| > My example application is to use normal dynamic routing algorithm
| > which based on the above text does not fall under term of "explicit"
| > it is neither loose ERO or strict ERO - there is no ERO.
| 
| there is always an ERO.
| for hop-by-hop LSPs the ERO admittedly is as 'loose' as 'loose' can get -
| which is consisting of a single 'loose' hop denominating the egress point.
| 
| just ask yourself how is e.g.
| a RSVP/SR LSP: 192.168.1.1 'L' ERO different than
| a LDP LSP: FEC 192.168.1.1 ?
| 
| /hannes
| 
| 
| _______________________________________________
| status mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/status
| 
|

---

From: <[email-masked]>
Date: Wed, 25 Sep 2013 08:32:38 +0200

Hannes,

please explain your point.

Regards,

Ruediger

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]]

Means we've solved all hop-by-hop and ER issues by the existing protocols and you don't see a point in any SPRING related activity?

Yes, and you are one of the authors. If you believe there's no spot covered by existing protocols, why are you entertaining drafts related to SPRING?

If all spots are covered: which single existing protocol detects a domain's complete MPLS topology coupled with IGP topology and utilisation of the MPLS topology discovered that way for routing at a source node?

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 25 Sep 2013 11:02:15 +0200

> Means we've solved all hop-by-hop and ER issues by the existing protocols and you don't see a point in any SPRING related activity?

what i am looking in SPRING is to augment the protocol stack with
semantics which do not yet exist. as a counter-example introducing IGP
advertised hop-by-hop labels (just to replace LDP for transport
labels is redundant) and as such rather uninteresting.

however there are use cases which require transport labels to be learned
from non-adjacecnt routers. (e.g. R-LFA, R-LFA+DF) and IGP
disseminated labels would fix that problem just nice.

> Yes, and you are one of the authors. If you believe there's no spot covered by existing protocols, why are you entertaining drafts related to SPRING?

today no protocol supports learning of labels from non-adjacent neighbors,
like we need it in R-LFA and R-LFA+DF - so the 'workaround' is
to dynamically bring up LDP sessions which is arguably a bit more expensive
as you cannot construct R-LFA backup paths in s "single pass",
after initial PQ set calculation you always need to wait until the
T-LDP labels from the PQ neighbors have been learned.

upon major topology changes this translates into twice the forwarding table
updates, twice the BGP route resolver dependency checking, etc.

the 'segment routing extensions' draft and the 'label in IGP drafts 
which i co-authored, fix that specific problem by allowing to calculate/update
backup paths in a "single pass".

> If all spots are covered: which single existing protocol detects a domain's complete MPLS topology coupled with IGP topology and utilisation of the MPLS topology discovered that way for routing at…

the cardinal mistake in here seems to me is the desire to have a 'single protocol'.

as no protocol has the sum of properties of all the other protocols,
there will be always a 'plurality' of protocols.

IOW just because we introduce hop-by-hop labels and explicit routes in the IGP
does not imply that neither LDP, RSVP nor BGP-LU is going away.
at best we may see some shift of functionality from protocol X to protocol Y.

hope that clarifies,

/hannes