Subject: Re: [Status] Summary of STATUS BOF and the next steps

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 01 Sep 2013 11:38:04 -0400

All,

I would also favour "Segment Routing WG" as well.

I note this since attempting to come up with an all encompassing acronym
will be difficult and Segment Routing is generic enough to associate to
multiple functions.

Regards,

Victor K

On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" <[email-masked]>
wrote:

>+1 for Segment Routing WG
>
>Roberta
>
>Sent from my iPad
>
>On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" <[email-masked]>
>wrote:
>
>> Segment Routing WG
>> 
>> Sent from my iPhone
>> 
>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)"
>><[email-masked]> wrote:
>> 
>>> The second task, which hopefully should be relatively easy,
>>> is to find a better working name for the WG, since it has
>>> been put to me a number of times that STATUS is going to
>>> be confusing in text and a difficult search term.
>> _______________________________________________
>> 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: Mark Townsley <[email-masked]>
Date: Sun, 1 Sep 2013 19:07:55 +0200

> will be difficult and Segment Routing is generic enough to associate to

Then we can just use "segroute" for the short name. WGs do not have to have acronyms, but they do need to have an 8-char limited short name for the various automated tools not to break.

- Mark

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Sep 2013 13:02:01 +0000

Hi,

What is this 'segment routing' silliness?  The correct term is 'source routing'. 

Yours Irrespectively,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mark Townsley
> Sent: Sunday, September 01, 2013 10:08 AM
> To: Victor Kuarsingh
> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
> (aretana); [email-masked]; Stewart Bryant (stbryant)
> Subject: Re: [Status] Summary of STATUS BOF and the next steps
> 
> 
> > I note this since attempting to come up with an all encompassing
> > acronym will be difficult and Segment Routing is generic enough to
> > associate to multiple functions.
> 
> Then we can just use "segroute" for the short name. WGs do not have to
> have acronyms, but they do need to have an 8-char limited short name for
> the various automated tools not to break.
> 
> - Mark
> 
> >
> > Regards,
> >
> > Victor K
> >
> >
> >
> >>>> The second task, which hopefully should be relatively easy, is to
> >>>> find a better working name for the WG, since it has been put to me
> >>>> a number of times that STATUS is going to be confusing in text and
> >>>> a difficult search term.

---

From: <[email-masked]>
Date: Tue, 3 Sep 2013 15:06:38 +0200

Hi,

"Source routing" is just a subcase of segment routing ... as it is for IP routing ...

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de John E Drake
Envoyé : mardi 3 septembre 2013 15:02
À : Mark Townsley; Victor Kuarsingh
Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
Objet : Re: [Status] Summary of STATUS BOF and the next steps

Hi,

Yours Irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mark Townsley
> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro 
> Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
> have acronyms, but they do need to have an 8-char limited short name 
> for the various automated tools not to break.
> 
> - Mark
> 
> >
> > Regards,
> >
> > Victor K
> >
> >
> >
> >>>> find a better working name for the WG, since it has been put to 
> >>>> me a number of times that STATUS is going to be confusing in text 
> >>>> and a difficult search term.

_________________________________________________________________________________________________________________________

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: John E Drake <[email-masked]>
Date: Tue, 3 Sep 2013 13:31:41 +0000

Stephane,

I don't see anything in the segment routing architecture I-D that justifies your assertion.

Yours Irrespectively,

John

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 6:07 AM
> To: John E Drake; Mark Townsley; Victor Kuarsingh
> Cc: Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana);
> Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
> Subject: RE: [Status] Summary of STATUS BOF and the next steps
> 
> Hi,
> 
> De : [email-masked] [mailto:[email-masked]] De la part de
> John E Drake Envoyé : mardi 3 septembre 2013 15:02 À : Mark Townsley;
> Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro
> Retana (aretana); Adrian Farrel; [email-masked]; Stewart Bryant (stbryant)
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 03 Sep 2013 14:33:02 +0100

Stephane

That is not correct. A long time ago there was source routed transparent 
which was a token ring technology.

Stewart

On 03/09/2013 14:06, [email-masked] wrote:
> .

-- 
For corporate legal information go to:

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

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Sep 2013 13:32:32 +0000

Excellent.

Yours Irrespectively,

John

> From: AshwoodsmithPeter [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2013 6:27 AM
> To: [email-masked]
> Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione
> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);
> [email-masked]; Stewart Bryant (stbryant)
> The term "source routing" has been around for a very long time and is data
> path agnostic. Its also the term used in the literature etc so my preference is
> to stick with this existing well known and data path agnostic term.
> 
> Peter
> 
> On Sep 3, 2013, at 9:07 AM, "[email-masked]"
> <[email-masked]> wrote:
> 
> > Hi,
> >
> > De : [email-masked] [mailto:[email-masked]] De la
> > part de John E Drake Envoyé : mardi 3 septembre 2013 15:02 À : Mark
> > Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
> > Scudder; Alvaro Retana (aretana); Adrian Farrel; [email-masked];
> > Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF
> > and the next steps
> >
> > Hi,
> >
> >> Then we can just use "segroute" for the short name. WGs do not have
> >> to have acronyms, but they do need to have an 8-char limited short
> >> name for the various automated tools not to break.
> >>
> >> - Mark
> >>
> >>>
> >>> Regards,
> >>>
> >>> Victor K
> >>>
> >>>
> >>>
> ____________
> > ___________________________________________________
> >
> > 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,
> > 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.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 3 Sep 2013 13:27:15 +0000

The term "source routing" has been around for a very long time and is data path agnostic. Its also the term used in the literature etc so my preference is to stick with this existing well known and data path agnostic term.

Peter

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 3 Sep 2013 13:41:22 +0000

There was a lot of work on source routing mechanisms independent of IP. One rather cool example was a mechanism for routing through a constellation of polar orbit satellites. Geodesic I think it was called. There were also a number of other non IP proprietary source routing protocols deployed too. Anyway I agree that the term is generic and not tied to IP any more than hop-by-hop routing is tied to IP.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, September 03, 2013 9:33 AM
To: [email-masked]
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Stephane

Stewart

---

From: <[email-masked]>
Date: Tue, 3 Sep 2013 15:44:58 +0200

Stewart,

to name a WG "Source Routing WG" just because it allows a more organised way of exploiting features of an MPLS network, and that limited to paths and routers where an operator desires to utlise these features doesn't seem to be a good idea.

Segment Routing describes what the company I work for will be using it. We don't intend to operate a source routed network. It's an enhancement as compared to LDP based MPLS.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, September 03, 2013 3:33 PM
To: [email-masked]
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Stephane

Stewart

---

From: Loa Andersson <[email-masked]>
Date: Tue, 03 Sep 2013 15:58:28 +0200

All,

I wonder - if this is true:

In segment routing the source to a (partial) source routing defining
which segments (for any value of segment) that should be in the path.
Each segment may or may not be establish by source routing or any other
routing technology.

If this is true - then a discussion on what is and what is not a sub-set
of the other will turn out to be extremely non-productive.

Also there is both "segment routing" and "source routing" - I could
imagine a case where which segment to use is not determined by the
source but by any standard routing algorithm. If doing this has any
value or not is for the future.

/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, 3 Sep 2013 14:29:35 +0000

+1

Regarding the MPLS dataplane, it's mostly about using the IGP as the (intra AS) label distribution protocol for both SPT and 1 hop LSP. Then this allows for easier stacking of LSP/segments as any LSR knows all the LSP/segments of the AS, which can then be used for different use cases as presented during the BOF. This is not source routing from the source of the IP packet.

Regards,
Bruno

>From: [email-masked]
>
>Stewart,
>
>to name a WG "Source Routing WG" just because it allows a more organised way
>of exploiting features of an MPLS network, and that limited to paths and
>routers where an operator desires to utlise these features doesn't seem to
>be a good idea.
>
>Segment Routing describes what the company I work for will be using it. We
>don't intend to operate a source routed network. It's an enhancement as
>compared to LDP based MPLS.
>
>Regards,
>
>Ruediger
>
>> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana);
>____________________________________________________________________________
>_____________________________________________
>>
>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,
>information that may be protected by law;

---

From: <[email-masked]>
Date: Tue, 3 Sep 2013 16:43:26 +0200

There was a misunderstanding in my small comment :) so I will explain more :

In segment routing, you have more than basic source routing : segment routing is just associate a segment number to an action and then combine segment as you want, yes you can do source routing, but you also can do more.

In the other hand, I completely agree with your statement that source routing is generic and dataplane agnostic, as segment routing is ... (segment routing is not a new dataplane ...)

Now the definition of the WG naming must be inline with the charter that will be defined ... (draft today)
 
Based on the already existing consensus (at least for MPLS dataplane) brought up during Berlin STATUS BOF meeting, segment routing sounds to be a good target candidate.

So now, do we want to do more in the WG charter than just make progressing segment routing architecture and uses cases document and ensure coordination for the standardization of this technology ?
 
Do we want to standardize other technologies in this WG ? I don't think so, based on Stewart's conclusion email from the BOF :"A new WG focused solely on SR therefore needs to be create"

If the WG charter is limited to source routing, how will we handle the "non source routing" use cases of segment routing ? In another working group ? So we will go back to the WG synchronization issue that has been raised for this technology ...

If the WG is focused on SR, let's use a name in relation with SR.

Feedback ?

Stephane

-----Message d'origine-----
De : AshwoodsmithPeter [mailto:[email-masked]]
Envoyé : mardi 3 septembre 2013 15:27
À : LITKOWSKI Stephane DTF/DERX
Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and the next steps

Peter

On Sep 3, 2013, at 9:07 AM, "[email-masked]" <[email-masked]> wrote:

> ______________________________________________________________________
> 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.
> 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 3 Sep 2013 14:04:52 +0000

Unified Segment Source Routing (USSR)? ;)

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, September 03, 2013 6:58 AM
To: AshwoodsmithPeter
Cc: [email-masked]; John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]; [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

All,

In segment routing the source to a (partial) source routing defining which segments (for any value of segment) that should be in the path.
Each segment may or may not be establish by source routing or any other routing technology.

If this is true - then a discussion on what is and what is not a sub-set of the other will turn out to be extremely non-productive.

Also there is both "segment routing" and "source routing" - I could imagine a case where which segment to use is not determined by the source but by any standard routing algorithm. If doing this has any value or not is for the future.

/Loa

On 2013-09-03 15:41, AshwoodsmithPeter wrote:
> Behalf Of Stewart Bryant
> That is not correct. A long time ago there was source routed 
> transparent which was a token ring technology.
>
> Stewart
>
>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; 
>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
>>>>>>> The second task, which hopefully should be relatively easy, is 
>>>>>>> to find a better working name for the WG, since it has been put 
>>>>>>> to me a number of times that STATUS is going to be confusing in 
>>>>>>> text and a difficult search term.
>> _____________________________________________________________________
>> ____________________________________________________
>>

--

---

From: <[email-masked]>
Date: Tue, 3 Sep 2013 16:42:08 +0200

Feedback ?

Stephane

-----Message d'origine-----
De : AshwoodsmithPeter [mailto:[email-masked]] 
Envoyé : mardi 3 septembre 2013 15:27
À : LITKOWSKI Stephane DTF/DERX
Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant)
Objet : Re: [Status] Summary of STATUS BOF and the next steps

Peter

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 3 Sep 2013 15:14:02 +0000

Roughly speaking we have three well known transit behaviors for packet forwarding which can be added recursively at various boundaries.

Hop-by-hop            => out interface = F(packet.destination)
Label-substitution    => out interface = F(incoming port, packet.label)
Source routing        => out interface = packet.hop[packet.nexthop++]

These terms have all been used independently of the underlying data planes, eg IP, Ethernet, ATM, MPLS, etc. for nearly 20 years.

Segment routing is the use of recursive label-substitution to implement source routing like behavior because there is no packet.nexthop++ operation in existing MPLS hardware, so it does not seem agnostic of MPLS which was one of the stated goals of the charter.

Not to say it's not a great thing to do and very useful, but terminology wise I don't think it meets the stated agnostic requirement. 

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 03, 2013 10:30 AM
To: [email-masked]; [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

+1

Regards,
Bruno

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 3 Sep 2013 15:22:17 +0000

" If the WG charter is limited to source routing, how will we handle the "non source routing" use cases of segment routing ? In another working group ? So we will go back to the WG synchronization issue that has been raised for this technology ..."

That's why I suggested SRV2. We are revisiting source routing with new concepts. More generic number/action behavior. 

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 03, 2013 10:43 AM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

 

Feedback ?

Stephane

-----Message d'origine-----
De : AshwoodsmithPeter [mailto:[email-masked]]
Envoyé : mardi 3 septembre 2013 15:27
À : LITKOWSKI Stephane DTF/DERX
Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and the next steps

Peter

---

From: Loa Andersson <[email-masked]>
Date: Tue, 03 Sep 2013 17:31:44 +0200

Folks,

Excuse me if I'm slightly out of the loop, but so far I have not seen a
charter proposal, if there is one please point me to it.

It seems a bit odd to put the cart (what the wg should do) before the
horse (wg name). If we drill down the the charter first the wg name
might be easier to figure out.

/Loa

PS
OK I understand that the horse and cart analogy limps a  bit :).

--

---

From: <[email-masked]>
Date: Tue, 3 Sep 2013 17:32:56 +0200

+1 !

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Loa Andersson
Envoyé : mardi 3 septembre 2013 17:32
À : [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

Folks,

Excuse me if I'm slightly out of the loop, but so far I have not seen a charter proposal, if there is one please point me to it.

It seems a bit odd to put the cart (what the wg should do) before the horse (wg name). If we drill down the the charter first the wg name might be easier to figure out.

/Loa

PS

On 2013-09-03 17:22, AshwoodsmithPeter wrote:
> Behalf Of [email-masked]
> In the other hand, I completely agree with your statement that source 
> routing is generic and dataplane agnostic, as segment routing is ... 
> (segment routing is not a new dataplane ...)
>
> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione 
> [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status] 
> Summary of STATUS BOF and the next steps
>
>> _ ___________________________________________________
>>

--

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 3 Sep 2013 18:30:56 +0200

good point - what about this charter proposal ?

---

Stacked Tunnels for Explicit Routing (STER) 
===========================================

A explicit routing domain (ERD) contains a set of routers with the following characteristics:

- They form a connected network
- They can forward traffic through the shortest paths or paths other than the shortest (the latter called explicitly routed paths, or explicit paths)
- They share a common trust model. In this model, any router within the ERD can specify an explicit path between itself and any other router in the ERD. It can then send any packet that passes through it through any path that it has specified. Downstream routers within the ERD forward the packet as specified by the router at the head-end of the path.

The STER working group is chartered for the following ordered list of work items:

- The first goal of the STER WG is to identify use-cases for ERDs. 
- Having identified use-cases, the WG will identify gaps between currently available technologies and use-case requirements. 
- The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. 

Protocol work may be carried out in this working group or in other working groups responsible for the protocols, in coordination with this WG, and in agreement with the WG chairs and responsible ADs. However, no protocol work will be adopted by a working group to address the ERD use-cases until the requirements document motivating the protocol work has been sent to the IESG for publication as an RFC.

---

<flame suit on>

/hannes

---

From: John E Drake <[email-masked]>
Date: Tue, 3 Sep 2013 17:02:09 +0000

Hannes,

This is the precisely the terminology that I used in my Berlin presentation and the charter statement seems fine.

Yours Irrespectively,

John

> Of Hannes Gredler
> Sent: Tuesday, September 03, 2013 9:31 AM
> To: Loa Andersson
> Cc: [email-masked]
> - They can forward traffic through the shortest paths or paths other than the
> shortest (the latter called explicitly routed paths, or explicit paths)
> - They share a common trust model. In this model, any router within the ERD
> can specify an explicit path between itself and any other router in the ERD. It
> can then send any packet that passes through it through any path that it has
> specified. Downstream routers within the ERD forward the packet as
> specified by the router at the head-end of the path.
> 
> - Having identified use-cases, the WG will identify gaps between currently
> available technologies and use-case requirements.
> - The WG will then define requirements for extensions to existing protocols
> or new protocols that address gaps that are identified.
> 
> Protocol work may be carried out in this working group or in other working
> groups responsible for the protocols, in coordination with this WG, and in
> agreement with the WG chairs and responsible ADs. However, no protocol
> work will be adopted by a working group to address the ERD use-cases until
> the requirements document motivating the protocol work has been sent to
> the IESG for publication as an RFC.
> 
> ---
> 
> <flame suit on>
> 
> /hannes
> 
> 
> > Excuse me if I'm slightly out of the loop, but so far I have not seen
> > a charter proposal, if there is one please point me to it.
> >
> >> " If the WG charter is limited to source routing, how will we handle the
> "non source routing" use cases of segment routing ? In another working
> group ? So we will go back to the WG synchronization issue that has been
> raised for this technology ..."
> >>
> >> That's why I suggested SRV2. We are revisiting source routing with new
> concepts. More generic number/action behavior.
> >>
> >> Peter
> >>
> >> In segment routing, you have more than basic source routing : segment
> routing is just associate a segment number to an action and then combine
> segment as you want, yes you can do source routing, but you also can do
> more.
> >>
> >> Based on the already existing consensus (at least for MPLS dataplane)
> brought up during Berlin STATUS BOF meeting, segment routing sounds to be
> a good target candidate.
> >>
> >> So now, do we want to do more in the WG charter than just make
> progressing segment routing architecture and uses cases document and
> ensure coordination for the standardization of this technology ?
> >>
> >> Do we want to standardize other technologies in this WG ? I don't think
> so, based on Stewart's conclusion email from the BOF :"A new WG focused
> solely on SR therefore needs to be create"
> >>
> >> If the WG charter is limited to source routing, how will we handle the "non
> source routing" use cases of segment routing ? In another working group ?
> So we will go back to the WG synchronization issue that has been raised for
> this technology ...
> >>
> >> Envoyé : mardi 3 septembre 2013 15:27 À : LITKOWSKI Stephane
> DTF/DERX
> >> The term "source routing" has been around for a very long time and is
> data path agnostic. Its also the term used in the literature etc so my
> preference is to stick with this existing well known and data path agnostic
> term.
> >>
> >> Peter
> >>
> __________
> >>> __ ___________________________________________________
> >>>
> >>> 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.
> >>>
> ___________

---

From: Mach Chen <[email-masked]>
Date: Wed, 4 Sep 2013 01:55:43 +0000

I also prefer to "source routing", it's well-know and direct.

Best regards,
Mach

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John E Drake
> Sent: Tuesday, September 03, 2013 9:02 PM
> To: Mark Townsley; Victor Kuarsingh
> Cc: Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); Adrian
> Farrel; [email-masked]; Stewart Bryant (stbryant)

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 09:21:52 +0200

>We are revisiting source routing with new concepts. More generic number/action behavior.

[SLI] Agree ! So I would be more in favor of a new term to prevent confusion with a very well known concept today.

-----Message d'origine-----
De : AshwoodsmithPeter [mailto:[email-masked]] 
Envoyé : mardi 3 septembre 2013 17:22
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : RE: [Status] Summary of STATUS BOF and the next steps

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 03, 2013 10:43 AM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

 

Feedback ?

Stephane

-----Message d'origine-----
De : AshwoodsmithPeter [mailto:[email-masked]]
Envoyé : mardi 3 septembre 2013 15:27
À : LITKOWSKI Stephane DTF/DERX
Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and the next steps

Peter

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: <[email-masked]>
Date: Wed, 4 Sep 2013 10:02:45 +0200

Hannes,

In case, we are using only directed forwarding (adjacency segment), could we still talk about tunneling ? (it's a very very small tunnel)
Moreover talking about "stacking" is really dataplane agnostic (MPLS) ...

In the proposed segment routing architectural concepts, segments are at the same "level" and pointer moves on the segment list, then the MPLS instantiation is performing this using stacking ...

IMHO, if we use "Stacked Tunnels", we already talk about a chosen solution and it's closing the door to something else  ...

Finally, about the "routing" word, routing is essentially a "forward" action which may limit the scope of what we can do by using a segment list. Actions associated with a segment could be something else than forwarding.

Do we want in the charter to limit the scope to routing actions ?

I have no solution today to propose for the naming, but I completely agree with Loa, to first focus on working on the charter, and define a clear scope of the work and then the name will be easier to find.

Regarding your charter proposal :

--------

- They form a connected network
        [SLI] InterAS case must be included, but the WG can go step by step and first release intraAS, and then doing interAS (in relation with IDR ??).

- They can forward traffic through the shortest paths or paths other than the shortest (the latter called explicitly routed paths, or explicit paths)
        [SLI] There is something else between SPT and Explicit path, you can define other algorithms than SPT to define a path, and it's not explicit path. Moreover I come back to my comment, on do we want to limit the scope to routing ? I would say no.

- They share a common trust model. In this model, any router within the ERD can specify an explicit path between itself and any other router in the ERD. It can then send any packet that passes through it through any path that it has specified.
        [SLI] Security considerations may have to be addressed in the charter , especially for the interAS case (trust yes, but not sure access to everything may not be good)

Downstream routers within the ERD forward the packet as specified by the router at the head-end of the path.
[SLI] Yes, but any router in the middle may be able to change the end to end explicit path.

[SLI] Agree, I would add :
- defining the architecture framework
- analysing the security considerisations

---------

Here would be my proposal to extend yours :

A <named to be defined> domain contains a set of routers with the following characteristics:

- They form a connected network
- They can forward traffic through any path within the network using shortest path, non shortest path or explicit path
- They may provide other types of services than forwarding and they can enforce service actions in the path.
- They share a common trust model. In this model, any router within the domain can specify a path between itself and any other router in the domain. It may then send any packet that passes through it through any path that it has specified and that is conform to the security rules. Downstream routers within the ERD forward the packet as specified by the router at the head-end of the path.

The <name> working group is chartered for the following ordered list of work items:

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between domains (interdomain).
- Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements.
- The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Hannes Gredler
Envoyé : mardi 3 septembre 2013 18:31
À : Loa Andersson
Cc : [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

---

Stacked Tunnels for Explicit Routing (STER) ===========================================

---

<flame suit on>

/hannes

On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote:

>> Envoyé : mardi 3 septembre 2013 15:27 À : LITKOWSKI Stephane DTF/DERX
>>> ____________________________________________________________________
>>> 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.
>>>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 04 Sep 2013 11:24:52 +0100

May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:

The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

     The working group is chartered for the following work items:

     A framework for the use of the existing MPLS data plane to
     support tunnel-based unicast source routing.

     Develop use cases for tunnel-based unicast source routing
     that demonstrate the need and support for solutions. Care
     should be taken to avoid clustering use cases that might seem
     to imply support for multiple use cases when only some of the
     cluster actually have wide-scale support.

     Develop ISIS and OSPF protocol extensions necessary for
    distribution of MPLS forwarding information.

     The working group will consider management (including
     configuration, reporting, diagnostics, and OAM) and security
     implications of its work and document them in separate
     documents as appropriate.

     The working group is not chartered to make any changes to
     the MPLS or IPv6 data planes. Any proposed changes to the
     data planes are to be specified in the working groups responsible
     for the data planes (that is, the MPLS and 6MAN working groups,
     respectively).

- Stewart

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 4 Sep 2013 14:01:03 +0000

I would like us to have the door open to changes in the data plane in the future.

The text as written pretty much closes that door.

Naturally it makes sense to focus on what current hardware can do, but we need to be forward looking and to make recommendations on what changes would be useful in the future.

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

- Stewart

---

From: <[email-masked]>
Date: Wed, 4 Sep 2013 16:21:13 +0200

Peter,

no objection, if you address phase 2 of SR. So whatever is done in phase 1, it should not exclude future changes to the data plane. SR Phase 1, which is chartered now, should exclude changes to the existing data plane. Let's stay focused.

Regards,

Ruediger

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 4:01 PM
To: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Peter

- Stewart

---

From: John E Drake <[email-masked]>
Date: Wed, 4 Sep 2013 14:26:28 +0000

Peter,

The group's charter can always be amended in the future, but I don't think it's good to declare open season on the MPLS data plane initially.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 7:01 AM
To: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Peter

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]<mailto:[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

- Stewart

---

From: Rob Shakir <[email-masked]>
Date: Wed, 4 Sep 2013 19:56:37 +0100

Right. Day 1 we need this to work with things that are deployable in real and existing networks, but I think this should not stop us defining the charter to write a data plane agnostic architecture, which can then have documents describing how it is implemented in each data plane we want to use. 

This way we can define the features that we need - or at least desirable - and then work out how they are realised (some existing data planes may not be able to support all desirable features - an example is retaining the full path at all hops). It also reduces duplication across the data plane instance specs. 

From my perspective this means the charter must include an architecture deliverable plus one defining the MPLS data plane. Based on the assessment of the BoF it should also include one for lPv6. This would not preclude future data planes from being added to the charter and reusing all the output of the WG sometime down the line. 

r. 

Sent from my iPhone

On 4 Sep 2013, at 15:26, John E Drake <[email-masked]> wrote:

> Peter,
>  
> The group’s charter can always be amended in the future, but I don’t think it’s good to declare open season on the MPLS data plane initially.
>  
> Yours Irrespectively,
>  
> John
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 4 Sep 2013 19:05:53 +0000

strongly concur.

Peter

On Sep 4, 2013, at 2:57 PM, "Rob Shakir" <[email-masked]<mailto:[email-masked]>> wrote:

r.

Sent from my iPhone

On 4 Sep 2013, at 15:26, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:

Peter,

Yours Irrespectively,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 7:01 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Peter

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

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Wed, 4 Sep 2013 21:38:51 +0000

I actually don't think it is possible to write a dataplane agnostic architecture.   We can write an architecture document that is 90% dataplane independent and then has some dataplane dependencies.  E.g. having the full SR path available at each hop vs the remainder.

George

From: AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 4, 2013 3:05 PM
To: Rob Shakir <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

strongly concur.

Peter

r.

Sent from my iPhone

Peter,

Yours Irrespectively,

John

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 7:01 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

Peter

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]<mailto:[email-masked]>
Subject: Re: [Status] Summary of STATUS BOF and the next steps

- Stewart

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 05:54:26 +0200

hi stephane,

see comments inline prefixed by HG>

On Sep 4, 2013, at 10:02 AM, <[email-masked]> <[email-masked]> wrote:
>  case, we are using only directed forwarding (adjacency segment), could we still talk about tunneling ? (it's a very very small tunnel)
> Moreover talking about "stacking" is really dataplane agnostic (MPLS) …

HG> one-hop tunnels are ok;

> In the proposed segment routing architectural concepts, segments are at the same "level" and pointer moves on the segment list, then the MPLS instantiation is performing this using stacking …

the "moving pointer" is a requirement without an actual use case -
do you know how this would be used ? - i don't

> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solution and it's closing the door to something else  …

HG> closing door to things we have no (known) requirements for is ok;
being anything to anybody is not helpful - the more concise the charter
the better;

> Do we want in the charter to limit the scope to routing actions ?

HG> as per the published use-case drafts all i have seen are use-cases related to
"forwarding". as far as i am concerned i am good limiting the scope to
"routing actions".

> I have no solution today to propose for the naming, but I completely agree with Loa, to first focus on working on the charter, and define a clear scope of the work and then the name will be easier…

HG> good :-)

>        [SLI] InterAS case must be included, but the WG can go step by step and first release intraAS, and then doing interAS (in relation with IDR ??).

HG> did i preclude inter-AS in any way ?

>        [SLI] There is something else between SPT and Explicit path, you can define other algorithms than SPT to define a path, and it's not explicit path. Moreover I come back to my comment, on do…

HG> if you have a case for non-routing, please make it; - IIRC in our past 6 months of
 conversation around IGP label advertisement / SR we haven't discussed any non-routing use-case.

>        [SLI] Security considerations may have to be addressed in the charter , especially for the interAS case (trust yes, but not sure access to everything may not be good)

HG> ok.

> [SLI] Yes, but any router in the middle may be able to change the end to end explicit path.

HG> is there any application outside FRR for changing an explicit path ?

> - analysing the security considerations

HG> ok;

---

From: Saku Ytti <[email-masked]>
Date: Thu, 5 Sep 2013 07:52:37 +0300

> I actually don't think it is possible to write a dataplane agnostic architecture.   We can write an architecture document that is 90% dataplane independent and then has some dataplane dependencies.…

Architecture can provide command 'next segment', without explicitly
mandating previous segments to be deleted or kept.

Compatible implementation/wire-format then has some freedom in its
implementation.

-- 
  ++ytti

---

From: <[email-masked]>
Date: Thu, 5 Sep 2013 10:00:34 +0200

Hannes,

> In the proposed segment routing architectural concepts, segments are
> at the same "level" and pointer moves on the segment list, then the
> MPLS instantiation is performing this using stacking ...

[HG] the "moving pointer" is a requirement without an actual use case - do you know how this would be used ? - i don't

[SLI] Interrest is to keep tracking where the packet is coming from. I'm not saying that this is a good the solution or not ... working group should decide ... but enforcing "stacking" is the charter may close door to some other solutions.

> Do we want in the charter to limit the scope to routing actions ?

HG> as per the published use-case drafts all i have seen are use-cases
HG> related to
"forwarding". as far as i am concerned i am good limiting the scope to "routing actions".

[SLI] We had to start with something simple, that's why the current use cases are related only to forwarding. But it's not a reason to limit the charter to this ...

[SLI] It was not clear to me what did you put behind "connected network"

>        [SLI] There is something else between SPT and Explicit path, you can define other algorithms than SPT to define a path, and it's not explicit path. Moreover I come back to my comment, on do…

HG> if you have a case for non-routing, please make it; - IIRC in our
HG> past 6 months of
 conversation around IGP label advertisement / SR we haven't discussed any non-routing use-case.

[SLI] Non routing use case are more future ...  routing is the basic infrastructure on top of which you can add some stuffs.

Stephane

-----Message d'origine-----
De : Hannes Gredler [mailto:[email-masked]]
Envoyé : jeudi 5 septembre 2013 05:54
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

hi stephane,

On Sep 4, 2013, at 10:02 AM, <[email-masked]> <[email-masked]> wrote:
>  case, we are using only directed forwarding (adjacency segment),
> could we still talk about tunneling ? (it's a very very small tunnel)

> In the proposed segment routing architectural concepts, segments are
> at the same "level" and pointer moves on the segment list, then the
> MPLS instantiation is performing this using stacking ...

the "moving pointer" is a requirement without an actual use case - do you know how this would be used ? - i don't

> IMHO, if we use "Stacked Tunnels", we already talk about a chosen
> solution and it's closing the door to something else  ...

HG> closing door to things we have no (known) requirements for is ok;
being anything to anybody is not helpful - the more concise the charter the better;

> Do we want in the charter to limit the scope to routing actions ?

HG> as per the published use-case drafts all i have seen are use-cases
HG> related to
"forwarding". as far as i am concerned i am good limiting the scope to "routing actions".

HG> good :-)

>        [SLI] There is something else between SPT and Explicit path, you can define other algorithms than SPT to define a path, and it's not explicit path. Moreover I come back to my comment, on do…

HG> if you have a case for non-routing, please make it; - IIRC in our
HG> past 6 months of
 conversation around IGP label advertisement / SR we haven't discussed any non-routing use-case.

>        [SLI] Security considerations may have to be addressed in the
> charter , especially for the interAS case (trust yes, but not sure
> access to everything may not be good)

HG> ok.

HG> ok;

> - They can forward traffic through any path within the network using
> shortest path, non shortest path or explicit path
> part de Hannes Gredler Envoyé : mardi 3 septembre 2013 18:31 À : Loa
> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of STATUS
> BOF and the next steps
>
> - They can forward traffic through the shortest paths or paths other
> than the shortest (the latter called explicitly routed paths, or
> explicit paths)
>>> In the other hand, I completely agree with your statement that
>>> source routing is generic and dataplane agnostic, as segment routing is ...
>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta
>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana
>>> (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>> [Status] Summary of STATUS BOF and the next steps
>>>
>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS
>>>> BOF and the next steps
>>>>
>>>> Hi,
>>>>
>>>>>> acronym will be difficult and Segment Routing is generic enough
>>>>>> to associate to multiple functions.
>>>>>
>>>>> Then we can just use "segroute" for the short name. WGs do not
>>>>> have to have acronyms, but they do need to have an 8-char limited
>>>>> short name for the various automated tools not to break.
>>>>>
>>>>> - Mark
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Victor K
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> to find a better working name for the WG, since it has been
>>>>>>>>> put to me a number of times that STATUS is going to be
>>>>>>>>> confusing in text and a difficult search term.
>>>> ___________________________________________________________________
>>>> _ __ ___________________________________________________
>>>>
>>> _ ____________________________________________________
>>>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 5 Sep 2013 08:18:46 +0000

Hannes, Stephane,

> [SLI] Interrest is to keep tracking where the packet is coming from. I'm not saying that this is a good the solution or not ... working group should decide ... but enforcing "stacking" is the chart…

absolutely agree. Data-plane agnostic means there may be differences
in the way data-planes instantiate a function.

If one data-plane stacks, the other may point. Nothing wrong with 
this.

> "forwarding". as far as i am concerned i am good limiting the scope to "routing actions".

not me. There are use cases, (still to document but pretty real) that
are not routing based. Service Chaining is one.

> [SLI] We had to start with something simple, that's why the current use cases are related only to forwarding. But it's not a reason to limit the charter to this ...

absolutely agree.

> conversation around IGP label advertisement / SR we haven't discussed any non-routing use-case.

Service chaining is one of them.

Thanks.

s.

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 5 Sep 2013 10:50:49 +0200

hi stefano,

please see comments inline;

> are not routing based. Service Chaining is one.

HG> the use cases becomes "real" once they see the light of day (=publication)
    in the meantime they'll remain "fictional".
    for network service chaining it is my understanding that there is a dedicated BOF/WG.
    i fail to see why we would need to do it here. - quite contrary it may be one of those things
    that http://tools.ietf.org/html/rfc1925 section 2 point (5) warns us about.

>> [SLI] We had to start with something simple, that's why the current use cases are related only to forwarding. But it's not a reason to limit the charter to this ...

HG> good so lets keep it out for now, and change charter later as requirements become more clear;

---

From: Rob Shakir <[email-masked]>
Date: Thu, 5 Sep 2013 10:23:11 +0100

> I actually don't think it is possible to write a dataplane agnostic architecture.   We can write an architecture document that is 90% dataplane independent and then has some dataplane dependencies.…

You're right, maybe "agnostic" is an overstatement, but it at least needs to be data plane independent as you say (such that the architecture does not link to a specific data plane, but can be re-used across them). The way that we develop the architecture should of course take into account what the capabilities are of the data planes that we envisage deploying SR on.

r.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 5 Sep 2013 10:16:29 +0000

Hi all,

According to the BoF session at IETF87, it seems that there are a certain number of people who want to see an IPv6-based, rather than MPLS-based source routing mechanism. However, it seems that many people are hesitate to make any change to the existing MPLS and IP data planes.

I wonder whether the following low-cost approach can make those IP fans happy: the predefined next-hops that the explicit source path must traverse are still expressed by the MPLS label stack in the data packets, but the adjacent next-hops are connected via pure IP networks, rather than MPLS networks.  For example, if LSR A wants to send a MPLS VPN packet for LSR Z along an explicit path {B, C, Z}, it would push the node segment label for Z and then the node segment label for C into the existing MPLS label stack, and then transport such MPLS packet over an IP tunnel towards B. Upon receiving such MPLS packet over the IP tunnel, B would look up the corresponding MPLS forwarding table entry for the topmost label (i.e., the node segment label for C) and find the out interface for this packet is an IP tunnel interface with tunnel destination of C, therefore it would pop the topmost label (if the out label of that MPLS forwarding entry is null) and then transport the MPLS packet over an IP tunnel towards C.  Once C receives such MPLS packet over the IP tunnel, C would look up the corresponding MPLS forwarding entry for the current topmost label (i.e., the node segment label for Z) , and then forward this MPLS packet over an IP tunnel towards Z like what B has done.

The above approach has at least the following benefits:

1)    No change to the existing MPLS and IP data plane.

2)    No requirement for the MPLS forwarding capability on all routers=> only those explicit hops need the MPLS forwarding capability.

3)    No requirement for software upgrade on all routers=> only those explicit hops need such software upgrade.

4)    Less MTU collision risk due to the usage of 20-bit long MPLS labels, rather than 128-bit long IPv6 addresses for indicating the predefined next-hops of a given explicit source path.

Best regards,
Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Stewart Bryant
发送时间: 2013年9月4日 18:25
收件人: Mach Chen
抄送: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]
主题: Re: [Status] Summary of STATUS BOF and the next steps

- Stewart

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 5 Sep 2013 03:42:23 -0700

Is this any different than MPLS over GRE, where GRE is used to get over
non-MPLS-aware parts of a network?

Anoop

On Thu, Sep 5, 2013 at 3:16 AM, Xuxiaohu <[email-masked]> wrote:

>  Hi all,****
>
> ** **
>
> According to the BoF session at IETF87, it seems that there are a certain
> number of people who want to see an IPv6-based, rather than MPLS-based
> source routing mechanism. However, it seems that many people are hesitate
> to make any change to the existing MPLS and IP data planes.****
>
> ** **
>
> I wonder whether the following low-cost approach can make those IP fans
> happy: the predefined next-hops that the explicit source path must traverse
> are still expressed by the MPLS label stack in the data packets, but the
> adjacent next-hops are connected via pure IP networks, rather than MPLS
> networks.  For example, if LSR A wants to send a MPLS VPN packet for LSR Z
> along an explicit path {B, C, Z}, it would push the node segment label for
> Z and then the node segment label for C into the existing MPLS label stack,
> and then transport such MPLS packet over an IP tunnel towards B. Upon
> receiving such MPLS packet over the IP tunnel, B would look up the
> corresponding MPLS forwarding table entry for the topmost label (i.e., the
> node segment label for C) and find the out interface for this packet is an
> IP tunnel interface with tunnel destination of C, therefore it would pop
> the topmost label (if the out label of that MPLS forwarding entry is null)
> and then transport the MPLS packet over an IP tunnel towards C.  Once C
> receives such MPLS packet over the IP tunnel, C would look up the
> corresponding MPLS forwarding entry for the current topmost label (i.e.,
> the node segment label for Z) , and then forward this MPLS packet over an
> IP tunnel towards Z like what B has done.****
>
> ** **
>
> The above approach has at least the following benefits:****
>
> ** **
>
> **1)    **No change to the existing MPLS and IP data plane.****
>
> **2)    **No requirement for the MPLS forwarding capability on all
> routers=> only those explicit hops need the MPLS forwarding capability.***
> *
>
> **3)    **No requirement for software upgrade on all routers=> only those
> explicit hops need such software upgrade.****
>
> **4)    **Less MTU collision risk due to the usage of 20-bit long MPLS
> labels, rather than 128-bit long IPv6 addresses for indicating the
> predefined next-hops of a given explicit source path.****
>
> ** **
>
> Best regards,****
>
> Xiaohu****
>
> ** **
>
> *发件人:* [email-masked] [mailto:[email-masked]] *代表 *Stewart
> Bryant
> *发送时间:* 2013年9月4日 18:25
> *收件人:* Mach Chen
> *抄送:* John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione
> *主题:* Re: [Status] Summary of STATUS BOF and the next steps****
>
> ** **
>
>
> - Stewart****

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 5 Sep 2013 13:32:35 +0000

> HG> the use cases becomes "real" once they see the light of day (=publication)

I'm producing a charter proposal that includes use-cases document 
publication.

> HG> good so lets keep it out for now, and change charter later as requirements become more clear;

I don't think we want to keep it out.

s.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 5 Sep 2013 13:39:54 +0000

There are a number of interesting uses when the history of the packet's flight is available.

 - tandem fast reroute mechanisms can use previous hops as context to spread traffic to different alternate next hops.
 - one can create 1:1 end to end protected paths with reverse path fate sharing for the probes, no need to install state at both ends.
 - greatly simplified debugging of network.
 - easier to build network flow information by simply inspecting traffic flowing through small number of representative network cuts.
 - reverse path checks can be used for authentication.
 - potentially halves the amount of work an central (SDN or Forces) controller must do (assuming symmetry is desired).

Admittedly these are longer term uses, but for these reasons and others I hope that we do not close the door to keeping track of the history of the packet's flight. 

Cheers,

Peter

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 5 Sep 2013 13:51:26 +0000

George, the existing architecture document does a pretty good job IMHO. Not perfect of course, but they lay out the properties that are desirable and then map them to IP and MPLS. I hope we can keep that approach in the WG. 

Peter

-----Original Message-----
From: Rob Shakir [mailto:[email-masked]] 
Sent: Thursday, September 05, 2013 5:23 AM
To: George Swallow (swallow)
Cc: AshwoodsmithPeter; [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

r.

---

From: John E Drake <[email-masked]>
Date: Thu, 5 Sep 2013 17:55:51 +0000

Peter,

Comments inline.

Yours Irrespectively,

John

> Of AshwoodsmithPeter
> Sent: Thursday, September 05, 2013 6:40 AM
> To: [email-masked]
> [HG] the "moving pointer" is a requirement without an actual use case - do
> you know how this would be used ? - i don't
> 
> [SLI] Interrest is to keep tracking where the packet is coming from. I'm not
> saying that this is a good the solution or not ... working group should decide
> ... but enforcing "stacking" is the charter may close door to some other
> solutions.
> 
>  - tandem fast reroute mechanisms can use previous hops as context to
> spread traffic to different alternate next hops.

[JD]  This information is useless.  Regardless of the paths that packets took to reach a given transit node, that node is presented with a composite set of traffic flows for each egress node.  It will need to spread the packets of these flows across its ECMP paths to that egress node by replacing the explicit route in each packet with an explicit route specifying one of these ECMP paths, subject to the requirement that all packets of a given flow follow the same path.

Also, this is strictly a transient case which stops being of interest once the ingress nodes receive the IGP update from the transit node that indicating the link in question has failed, because at this point the ingress nodes will compute new explicit routes that don't use the failed link.  

>  - one can create 1:1 end to end protected paths with reverse path fate
> sharing for the probes, no need to install state at both ends.

[JD]  Without installing state, how will an egress node know which packets from a given ingress node are following disjoint paths through the network?  I.e., there will be a multiplicity of disjoint path pairs that a given ingress node is using to send packets to that egress node. 

>  - greatly simplified debugging of network.

[JD]  If a packet is misdirected by a transit node, then that transit node is obviously not processing the explicit route correctly.  Therefore, what is the utility of having the complete explicit route computed by the ingress node in such a misdirected packet, since it is clearly not being followed?

I think it would be far more effective to dynamically accumulate a given packet's path through the network.  

>  - easier to build network flow information by simply inspecting traffic flowing
> through small number of representative network cuts.
 
[JD]  In a real network with a large number of ECMP paths between ingress/egress node pairs, what leads you to assume that querying a small number of transit nodes will give one any idea of how the traffic is flowing through one's network?  Why isn't simply querying the ingress nodes both simpler and more effective?
 
Also, this is obviously useless if a central controller is being used.

>  - reverse path checks can be used for authentication.

[JD]  Reverse path checks are done at the ingress to a network not at the egress.  

> must do (assuming symmetry is desired).

[JD]  The phrase 'false economy' springs to mind. 

> 
> Admittedly these are longer term uses, but for these reasons and others I
> hope that we do not close the door to keeping track of the history of the
> packet's flight.
> 
> Cheers,
> 
> Peter
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 6 Sep 2013 03:21:55 +0000

Hi Anoop,

It exactly uses the MPLS-in-GRE or other IP-based encapsulations for MPLS.

Anyway, unless it is mandatory to contain a list of IPv6 addresses in the IPv6 data packet for indicating the predefined next-hops of a given explicit source path, it would be better to use a list of SHORTER IDs/labels instead of the 128-bit long IPv6 addresses to indicate those predefined next-hops. IMHO, the existing MPLS label stack mechanism happens to be an ideal candidate for this. People who want to use such mechanism don’t need to know any other applications of MPLS. The only thing that they need to know is that short (MPLS) labels, instead of IPv6 addresses are used in the IPv6 data packet to indicate the predefined next-hops. Therefore, it seems that there is no strong technical motivation to reinvent the wheel for the IPv6 data plane.

Best regards,
Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Anoop Ghanwani
发送时间: 2013年9月5日 18:42
收件人: Xuxiaohu
抄送: [email-masked]; [email-masked]
主题: Re: [Status] A possible way to make IP fans happy//re: Summary of STATUS BOF and the next steps

Is this any different than MPLS over GRE, where GRE is used to get over non-MPLS-aware parts of a network?

Anoop

On Thu, Sep 5, 2013 at 3:16 AM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Best regards,
Xiaohu

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] 代表 Stewart Bryant
发送时间: 2013年9月4日 18:25
收件人: Mach Chen
抄送: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [email-masked]<mailto:[email-masked]>
主题: Re: [Status] Summary of STATUS BOF and the next steps

- Stewart

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 6 Sep 2013 18:27:29 +0200

hi stephane,

here is a revised draft charter as per your comments.

---

<Name-TBD> domain contains a set of routers with the following
characteristics:

- They form a connected network
- They can forward traffic through any path within the network using
  shortest path, or any other (e.g., an explicit) path
- They share a common trust model. In this model, any router within
  the domain can specify a path between itself and any other router
  in the domain. It may then send any packet that passes through it
  through any path that it has specified and that is conform to the
  security rules. Downstream routers along the path within the <Name-TBD>
  domain forward the packet as specified by the router at the head-end
  of the path.

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

- The first goal of the WG is to identify use-cases.
- The WG will then define the architecture framework associated with
  the security considerations. The architecture framework and security
  considerations must address the relations between domains (interdomain).
- Having identified use-cases, architecture and security, the WG will
  identify gaps between currently available technologies and use-case
  requirements.
- The WG will then define requirements for extensions to existing
  protocols or new protocols that address gaps that are identified.
- The WG will first focus on the intra-domain forwarding definition.

Protocol work may be carried out in this working group or in other
working groups responsible for the protocols, in coordination with
this WG, and in agreement with the WG chairs and responsible ADs.
However, no protocol work will be adopted by a working group to
address the identified use-cases until the requirements document
motivating the protocol work has been sent to the IESG for
publication as an RFC.

---

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Sep 2013 18:52:39 +0200

Hi,

>   protocols or new protocols that address gaps that are identified.

So this effectively says that if there is a way in today's protocols
to accomplish use-cases - no matter how operationally and deployment
difficult this turns out to be in practice - there would be no gaps -
hence no hope for the operators to see any new protocol extensions
work to proceed.

I find those two sentences quoted above not acceptable.

Of course let's also observe that there is going to be clearly
difficulty - which we have already seen at the "BOF" - to evaluate
proposed use-cases and consider them as valid or not valid. Who will
be the judge and the jury - chairs ? ADs ? IESG ? Rough consensus ?

For the record .. I support charter sent to the list by Stefano Previdi.

Best,
R.

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 09:08:42 +0200

Hannes,

I'm worried about the proposal below, which seem to miss the most important points of SR (I call it that):

- SR allows to reduce complexity by getting rid of RSVP TE and LDP. Apart from OAM I
  don't think SR is supposed to fill gaps.
- I don't fully understand why the SR work must address inter domain relations, if
  it is supposed to be primarily chartered with intra domain control plane issues.
- My take is, that intra-domain MPLS forwarding will remain as is initially with SR.
  Your last bullet point means todays MPLS is out of scope, as no forwarding
  definitions need to be changed?
- We agreed not work on protocols within the SR WG. Why has that been changed?

Regards,

Ruediger

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

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

Protocol work may be carried out in this working group or in other working groups responsible for the protocols, in coordination with this WG, and in agreement with the WG chairs and responsible ADs.
However, no protocol work will be adopted by a working group to address the identified use-cases until the requirements document motivating the protocol work has been sent to the IESG for publication as an RFC.

---

/hannes

On Sep 4, 2013, at 10:02 AM, <[email-masked]> <[email-masked]> wrote:

> Hannes,
>
> In case, we are using only directed forwarding (adjacency segment),
> could we still talk about tunneling ? (it's a very very small tunnel) Moreover talking about "stacking" is really dataplane agnostic (MPLS) ...
>

---

From: Rob Shakir <[email-masked]>
Date: Mon, 9 Sep 2013 08:24:59 +0000

Hannes,

In-line as rjs>.

On 6 Sep 2013, at 16:27, Hannes Gredler <[email-masked]> wrote:

>  considerations must address the relations between domains (inter domain).

rjs> It seems a little odd to me that we would identify that there are inter-domain issues to solve when there is no suggested use case that seemed to relate to this as a requirement. Any extensions of the technology developed within the WG to be inter-domain can be for future study.

> motivating the protocol work has been sent to the IESG for

rjs> I do not see the need to place this restriction on the WG -- often we can shape and re-discuss requirements as we work through the details of solutions, based on the practicality of realising particular functions, or the complexity of supporting particular capabilities. Since we do not have this restriction in other WGs, I'm not clear that we need it defined here?

Kind regards,
r.

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 10:56:56 +0200

ruediger,

On Sep 9, 2013, at 9:08 AM, <[email-masked]> wrote:
> - SR allows to reduce complexity by getting rid of RSVP TE and LDP.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

that seem to be a gross misunderstanding on your side;

'reducing complexity' means *obsoleting* technology A with technology B.

the issue is that introduction of SR does *neither* obsolete LDP *nor* RSVP,
simply because SR is not a 100% replacement of LDP and RSVP functionalities.

SR lacks functionality in areas of:

  1. LSP bandwidth reservation
  2. LSP preemption
  3. p2mp path construction
  4. PW signaling
  5. FRR node-protection

adding the IGP as a label distribution protocol to the stack of protocols
allows the network to do tunnel discovery and with that capability we can arguably fix
a couple of interesting problems, but does this single capability
make it a panacea for networking ?

> - My take is, that intra-domain MPLS forwarding will remain as is initially with SR.

there are SPs which operate multi-AS domains and the implications
to connect those ASes using label-stacking technology should be worked on.

> - Your last bullet point means todays MPLS is out of scope, as no forwarding

not sure if we can get away with zero changes - issues that we need to talk about are:

1. MPLS source labels
2. Entropy label implications of label stacking
3. Hardware capabilites (Maxpushlabels) and management

> - We agreed not work on protocols within the SR WG. Why has that been changed?

there might be a a need to work on protocols which do not fit into existing WGs.

HTH,

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 11:23:01 +0200

hi rob,

> rjs> It seems a little odd to me that we would identify that there are inter-domain issues to solve when there is no suggested use case that seemed to relate to this as a requirement. Any extension…

HG> here is an example of an inter domain use-case:
http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-05#section-3.2

> rjs> I do not see the need to place this restriction on the WG -- often we can shape and re-discuss requirements as we work through the details of solutions, based on the practicality of realising…

HG> you are right that hacking protocols without use-cases and requirements has been
done in the past in other WGs, but its not a good habit. and since the snake-oil
dealers are already overselling this technology and what it can do, we should
stay very disciplined.

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 11:26:10 +0200

Hannes,

sorry, but why should the ISPs interested in standardising SR worry about issues ocurring for ISPs who are not interested in migrating to SR? I don't think, SR should look for replacements, SR should work on simplifications. That's what the charter should express. I'm not interested in working within a "LDP and RSVP-TE replacement WG". Sorry if my first mail was overstated to that regard ("...get rid of").

DT so far does not utilise RSVP TE in parts of the backbone, but is interested in SR based features offering similar routing properties. Bandwidth reservation and preemption are completely irrelevant to me.

If there are issues, we will (dis)cover them while we work on the technology. But discovering issues and analysing them shouldn't be core part of a charter - the features to be developed should be.

Serious issues on non core-aspects identified in advance may be removed from the charter (I'd regard that as usual).

Regards,

Ruediger

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]]
Sent: Monday, September 09, 2013 10:57 AM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

ruediger,

1. MPLS source labels

HTH,

/hannes

---

From: Rob Shakir <[email-masked]>
Date: Mon, 9 Sep 2013 09:40:33 +0000

Hi Hannes,

On 9 Sep 2013, at 09:23, Hannes Gredler <[email-masked]> wrote:

>>> <..snip..>

rjs> Isn't this an intra-domain use case? As I read it, ASBR{1,2} allocate the label and advertise it within the AS1 IGP. There is no labelled traffic passed between AS1 and AS{3,4,5,6} as both the ASBRs program a pop operation. I read inter-domain as segments being used to influence routing within two separate autonomous systems which are not within the same trust domain.

> dealers are already overselling this technology and what it can do, we should

rjs> I can't comment on the assertions of others, and do not wish to do so. In my view, there are pragmatic use cases (defined by a number of operators) which are gaps that we cannot meet today. Let's identify those, and work on those, and allow further uses of the technology going forward if there is a convincing case to do so.

rjs> I don't disagree that we should stay disciplined, but I do not see the requirement to mandate that a document must be sent to the IESG to be published *before* solutions drafts are adopted. Having a requirement that the adopted solutions drafts should address the use cases within previously adopted documents puts the same focus safe-guard in as far as I can see.

Kind regards,
r.

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 12:06:08 +0200

robert,

i am glad that you haven't discovered the hidden anagrams in the 
proposed draft agenda, yet - it would have revealed a larger conspiracy
and their satanic plan for removing free speech and freedom on the internet.

apart from that i simply fail to see the need for developing redundant
technology within IETF.

/hannes

On Sep 6, 2013, at 6:52 PM, Robert Raszuk wrote:
> hence no hope for the operators to see any new protocol extensions"
> work to proceed.
> 
[ … ]

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 12:49:00 +0200

ruediger,

> sorry, but why should the ISPs interested in standardising SR worry about issues ocurring for ISPs who are not interested in migrating to SR? I don't think, SR should look for replacements, SR shou…

if its not 'obsoleting' something, then it is by definition an 'extension' of something.
in other words the complexity of the 'something' will be going up and never down.
i haven't yet identified the code to be deleted, if SR is going to be a success ;-)

> DT so far does not utilise RSVP TE in parts of the backbone, but is interested in SR based features offering similar routing properties. Bandwidth reservation and preemption are completely irreleva…

that is fine and yet for the industry as a whole doing distributed
bandwidth reservation *is* a relevant functionality.

> If there are issues, we will (dis)cover them while we work on the technology. But discovering issues and analysing them shouldn't be core part of a charter - the features to be developed should be.

i'd rather do the analysis and planning exercise
before commencing work.

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2013 13:03:55 +0200

> i haven't yet identified the code to be deleted, if SR is going to be a success ;-)

How about LDP as starter ?

Which of the below are solved by LDP ? Which LDP functionality will
not be covered by SR ?

>>  3. p2mp path construction

Note that those are all done today in the control plane. Therefor it
seems pretty trivial to accomplish all of those with SR using number
of PCE or PCE like controllers rather then use RSVP-TE for explicit
path signalling.

>>  5. FRR node-protection

As you know computing LFA sort of addresses this topic pretty well.
Moreover SR may complete topologies where today LFA may not be
possible in 100% of coverage.

>> make it a panacea for networking ?

Some folks think that MPLS is a panacea for networking .. SR with IP
encap can prove it is not ;) That's the beauty of it.

> apart from that i simply fail to see the need for developing redundant

Why not since the redundant technology has much better scaling and
operational properties. It simplifies control plane and that alone
should be sufficient reason.

Cheers,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 13:04:58 +0200

hi rob,

> rjs> Isn't this an intra-domain use case? As I read it, ASBR{1,2} allocate the label and advertise it within the AS1 IGP. There is no labelled traffic passed between AS1 and AS{3,4,5,6} as both the…

HG> it is … now think for a moment if there would be one AS in-between
   the egress link - as per the illustration below:
   the ingress router is in AS1 and it wants to control the exit link of AS2-->AS3.

   AS1--AS2--AS3

> rjs> I can't comment on the assertions of others, and do not wish to do so. In my view, there are pragmatic use cases (defined by a number of operators) which are gaps that we cannot meet today. Le…

HG> agreed.

> rjs> I don't disagree that we should stay disciplined, but I do not see the requirement to mandate that a document must be sent to the IESG to be published *before* solutions drafts are adopted. Ha…

HG> that seems reasonable to me as well - do you have a suggestion for the actual text ?

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 13:58:04 +0200

Hannes,

please try to bring the discussion forward.

- I do not support deployment of RSVP TE in the DT backbone because
  this adds undesired complexity. Why should I worry about
  obsoleting RSVP-TE or aim on that, if I think the cost of deploying
  RSVP-TE is too high as compared to the gain?

- I'm happy extending ISIS, if this allows for an additional
  range of TE (and OAM) functions. That's what I'll gain if SR is a success.

I think my point is clear. I don't want to keep you from discussing RSVP-TE related topics with others and I fully respect if others have RSVP-TE related issues.

In addition, SR will allow for very scaleable LSP monitoring OAM. Trying to to this with todays features is very complex (we've done that).

SR can simplify LSP monitoring OAM as compared to what's available today.

Finally, if you prefer to do analysis and planning work, then why shouldn't you? In parallel to those commencing work on specifying SR.

Regards,

Ruediger

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]]
Sent: Monday, September 09, 2013 12:49 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

ruediger,

> [ ... ]

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 14:13:02 +0200

robert,

> How about LDP as starter ?

this would really disappoint my RFC4447 (LDP pseudo wire) customers
if i'd remove LDP support in favor of SR.

> Which of the below are solved by LDP ? Which LDP functionality will

(3) is solved by mLDP and RSVP-TE.
(1) and (2) is solved by RSVP-TE

> seems pretty trivial to accomplish all of those with SR using number
       ^^^^^^^^^^^^^^
> path signaling.

"In theory there is no difference between theory and practice. In practice there is."

  so lets discuss about the  *practical* side of things.

  assume for a second that we have a single TE controller
  that updates potentially thousands of PCE clients.
  how long would it take to react after a topology change ?
  (=recompute and upload new explicit routes).
  is it order of milliseconds ? order of seconds if not order of minutes ?

  it is obvious that somehow you need to distribute the
  TE-controller functionality such that you can re-act fast enough
  to process topology changes. - the more distributed the controller gets
  the more reactive the TE-controller system gets.

  next lets assume that every PCE client gets its own PCE server, co-located
  with a zero-latency path and you will discover that this is no
  different than what we have today.

  so what SR does wrt to TE is essentially shifting functionality around
  rather than solving it in any better way.

> As you know computing LFA sort of addresses this topic pretty well.
 ^^^^^^^^^^^

no i don't - and for my own education would be really interested to learn
how to provide node-protection for 1-hop (per-adjacency) labels.

> possible in 100% of coverage.

i am afraid SR is still not there -
trouble is that LFA is like "star wars" - there are many episodes …

episode 1: rfc5286 
episode 2: remote-LFA
episode 3: remote-LFA + DF

note that even at this stage we haven't arrived at "100% coverage - no matter what"
so likely there will be:

episode 4: remote-LFA + recursive DF

> encap can prove it is not ;) That's the beauty of it.

do we really want to revamp 15 years old discussions - get over it ;-)

MPLS is a useful technology and most important the MPLS data plane
is available today.

> Why not since the redundant technology has much better scaling and
 ^^^^^^^
> should be sufficient reason.

i have learned over the years that the pundits of "simpler, better
cheaper" are very creative minds in omitting details which matter,
(but do not necessarily work into their favor).

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 9 Sep 2013 14:19:29 +0200

> SR can simplify LSP monitoring OAM as compared to what's available today.

thats fine - and the OAM use case is an undisputed one - no worries;

the question to you is:

for doing OAM do you need an IPv6-SR flavor and if so why ?

> Finally, if you prefer to do analysis and planning work, then why shouldn't you? In parallel to those commencing work on specifying SR.

you cannot build a house without a plan beforehand, right ?

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2013 14:44:39 +0200

Hi Hannes,

> if i'd remove LDP support in favor of SR.

Pseudowires is an overlay application/service. As such a mechanism
which is much better suited to signal overlays should be recommended.

Hint: RFC4761 BGP works pretty well for p2mp discovery and signalling
... I see no reason to use bunch of LDP p2p sessions for that. Recall
discussions about LDP reflectors ;) ?

Likewise there are new emerging ways to signal overlay services, but I
think this is not the right place to discuss those.

>>>> 3. p2mp path construction

mLDP has not much in common with LDP other then name. It is PIM ported
to signal MPLS bindings. I did not say to get rid of mLDP.

>> seems pretty trivial to accomplish all of those with SR using number

You don't need to be that explicit .... ;-))

>   is it order of milliseconds ? order of seconds if not order of minutes ?

As compared with what ? With today the same single controller
instructing all headends to do the re- signalling

Note that I am of the strong opinion that reaction to failures should
be precomputed and preinstalled ahead of failure in any technology we
use. Then upon failure control plane can take as much as needed to
"converge".

>   the more reactive the TE-controller system gets.

See above ... I would argue that link state flooding is much more
faster then hop by hop RSVP signalling. You may not agree ...

>   different than what we have today.

If you follow some of the PCE discussions you would see that this
model does not allow for required optimization for number of traffic
distributions needs. Hint: Google centralized PCE model described in
public papers and presentations.

>   rather than solving it in any better way.

It solves the signalling issue. The domain wide coordination of
computation of paths is still the same.

>> As you know computing LFA sort of addresses this topic pretty well.

Creating LFA bypass of each node with when required SR segment going
far enough that loops are guaranteed not to occur looks like pretty
easy exercise.

Sorry I have no math prove that this will address any network
topology, but I also see no reason why it would not.

> i am afraid SR is still not there -

Perfect topic for this WG to make it be there. Can we add this to the charter ?

> episode 4: remote-LFA + recursive DF

And that's actually a great indication why issues are related and why
it would be productive to work on SR documents in RTGWG. I am sure
your familiarity with science-fiction movies could easily turn SR into
series of "start trek" episodes ...

> MPLS is a useful technology and most important the MPLS data plane

Sure. But as we do know MPLS lacks well defined inter-domain NNI, as
well as it's adoption in number of emerging solutions (DC fabrics) is
rather non existent.

> (but do not necessarily work into their favor).

I am not afraid to discuss details. But discussing details is very
different in practice from building the wall of let's just discuss
missing gaps from what we have today. I am afraid this time it will
not work that way .. sorry.

Cheers,
R.

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 14:54:38 +0200

Hannes,

I've talked about MPLS LSP monitoring. IPv6 to me is of interest in RFC4379 context only. As ECMP and tracing or adressing ECMP paths helps to reduce label stacks, ECMP related RFC4379 functionality is desireable with SR too, I think.

I'm not yet interested native IPv6 OAM functions.

Regards,

Ruediger

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]]
Sent: Monday, September 09, 2013 2:19 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: Re: [Status] Summary of STATUS BOF and the next steps

the question to you is:

---

From: Rob Shakir <[email-masked]>
Date: Mon, 9 Sep 2013 13:28:19 +0000

Hi Hannes,

>   the ingress router is in AS1 and it wants to control the exit link of AS2-->AS3.

rjs> I haven't seen any demand for this use case though. Similarly to the lack of demand (from my perspective) of inter-domain explicit routing/path placement.

rjs> I am going to go out on a limb here, and assert that there a huge set of other problems if one starts allowing AS1 to explicitly define routes within AS2 when they are outside different trust-domains. If we try and bring anything like this in scope in the initial phase, then I think we need to consult with the wider operational community as to how AS2 looks after its own interests, before considering what the technology solution is. Too often there are suggestions that we should develop technology solutions, where the current operational reality is that they are not implementable (based on commercial constraints, or requirements for deterministic behaviour).

rjs> So, based on this, let's tackle the intra-domain cases to start with. If and when we have operators who have requirements for this to be inter-domain, but intra-trust domain, then we can debate whether these are of interest to the WG, similarly to the debate we can have when there are operators raising requirements that need inter-domain, inter-trust domain functionality. However, I do not see why we should delay the implementation of intra-domain cases based on a possible future extension :-)

>> <…snip…>

original> Protocol work may be carried out in this working group or in other
original> working groups responsible for the protocols, in coordination with
original> this WG, and in agreement with the WG chairs and responsible ADs.
original> However, no protocol work will be adopted by a working group to
original> address the identified use-cases until the requirements document
original> motivating the protocol work has been sent to the IESG for
original> publication as an RFC.

revised> The <Name-TBD> working group will initially produce descriptions of 
revised> use cases, and requirements to be addressed. Where there is consensus
revised> within the WG for these use cases to be solved (demonstrated through
revised> WG adoption, and/or agreement with the chairs and responsible ADs),
revised> architectural specifications and requirements for protocol extensions 
revised> will be developed. Where new protocol extensions are developed, the
revised> relevant working groups (e.g., IS-IS, OSPF, IDR, PCEP…) will develop
revised> these, in conjunction with the WG.

rjs> Not perfect, but maybe a reasonable starting point?

r.

---

From: Rob Shakir <[email-masked]>
Date: Mon, 9 Sep 2013 13:48:54 +0000

Hannes,

>  rather than solving it in any better way.

As there has been significant effort to try and cover in the existing drafts, there are two classes of explicit routing problems (~= "traffic engineering" problems).

1) those that require admission control into resources,
2) those that require only placement away from the SPT, with no admission control.

With RSVP-TE we have to incur per-hop state for both cases - which means we must also perform signalling per-LSP, and incur mid-point load during re-signalling. This has real and practical problems which result in RSVP-TE not being deployed or SPs restricting their RSVP-TE deployment's scale. This, to me, is enough of a reason for us to determine that we'd like to try and find something that would solve 2), where we can remove the constraint on the # of LSPs.

If we develop something akin to this, then we are not so much "moving functionality around", but removing the need for the state which gives us no value for LSP type 1) (no constraint is specified where the mid-point would return a PathErr in RSVP-TE terms, so why do we keep it anywhere?).

For 1), we now have two choices, we can add the admission control centrally, or we can do it in a distributed fashion. Different planning approaches (for different organisations) will lend themselves to different approaches being taken. I can foresee that some networks will run RSVP-TE for 1) and IGP labels/SR LSPs for 2). Others will want stricter control on the paths requiring 1), such that they will want central computation instantiated in the data plane in the same manner as those in 2). I don't see a reason to restrict these approaches being available to operators such that they can make their own choices.

Additionally, we should bear in mind that RSVP-TE itself is not a panacea to centralised computation -- if we want to take consideration of information that is not immediately visible to the head-end PEs then we are likely to need ways that we can give each head-end device a hint (e.g., ERO) to describe how to route services.

Cheers,
r.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 9 Sep 2013 10:26:40 -0400

> topology, but I also see no reason why it would not.

[Alia] Robert, you are missing the problem.  The end of each segment has
the same egress
and ingress protection problems that any LSP has.  If a segment just
describes the next interface
or router, how is that router's failure protected against?

> Alia] I believe that all hop-by-hop fast-reroute techniques are in charter
already for RTGWG.
The need for arbitrarily long explicitly routed paths for complete coverage
with the rLFA (PQ-tunnels approach) is part of why the approach was
discarded in favor of not-via by its authors.  That said, RTGWG is in the
process of standardizing MRT-FRR, which provides 100% link and node
protection in any topologies without risk of looping traffic.

> [Alia] A complete solution is preferable to the need for continuing
episodes.

Alia

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2013 16:41:56 +0200

Hi Alia,

> [Alia] Robert, you are missing the problem.  The end of each segment has the
> same egress

Why is that difficult ?

When I am a transit node and I am forwarding packets to the end of
segment  (egress) the awareness of egress being down (from directly
connected detection protocol of your choice) I have ability to bypass
the failed node with a fixup of removing the end of segment
label/header from the packet's header.

That way the failed egress is bypassed/protected as long as failure
continues. The operation is local and uses to it's advantage the
global (domain wide) property of repair paths. It in fact get's better
as by looking at the next header the steering of the repair traffic
can be made optimal.

Contrary with labels of local significance such repair will not be
possible without employing yet another signalling protocol and I see
no good way to make it optimal at all.

Regards,
R.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 9 Sep 2013 10:56:46 -0400

Hi Robert,

On Monday, September 9, 2013, Robert Raszuk wrote:

> the

[Alia] It requires looking beyond the the top/current segment and
understanding what
is beneath.  More than just that,it requires setting up the necessary
different forwarding
state for all possible combinations.  Of course, if a segment points to an
LSP or an algorithmically
computed segment, the next-hop of that is not known by the router before
the segment starts.

So - to summarize - it requires a router to make forwarding decisions based
on labels under the
top of stack (if MPLS) or beyond the current pointer, it blows up the
forwarding state needed, and
the router may not know what the segment underneath means in terms of
next-next hop(s).

If only 1-hop segments are considered, the state expansion and added info
to read are still needed.
There are also the concerns about label stack expansion and MTU.

Regards,
Alia

and

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2013 17:08:33 +0200

Please notice that if we assume IPv6 forwarding the IPv6 header will
always contain destination IP address (most often BGP next hop in the
overlay) and included extension headers will provide just hints for
the segments.

Therefor the complication you describe with MPLS based forwarding I
see non existent with IP forwarding paradigm.

As far as state explosion .. I easily see a lot of room for
optimization as it will be very often the case that bypass can be
shared by many destinations.

Best regards,
R.

On Mon, Sep 9, 2013 at 4:56 PM, Alia Atlas <[email-masked]> wrote:
> computed segment, the next-hop of that is not known by the router before the
> segment starts.
>
> If only 1-hop segments are considered, the state expansion and added info to
> read are still needed.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 9 Sep 2013 11:31:38 -0400

> see non existent with IP forwarding paradigm.

[Alia] A strong desire doesn't make it so.   First, in IPv6, if the segment
info is just a hint, then ignoring it on failure could cause the traffic to
loop unless you are also stripping the segment extensions.  Second, if the
router respects the  segments, then this will still require reading ahead
in the segment list - with all of the extra microcode and handling that
implies.  It doesn't violate the existing architecture only because that
hasn't been fully defined.

> shared by many destinations.

Instead of 1 forwarding entry per neighbor, a router will need 1 for each
neighbor's neighbor and that assumes label or segment manipulation doesn't
need to be differentiated.

This would only work for 1-hop globally understood segments - though with
more computation, it might be possible for some algorithmically-based
segments to be figured out.

There are also the details around updating the segment list for
fast-reroute and what impact that has.

To be clear,  IMHO,  there are some interesting use-cases for
segment-routing, but it also has limitations that need to be
well-understood.  We need to define the architecture clearly and the
requirements and trade-offs.  We can't just assume that it will all work.

Alia

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 17:51:52 +0200

I think the discussion is moving to reviewing details rather than focusing anymore on the charter ... :) Let's keep this discussion for the WG discussion when it will exist and have a charter and a name :)

Now regarding the points from the last long email exchanges :

- I would also be in favor that interAS discussion must be part of the charter : intra-AS is first priority, but interAS is clearly needed : we have multiple ASes that would be able to run SR, so interdomain SR discussion would be interresting for us. Use case of multiple internal ASes is interresting, but dealing with Partners that are also running SR in their network is interresting also (including security concerns).

- I agree with Hannes point, that we are not here to say SR will replace this protocol or this protocol. We have some use case that must be addressed, let's find a solution for these. If some people can replace totally LDP or RSVP-TE in their network, it's good for them. If some other people are happy with what they have today and they want to keep RSVP-TE and LDP, it's fine too ...
Please just focus on the use case and solutions ...
I agree that today SR, as its is defined now, may not be able to replace LDP or RSVP-TE depending of the use case. And replacing LDP and RSVP-TE is not a target ... Many networks, many different use case, many protocol usage ! Let's keep a place for everyone :)

- For FRR node protection, let's wait a couple of weeks/months to have the WG starting ...  we may probably find something new in this area ... so we must not condamn SR today in this area ... it's just starting ... We must list this as a use case, and then propose a solution ...

Stephane

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Alia Atlas
Envoyé : lundi 9 septembre 2013 16:57
À : Robert Raszuk
Cc : Hannes Gredler; [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

Hi Robert,

Why is that difficult ?

[Alia] It requires looking beyond the the top/current segment and understanding what
is beneath.  More than just that,it requires setting up the necessary different forwarding
state for all possible combinations.  Of course, if a segment points to an LSP or an algorithmically
computed segment, the next-hop of that is not known by the router before the segment starts.

So - to summarize - it requires a router to make forwarding decisions based on labels under the
top of stack (if MPLS) or beyond the current pointer, it blows up the forwarding state needed, and
the router may not know what the segment underneath means in terms of next-next hop(s).

If only 1-hop segments are considered, the state expansion and added info to read are still needed.
There are also the concerns about label stack expansion and MTU.

Regards,
Alia

and

Regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2013 17:44:22 +0200

> unless you are also stripping the segment extensions.

Of course you should strip it. What's the point to keep it if you know
the segment endpoint is down ?

> router respects the  segments, then this will still require reading ahead in
> the segment list - with all of the extra microcode and handling that
> implies.

True.

> need to be differentiated.

Not really "neighbor's neighbor". At most to each segment end point,
but again subject to grouping.

> segments to be figured out.

I am not sure where "1-hop" limitation comes from.

> requirements and trade-offs.  We can't just assume that it will all work.

I fully agree.

r.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 9 Sep 2013 12:45:07 -0400

Hi Robert,

Here's my last message on this - because the key point is not really the
details of how and at what cost this could be done, but that there can be
architectural implications and the proper architecture and use-cases needs
to be nailed down before the protocol aspects.

> the segment endpoint is down ?

[Alia] First, this would be stripping all the segment information from the
IPv6 packet to ensure it doesn't loop again.  I assume the alternate would
be to move the context past the current segment to newly inserted segments
for the alternate.  Presumably, keeping the history of segments crossed is
valuable for IPv6 or else the proposed IPv6 extensions wouldn't focus on
that.

> but again subject to grouping.

[Alia] No - EXACTLY to each neighbor's neighbor.  For each segment that
ends at a neighbor N, the traffic in that segment would need to be looked
up (using MPLS terms) in the context of neighbor N and, having prepopulated
what label to swap to, be forwarded to the appropriate neighbor X of N.
The point is to protect the segment end-points.  This would have to be done
for protecting traffic going to every neighbor Y of N because N's
advertised segments and whether traffic is using them is unknown.

[Alia] An alternate, of course, is to advertise 1-hop+ segments where the
segment says end at N but the next-next-hop should be X.  That removes the
need for context label space at the cost of additional flooding - and
wouldn't work as well for algorithmically-based segments because of
reflooding upon topology changes.

> I am not sure where "1-hop" limitation comes from.
[Alia] How does the router S know what its neighbor N meant by segment-id L
in specific terms of the next-hop that N would forward the packet to?

> > requirements and trade-offs.  We can't just assume that it will all work.

[Alia] For the charter discussion, that's the important part.  I,
personally, want to see the architecture and use-cases clearly written out
(and there are some good starts) in a WG consensus process so that what is
and isn't feasible would be well understood.

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 9 Sep 2013 12:50:58 -0400

Hi Stephane,

On Mon, Sep 9, 2013 at 11:51 AM, <[email-masked]> wrote:

> **
> I think the discussion is moving to reviewing details rather than focusing
> anymore on the charter ... :) Let's keep this discussion for the WG
> discussion when it will exist and have a charter and a name :)
>

[Alia] Sure - that discussion was triggered by a claim that a limitation of
SR isn't at all an issue.  Given that one of the discussion points is how
fast to just dive into protocol-extensions because all this architecture
and use-cases isn't critical, I think it is important to consider some of
the assumptions of capability and their implications.

> - I would also be in favor that interAS discussion must be part of the
> charter : intra-AS is first priority, but interAS is clearly needed : we
> have multiple ASes that would be able to run SR, so interdomain
> SR discussion would be interresting for us. Use case of multiple internal
> ASes is interresting, but dealing with Partners that are also running SR in
> their network is interresting also (including security concerns).
>

[Alia] This is useful to hear.

>  - I agree with Hannes point, that we are not here to say SR will replace
> this protocol or this protocol. We have some use case that must be
> addressed, let's find a solution for these. If some people can replace
> totally LDP or RSVP-TE in their network, it's good for them. If some other
> people are happy with what they have today and they want to keep RSVP-TE
> and LDP, it's fine too ...
> I agree that today SR, as its is defined now, may not be able to replace
> LDP or RSVP-TE depending of the use case. And replacing LDP and RSVP-TE is
> not a target ... Many networks, many different use case, many protocol
> usage ! Let's keep a place for everyone :)
>
> - For FRR node protection, let's wait a couple of weeks/months to have the
> WG starting ...  we may probably find something new in this area ... so we
> must not condamn SR today in this area ... it's just starting ... We must
> list this as a use case, and then propose a solution ...
>

[Alia] If we don't have an architecture that supports it, our options are
less.  Fully describing the use-case would be good.  A strong motivation
for RSVP-TE has been its good fast-reroute solutions - covering link, node,
and SRLG.

Regards,
Alia

>  Stephane
>
>
>
>  ------------------------------
> *De :* [email-masked] [mailto:[email-masked]] *De la
> part de* Alia Atlas
> *Envoyé :* lundi 9 septembre 2013 16:57
> *À :* Robert Raszuk
> *Cc :* Hannes Gredler; [email-masked]
>
> *Objet :* Re: [Status] Summary of STATUS BOF and the next steps
>
> Hi Robert,
>

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 9 Sep 2013 10:01:28 -0700

Robert,

> of PCE or PCE like controllers rather then use RSVP-TE for explicit

Since you claim that it is "pretty trivial to accompish all of those
with SR..." please point to the document that describes how "trivial"
it is to accomplish one of those items, namely p2mp path construction,
with SR.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 9 Sep 2013 10:20:01 -0700

Rob,

> In-line as rjs>.

in-line...

> >  considerations must address the relations between domains (inter domain).

rjs> It seems a little odd to me that we would identify that there are inter-
rjs> domain issues to solve when there is no suggested use case that seemed 
rjs> to relate to this as a requirement. Any extensions of the technology 
rjs> developed within the WG to be inter-domain can be for future study.

Please note that the above bullet about the security considerations
and inter-domain has been taken verbatim from Stephane's proposal
to extend Hannes' proposed charter. See
http://www.ietf.org/mail-archive/web/status/current/msg00129.html.

Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2013 20:25:25 +0200

Hi Yakov,

> please point to the document that describes how "trivial"
> it is to accomplish one of those items, namely p2mp path
> construction with SR.

p2mp paths can be created in two ways:

A. Via multicast routing protocol in distributed fashion (ex mLDP, PIM etc ...)

B. Via controller programming replication points.

My claim was referring to the latter where using (for example I2RS
IETF protocol) replication points of segment X to segment Y, Z etc ...
can be programmed from controller to network elements.

Segment Routing is really helpful in this as notion of domain wide
labels allows easy traffic mapping to segments and on a per segment
base data plane traffic handling without any need for explicit path
signalling.

Note that this is not to say that I dismiss the need for former (point
A) and as you noticed in subsequent email to Hannes I clearly made the
distinction that mLDP is not something I would consider to be
replaced.

An interesting exercise could be undertaken to accomplish B with
today's locally significant MPLS without SR. I think it is doable
however it will require much more controller to network signalling as
well as clearly additional data plane support on today's network
equipment.

Best regards,
R.

> On Mon, Sep 9, 2013 at 7:01 PM, Yakov Rekhter <[email-masked]> wrote:
> Robert,
>

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 10:50:06 +0200

Hi all,

I'm creating a new mail topic because the "Summary of STATUS BOF ..." starts to be unreadable :)

Hannes and Stefano send to us two charter proposals that sounds good to me.

The main difference between the two proposals is that Stefano propose a segment bound to any type of instruction (forwarding, application or service based) while Hannes is focusing on forwarding actions (which is the first priority, and I think everybody agree on this).

It would be interresting to have a feedback from the mailinglist on this specific point.

IMHO, there is a strong interrest to explore the service actions bound to segment in a second step keeping forwarding as a priority.

Apart of this problem, here is a merge try of the two good proposals (I'm putting '<>' on hot topics :) ) :

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

Introduction
------------
The following use cases:
. Path computation based on awareness of utilization or performance
  data, within both centralized and distributed environments, . Multi-topology (dual planes, disjoint trees), . Simplification and reduction of signaling components (scaling), . Combined application and network layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.

have triggered work on the definition of new architecture and protocol extensions allowing to combine well known shortest path based routing paradigms with source/explicit routing methods. Some of these extensions have been implemented already.

Objective
---------

Define an architecture where a node can steer a packet through a network or set of networks (interdomain) on any path (shortest, non shortest, explicit, <service or application>).

In this architecture, routers are sharing a common trust model and are forming a <Name-TBD> domain.
Within this domain, a node can specify a path between itself and any destination in the domain. <The path may be a forwarding path, a service chaining path or a combination of both>.
It may then send any packet that passes through it through any path that it has specified and that is conform to the security rules. Downstream routers along the path within the <Name-TBD> domain forward the packet as specified by the router at the head-end of the path.

The architecture should support centralized and distributed path computation.

Work items :
------------------

Documents :
------------------
. Use Cases
. Architecture including security considerations
- Protocol extension requirements
. Interoperability Report

Protocol work may be carried out in this working group or in other working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordination with this WG, and in agreement with the WG chairs and responsible ADs.

Hope it helps to progress on the definition.

Stephane

-----Message d'origine-----
De : Hannes Gredler [mailto:[email-masked]]
Envoyé : vendredi 6 septembre 2013 18:27
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : Re: [Status] Summary of STATUS BOF and the next steps

hi stephane,

---

---

/hannes

---

From: Rob Shakir <[email-masked]>
Date: Tue, 10 Sep 2013 09:04:59 +0000

Hi Stephane,

Thanks for this, looks good! Comments in-line marked rjs>.

> The main difference between the two proposals is that Stefano propose a segment bound to any type of instruction (forwarding, application or service based) while Hannes is focusing on forwarding ac…

rjs> Agreed -- I think it would be useful to allow definitions of segments to identify different types of "service", since there appear to be some use cases (e.g., the explicit exit selection case) which require a segment type describing something that is not explicitly IGP-based.

> Apart of this problem, here is a merge try of the two good proposals (I'm putting '<>' on hot topics :) ) :

rjs> To clarify here, we define that our domain is under a common trust model (essentially, under common administrative control?), but then go on to talk about inter-domain elsewhere. Can we perhaps clarify (by defining a specific "<Name-TBD> domain" nomenclature) and say something like:

"In this architecture, routers sharing a common trust model form a <Name-TBD> domain. The architecture defined by this working group will allow a node to steer a packet between any source and destination node within the <Name-TBD> domain (formed of one or more networks), on any path (shortest, non-shortest, explicit or based on other characteristics specified by segment identifiers)."

> The architecture should support centralized and distributed path computation.

rjs> And then here "networks forming the <Name-TBD> domain"?

Thanks for the efforts,
r.

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 11:19:00 +0200

Souns good to me, (adding OAM also)

New recap :

Introduction
------------
The following use cases:

Objective
---------

Define an architecture where a node can steer a packet through a network or set of networks (interdomain) on any path.

In this architecture, routers sharing a common trust model form a <Name-TBD> domain. The architecture defined by this working group will allow a node to steer a packet between any source and destination node within the <Name-TBD> domain (formed of one or more networks), on any path (shortest, non-shortest, explicit or based on other characteristics specified by segment identifiers).

The architecture should support OAM functions.

Work items :
------------------

  considerations must address the relations between networks forming the <Name-TBD> domain (interAS).

Documents :
------------------
. Use Cases

-----Message d'origine-----
De : Rob Shakir [mailto:[email-masked]]
Envoyé : mardi 10 septembre 2013 11:05
À : LITKOWSKI Stephane DTF/DERX
Cc : Hannes Gredler; Stefano Previdi (sprevidi); [email-masked]
Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hi Stephane,

Thanks for the efforts,
r.

> De : Hannes Gredler [mailto:[email-masked]] Envoyé : vendredi 6
> septembre 2013 18:27 À : LITKOWSKI Stephane DTF/DERX Cc :
> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and the
> next steps
>
> hi stephane,
>
> the domain can specify a path between itself and any other router  in
> the domain. It may then send any packet that passes through it
> security rules. Downstream routers along the path within the
> <Name-TBD>  domain forward the packet as specified by the router at
> the head-end  of the path.
>
>>> Excuse me if I'm slightly out of the loop, but so far I have not
>>> seen a charter proposal, if there is one please point me to it.
>>>
>>> It seems a bit odd to put the cart (what the wg should do) before
>>> the horse (wg name). If we drill down the the charter first the wg
>>> name might be easier to figure out.
>>>
>>> /Loa
>>>
>>> PS
>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh;
>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro
>>>> Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>> De : [email-masked] [mailto:[email-masked]] De
>>>>> la part de John E Drake Envoyé : mardi 3 septembre 2013 15:02 À :
>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.
>>>>>>>>>> been put to me a number of times that STATUS is going to be
>>>>> __________________________________________________________________
>>>>> _ _ __ ___________________________________________________
>>>>>
>>>> _ _ ____________________________________________________
>>>>

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 11:48:36 +0200

Hi Stephane,

thanks for your proposal. Three remarks marked [RG] in line.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 10, 2013 11:19 AM
To: Rob Shakir
Cc: Hannes Gredler; [email-masked]; Stefano Previdi (sprevidi)
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

New recap :

  Introduction
  ------------
  The following use cases:
  . Path computation based on awareness of utilization or performance
    data, within both centralized and distributed environments,
  . Multi-topology (dual planes, disjoint trees),
  . Simplification and reduction of signaling components (scaling),
  . Combined application and network layer path specification,
  . Full coverage LFA-FRR,
  . Topology Aware OAM,
  . etc.

  have triggered work on the definition of new architecture and
  protocol extensions allowing to combine well known shortest path
  based routing paradigms with source/explicit routing methods.
  Some of these extensions have been implemented already.

  Objective
  ---------

  Define an architecture where a node can steer a packet through a
  network or set of networks (interdomain) on any path.

  In this architecture, routers sharing a common trust model form
  a <Name-TBD> domain. The architecture defined by this working
  group will allow a node to steer a packet between any source and
  destination node within the <Name-TBD> domain (formed of one or
  more networks), on any path (shortest, non-shortest, explicit
  or based on other characteristics specified by segment identifiers).

  It may then send any packet that passes through it through any
  path that it has specified and that is conform to the security
  rules. Downstream routers along the path within the <Name-TBD>
  domain forward the packet as specified by the router at the
  head-end of the path.

[RG] may be nit picking: to avoid the interpretation, that downstream
routers have to contact the head-end router to get specific routing
instructions.:
..forward the packet by the address stack inserted by the router
at the head-end...

  The architecture should support centralized and distributed
  path computation.

  Work items :
  ------------------

    considerations must address the relations between networks forming
    the <Name-TBD> domain (interAS).

  Documents :
  ------------------
  . Use Cases
  . Architecture including security considerations
  . Protocol extension requirements
  . Interoperability Report

  Protocol work may be carried out in this working group or in other
  working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...),
  in coordination with this WG, and in agreement with the WG chairs
  and responsible ADs.

[RG] Would the following be better:

Required protocol extensions are carried out in working groups
responsible...(). Work on new protocols may be carried out by
the <Name-TBD> WG ...

[RG] I'd appreciate if we were able to agree to avoid changes in
the MPLS forwarding plane, at least in the first phase. That should
be part of the charter. We could re-charter, should this result in a
deadlock later.

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 12:03:46 +0200

[RG] I'd appreciate if we were able to agree to avoid changes in the MPLS forwarding plane, at least in the first phase. That should be part of the charter. We could re-charter, should this result in a deadlock later.

[SLI] Agree also

[RG] may be nit picking: to avoid the interpretation, that downstream routers have to contact the head-end router to get specific routing
instructions.:
..forward the packet by the address stack inserted by the router at the head-end...

[SLI] Changed by : 
 "forward the packet by using the informations inserted by the router at the head-end"

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

Here is updated proposal :

Introduction
------------
The following use cases:

Objective
---------

It may then send any packet that passes through it through any path that it has specified and that is conform to the security rules. Downstream routers along the path within the <Name-TBD> domain forward the packet by using the informations inserted by the router at the head-end

As MPLS dataplane is largely deployed, the <Name-TBD> WG should avoid any modification in the MPLS dataplane when defining the architecture.

Work items :
------------------

Documents :
------------------
. Use Cases

Required protocol extensions are carried out in working groups responsible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by the <Name-TBD> WG. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mardi 10 septembre 2013 11:49
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : RE: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hi Stephane,

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 10, 2013 11:19 AM
To: Rob Shakir
Cc: Hannes Gredler; [email-masked]; Stefano Previdi (sprevidi)
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

New recap :

  Introduction
  ------------
  The following use cases:

  Objective
  ---------

[RG] may be nit picking: to avoid the interpretation, that downstream routers have to contact the head-end router to get specific routing
instructions.:
..forward the packet by the address stack inserted by the router at the head-end...

  Work items :
  ------------------

  Documents :
  ------------------
  . Use Cases

Required protocol extensions are carried out in working groups responsible...(). Work on new protocols may be carried out by the <Name-TBD> WG ...

[RG] I'd appreciate if we were able to agree to avoid changes in the MPLS forwarding plane, at least in the first phase. That should be part of the charter. We could re-charter, should this result in a deadlock later.

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 12:12:36 +0200

Hi Stephane,

allright, thanks.

Regards, Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, September 10, 2013 12:04 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: RE: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

[SLI] Agree also

[SLI] Changed by :

Introduction
------------
The following use cases:

Objective
---------

Work items :
------------------

Documents :
------------------
. Use Cases

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]]
Envoyé : mardi 10 septembre 2013 11:49
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]
Objet : RE: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hi Stephane,

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 10, 2013 11:19 AM
To: Rob Shakir
Cc: Hannes Gredler; [email-masked]; Stefano Previdi (sprevidi)
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

New recap :

  Introduction
  ------------
  The following use cases:

  Objective
  ---------

  Work items :
  ------------------

  Documents :
  ------------------
  . Use Cases

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 10 Sep 2013 10:30:03 +0000

Hi Stephane, Rob,

one preliminary remark: I prefer to use he therm "node" rather 
than "router". Use cases, such as Service Chaining requires that 
terminology.

some other comments below...

> Souns good to me, (adding OAM also)

[SP] As stated above, I'm fine with the above definition but I 
     assume this includes service chaining and that by "network 
     or set of networks" you intend "nodes" which may include 
     others things than just routers.

> In this architecture, routers sharing a common trust model form a <Name-TBD> domain. The architecture defined by this working group will allow a node to steer a packet between any source and destin…

[SP] without requiring to maintain state along the path, other 
     than in the ingress node.

> The architecture should support OAM functions.

[SP] The architecture should allow different mechanisms through which 
     a path is constructed. SR allows a variety of mechanisms, not 
     confined IGP/BGP path computation.

> Work items :

[SP] The architecture will support tunnel and non-tunnel paradigms
     The architecture will support multiple dataplanes: MPLS and V6	

Thanks.
s.

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 13:25:01 +0200

Agree on all proposal except :

"[SP] The architecture will support tunnel and non-tunnel paradigms
     The architecture will support multiple dataplanes: MPLS and V6"

I don't see the reason for this ... IMHO, the gap analysis and requirements inventory will result on saying or not : we must use tunnels and/or non tunnels, and the following dataplanes ... But I don't see the reason to put solutions directly in the charter ...
Could you explain your point ?

updated with the other comments :

Introduction
------------
The following use cases:

Objective
---------

Define an architecture where a node can steer a packet through a network or set of networks (interdomain) on any path without requiring to maintain state along the path, other than in the ingress node.

A node may be any type of device including routers or appliances.

In this architecture, nodes sharing a common trust model form a <Name-TBD> domain. The architecture defined by this working group will allow a node to steer a packet between any source and destination node within the <Name-TBD> domain (formed of one or more networks), on any path (shortest, non-shortest, explicit or based on other characteristics specified by segment identifiers).

It may then send any packet that passes through it through any path that it has specified and that is conform to the security rules. Downstream nodes along the path within the <Name-TBD> domain forward the packet by using the informations inserted by the node at the head-end

The architecture should allow different mechanisms through which
     a path is constructed. SR allows a variety of mechanisms, not
     confined IGP/BGP path computation.

Work items :
------------------

Documents :
------------------
. Use Cases

-----Message d'origine-----
De : Stefano Previdi (sprevidi) [mailto:[email-masked]]
Envoyé : mardi 10 septembre 2013 12:30
À : LITKOWSKI Stephane DTF/DERX; Rob Shakir
Cc : Hannes Gredler; [email-masked]
Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Hi Stephane, Rob,

one preliminary remark: I prefer to use he therm "node" rather than "router". Use cases, such as Service Chaining requires that terminology.

[SLI] Agree

[SLI] Agree

[SLI] Agree

Thanks.
s.

> Envoyé : mardi 10 septembre 2013 11:05 À : LITKOWSKI Stephane DTF/DERX
> Cc : Hannes Gredler; Stefano Previdi (sprevidi); [email-masked] Objet
> : Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...
>
> Hi Stephane,
>
>>> Andersson Cc : [email-masked] Objet : Re: [Status] Summary of
>>> STATUS BOF and the next steps
>>>
>>>>> Now the definition of the WG naming must be inline with the
>>>>> charter that will be defined ... (draft today)
>>>>>
>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>> On Behalf Of Mark Townsley
>>>>>>>> I note this since attempting to come up with an all
>>>>>>>> encompassing acronym will be difficult and Segment Routing is
>>>>>>>> generic enough to associate to multiple functions.
>>>>>>>
>>>>>>> have to have acronyms, but they do need to have an 8-char
>>>>>>> limited short name for the various automated tools not to break.
>>>>>>>
>>>>>>> - Mark
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Victor K
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> _________________________________________________________________
>>>>>> _ _ _ __ ___________________________________________________
>>>>>>
>>>>>> 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.
>>>>>>
>>>>> _ _ _ ____________________________________________________
>>>>>
>>> _ _ ___________________________________________________
>>>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 10 Sep 2013 16:58:28 +0000

On Sep 10, 2013, at 1:25 PM, <[email-masked]> wrote:

> I don't see the reason for this ... IMHO, the gap analysis and requirements inventory will result on saying or not

[SP] While I understand what brought the following statements
     in the proposed charter:
	"Having identified use-cases, architecture and security, 
	 the WG will identify gaps between currently available 
	 technologies and use-case requirements.
	 The WG will then define requirements for extensions to 
	 existing protocols or new protocols that address gaps 
	 that are identified."

     I'd like to point out with better precision what are the 
     directions we are ALREADY engaged into: dataplanes and 
     paradigms. As I mentioned in my charter proposal, we do have 
     implementations and multi-vendor interoperability tests will
     happen soon. So, I just want to be sure we don't ignore this 
     reality.

     MPLS and v6 data-plane are part of this reality, as well as 
     tunnel-based and non-tunnel based approaches.

> : we must use tunnels and/or non tunnels, and the following dataplanes ... But I don't see the reason to put solutions directly in the charter ...

these are not solutions these are way to avoid boundaries in the
framework.

Thanks.
s.

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 10 Sep 2013 19:27:03 +0200

stefano,

>     happen soon. So, I just want to be sure we don't ignore this 

HG> just because you have an implementation for <foo> does not constitute
    community interest. we are trying to build here a charter that
    matches what a broader community wants. if the use-case that you're concerned
    about (service-chaining and a new internet data plane #4) are compelling
    enough the group will work on it, but mandating that into the charter,
    without asking the though questions first seems a wrong start to me.

/hannes

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 10 Sep 2013 17:34:58 +0000

Hannes,

>    without asking the though questions first seems a wrong start to me.

[SP] Sorry to contradict but it's the exact opposite. If a group 
     of vendors decide to invest in implementations is because 
     they received, analyzed, processed a set of requirements 
     coming for operators who know pretty well what they do, what 
     they want to deploy and the technology they want the vendors 
     to deliver. This fits the definition of "community interest".

     My point is that I strongly _suggest_ IETF WG (any) not to 
     neglect these facts and not write a down a charter that will 
     take the "community" to argue whether "RSVP can do the job" 
     for the next 3 years.

     Having said that, whoever does NOT believe in the benefit of 
     a newly proposed technology, is always free to not implement 
     it and to not deploy it.

s.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 11 Sep 2013 02:14:42 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Stefano Previdi (sprevidi)
> 发送时间: 2013年9月11日 0:58
> 收件人: Stephane Litkowski
> 抄送: Hannes Gredler; Rob Shakir; [email-masked]
> 主题: Re: [Status] Good charter proposals from Hannes and Stefano : try to
> merge ...
> 
> 

I don't think it's suitable to mention developing IPv6 specific SR mechanism in the current charter unless there is no requirement for any change to the existing IPv6 data plane.

According to the following statements quoted from http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-9, "...The source route is encoded as an ordered list of segments instead of IP addresses..." If so, why not directly use an ordered list of labels (i.e., MPLS label stack) to do that (see http://www.ietf.org/mail-archive/web/status/current/msg00165.html)? 

*******************************************
   The main differences from the IPv6 source route model are:

Filsfils, et al.        Expires December 30, 2013               [Page 9]
 
Internet-Draft               Segment Routing                   June 2013

      The source route is encoded as an ordered list of segments instead
      of IP addresses.

      A segment can represent any instruction either a service or a
      topological path.  Topologically, the path to an IP address is
      often limited to the shortest-path to that address.  A segment can
      represent any path (e.g. an adjacency segment forces a packet to a
      nexthop through a specific adjacency even if the shortest-path to
      the next-hop does not use that adjacency).

      The ingress and egress egde routers are identified and always
      available, allowing for interesting accounting and policy
      applications.

      The source route functionality cannot be controlled from outside
      the SR domain.
*******************************************

Best regards,
Xiaohu

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 11 Sep 2013 08:14:35 +0200

stefano,

>     to deliver. This fits the definition of "community interest".

HG> interestingly enough i haven't encountered a network operator so
    far who says 'i need SR for service chaining' nor 
    we had somebody asking for this in the 'operator use case' slots
    in Berlin. - So who are they ? - can you manage such that
    they speak up and make their case ?

>     neglect these facts and not write a down a charter ...
 [ … ]

HG> i'd like to have some proof point for your 'facts' prior
    to making 'service chaining' a charter item.

>     a newly proposed technology, is always free to not implement 

HG> that is fine and well understood, but since you have a desire to
    standardize your 'newly proposed technology' you also need to play
    a bit by the rules.

---

From: <[email-masked]>
Date: Wed, 11 Sep 2013 11:53:32 +0200

Hannes,

Regarding "Service chaining", I would agree to not mention it directly in the charter (it's not mentionned explictly in my last proposal) BUT I don't want to close the door to other "action types" than forwarding. That's why using the wording "node" , "steering packets" seems to be good because it's large enough to address use cases that are not detailled today (for example service chaining).

So my approach would be , keep it large in definition using the proposed wording and then the use case analysis (in the work items) will give us what we need to address exactly.

Does it make sense for you to use this way ?

Thanks,

Stephane

-----Message d'origine-----
De : Hannes Gredler [mailto:[email-masked]]
Envoyé : mercredi 11 septembre 2013 08:15
À : Stefano Previdi
Cc : LITKOWSKI Stephane DTF/DERX; Rob Shakir; [email-masked]
Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

stefano,

On Sep 10, 2013, at 7:34 PM, Stefano Previdi (sprevidi) wrote:

>>>> I don't see the reason for this ... IMHO, the gap analysis and
>>>> requirements inventory will result on saying or not
>>>
>>>
>> HG> just because you have an implementation for <foo> does not
>> HG> constitute

 [ ... ]

>>>> It may then send any packet that passes through it through any path
>>>> that it has specified and that is conform to the security rules.
>>>> Downstream nodes along the path within the <Name-TBD> domain
>>>> forward the packet by using the informations inserted by the node
>>>> at the head-end
>>>>
>>>> The architecture should allow different mechanisms through which  a
>>>> path is constructed. SR allows a variety of mechanisms, not
>>>> - The WG will then define the architecture framework associated
>>>> with the security considerations. The architecture framework and
>>>> security considerations must address the relations between networks forming the <Name-TBD> domain (interAS).
>>>> - Having identified use-cases, architecture and security, the WG
>>>> will identify gaps between currently available technologies and
>>>> use-case requirements.
>>>> De : Stefano Previdi (sprevidi) [mailto:[email-masked]] Envoyé
>>>> : mardi 10 septembre 2013 12:30 À : LITKOWSKI Stephane DTF/DERX;
>>>> Rob Shakir Cc : Hannes Gredler; [email-masked] Objet : Re:
>>>> [Status] Good charter proposals from Hannes and Stefano : try to merge ...
>>>>
>>>> Hi Stephane, Rob,
>>>>
>>>>> . Path computation based on awareness of utilization or
>>>>> performance data, within both centralized and distributed environments, . Multi-topology (dual planes, disjoint trees), . Simplification and reduction of signaling components (scaling), . Combined application and network layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>>>>
>>>> assume this includes service chaining and that by "network  or set
>>>> of networks" you intend "nodes" which may include  others things
>>>> than just routers.
>>>>
>>>> [SLI] Agree
>>>>
>>>>
>>>> [SP] The architecture should allow different mechanisms through
>>>> which  a path is constructed. SR allows a variety of mechanisms,
>>>> not  confined IGP/BGP path computation.
>>>>
>>>> [SLI] Agree
>>>>
>>>>> Work items :
>>>>> ------------------
>>>>>
>>>>> - The WG will then define the architecture framework associated
>>>>> with the security considerations. The architecture framework and
>>>>> security considerations must address the relations between networks forming the <Name-TBD> domain (interAS).
>>>>> - Having identified use-cases, architecture and security, the WG
>>>>> will identify gaps between currently available technologies and
>>>>> use-case requirements.
>>>>> De : Rob Shakir [mailto:[email-masked]] Envoyé : mardi 10 septembre
>>>>> 2013 11:05 À : LITKOWSKI Stephane DTF/DERX Cc : Hannes Gredler;
>>>>> Stefano Previdi (sprevidi); [email-masked] Objet
>>>>>> . Path computation based on awareness of utilization or
>>>>>> performance data, within both centralized and distributed environments, . Multi-topology (dual planes, disjoint trees), . Simplification and reduction of signaling components (scaling), . Combined application and network layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.
>>>>>>
>>>>>> - The WG will then define the architecture framework associated
>>>>>> with the security considerations. The architecture framework and
>>>>>> security considerations must address the relations between domains (inter domain).
>>>>>
>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>> will identify gaps between currently available technologies and
>>>>>> use-case requirements.
>>>>>> - Protocol extension requirements . Interoperability Report
>>>>>>
>>>>>>
>>>>>> De : Hannes Gredler [mailto:[email-masked]] Envoyé : vendredi
>>>>>> 6 septembre 2013 18:27 À : LITKOWSKI Stephane DTF/DERX Cc :
>>>>>> [email-masked] Objet : Re: [Status] Summary of STATUS BOF and
>>>>>> the next steps
>>>>>>
>>>>>> hi stephane,
>>>>>>
>>>>>> - They can forward traffic through any path within the network
>>>>>> using shortest path, or any other (e.g., an explicit) path
>>>>>> - They share a common trust model. In this model, any router
>>>>>> within the domain can specify a path between itself and any other
>>>>>> router  in the domain. It may then send any packet that passes
>>>>>> through it through any path that it has specified and that is
>>>>>> conform to the security rules. Downstream routers along the path
>>>>>> within the <Name-TBD>  domain forward the packet as specified by
>>>>>> the router at the head-end  of the path.
>>>>>>
>>>>>> - The WG will then define the architecture framework associated
>>>>>> with the security considerations. The architecture framework and
>>>>>> security considerations must address the relations between domains (interdomain).
>>>>>> - Having identified use-cases, architecture and security, the WG
>>>>>> will identify gaps between currently available technologies and
>>>>>> use-case requirements.
>>>>>>> In case, we are using only directed forwarding (adjacency
>>>>>>> segment), could we still talk about tunneling ? (it's a very very small tunnel) Moreover talking about "stacking" is really dataplane agnostic (MPLS) ...
>>>>>>>
>>>>>>> - They can forward traffic through the shortest paths or paths
>>>>>>> other than the shortest (the latter called explicitly routed paths, or explicit paths)  [SLI] There is something else between SPT and Explicit path, you can define other algorithms than SPT to define a path, and it's not explicit path. Moreover I come back to my comment, on do we want to limit the scope to routing ? I would say no.
>>>>>>>
>>>>>>> charter , especially for the interAS case (trust yes, but not
>>>>>>> sure access to everything may not be good)
>>>>>>>
>>>>>>> - They can forward traffic through any path within the network
>>>>>>> using shortest path, non shortest path or explicit path
>>>>>>> la part de Hannes Gredler Envoyé : mardi 3 septembre 2013 18:31
>>>>>>> À : Loa Andersson Cc : [email-masked] Objet : Re: [Status]
>>>>>>> - They can forward traffic through the shortest paths or paths
>>>>>>> other than the shortest (the latter called explicitly routed
>>>>>>> paths, or explicit paths)
>>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have
>>>>>>>> not seen a charter proposal, if there is one please point me to it.
>>>>>>>>
>>>>>>>> It seems a bit odd to put the cart (what the wg should do)
>>>>>>>> before the horse (wg name). If we drill down the the charter
>>>>>>>> first the wg name might be easier to figure out.
>>>>>>>>
>>>>>>>> /Loa
>>>>>>>>
>>>>>>>> PS
>>>>>>>>> On Behalf Of [email-masked]
>>>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;
>>>>>>>>> Alvaro Retana (aretana); [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>>>>>>> De : [email-masked] [mailto:[email-masked]]
>>>>>>>>>> De la part de John E Drake Envoyé : mardi 3 septembre 2013 15:02 À :
>>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel;
>>>>>>>>>> [email-masked]; Stewart Bryant (stbryant) Objet : Re:
>>>>>>>>>>> From: [email-masked]
>>>>>>>>>>> [mailto:[email-masked]] On Behalf Of Mark Townsley
>>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian
>>>>>>>>>>> Farrel; Alvaro Retana (aretana); [email-masked]; Stewart
>>>>>>>>>>> Bryant
>>>>>>>>>>> (stbryant)
>>>>>>>>>>>> encompassing acronym will be difficult and Segment Routing
>>>>>>>>>>>> is generic enough to associate to multiple functions.
>>>>>>>>>>>
>>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do
>>>>>>>>>>> not have to have acronyms, but they do need to have an
>>>>>>>>>>> 8-char limited short name for the various automated tools not to break.
>>>>>>>>>>>
>>>>>>>>>>> - Mark
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Victor K
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> The second task, which hopefully should be relatively
>>>>>>>>>>>>>>> easy, is to find a better working name for the WG, since
>>>>>>>>>>>>>>> it has been put to me a number of times that STATUS is
>>>>>>>>>>>>>>> going to be confusing in text and a difficult search term.
>>>>>>>>>> _____________________________________________________________
>>>>>>>>>> ____ _ _ _ __
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>> ______________________________________________________________
>>>>>>>>> ____ _ _ _
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>> ________________________________________________________________
>>>>>>> ____ _ _ ___________________________________________________
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>> ____ _ ___________________________________________________
>>>>>>
>>>>> ____ ___________________________________________________
>>>>>
>>>> ______________________________________________________
>>>>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 11 Sep 2013 10:37:45 +0000

Hi Xiaohu,

> According to the following statements quoted from http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-9, "...The source route is encoded as an ordered list of segments instead o…

v6 dataplane allows more effective source route capability by 
leveraging extensions headers. Hence the proposal that will
consist of defining a new Extension Header for SR where the 
segment list is encoded and _preserved_ throughout the path.

So, I do strongly believe we have to work on v6 and since we're 
in the definition of a charter (i.e.: not the detailed review 
of the solutions) I believe v6 should be part of it.

Thanks.
s.

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 11 Sep 2013 14:32:08 -0400

Stephane,

This seems like a very reasonable way forward to me and I think the last draft charter you posted is "about right". In particular I want to support the idea that "the use case analysis ... will give us what we need to address exactly". 

--John

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Sep 2013 01:27:58 +0000

Hi Stefano,

> 发送时间: 2013年9月11日 18:38
> 抄送: Stephane Litkowski; Rob Shakir; [email-masked]; Hannes Gredler
> > I don't think it's suitable to mention developing IPv6 specific SR mechanism in
> the current charter unless there is no requirement for any change to the existing
> IPv6 data plane.
> 
> > According to the following statements quoted from
> http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-9, "...The
> source route is encoded as an ordered list of segments instead of IP addresses..."
> If so, why not directly use an ordered list of labels (i.e., MPLS label stack) to do
> that (see
> http://www.ietf.org/mail-archive/web/status/current/msg00165.html)?
> 
> 

What's the purpose of preserving the whole segment list throughout the path? In other words, isn't it enough to contain the information of ingress and egress nodes throughout the path?

Best regards,
Xiaohu

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 12 Sep 2013 12:43:45 +0000

Hi Xiaohu,

> What's the purpose of preserving the whole segment list throughout the path? In other words, isn't it enough to contain the information of ingress and egress nodes throughout the path?

there are use cases, among which OAM, that will leverage the 
availability of the segment list. v6 has good native properties 
that allow to insert explicit/source routing paradigms in the 
forwarding plane. Most of SW/HW implementations today can handle 
this without incurring HW performance penalty.

Thanks.
s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 12 Sep 2013 12:53:12 +0000

Hi John,

On Sep 11, 2013, at 8:32 PM, John G. Scudder wrote:
> Stephane,
> 
> This seems like a very reasonable way forward to me and I think the last draft charter you posted is "about right".

I have some concerns.

At least, Id' like to see IPv6 explicitly mentioned. 

s.

> In particular I want to support the idea that "the use case analysis ... will give us what we need to address exactly". 
> 
> --John
>

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 12 Sep 2013 15:23:41 +0200

hi stefano,

can you *share* your proposed 'extension header' spec ?
such that ASIC/hardware people can assess themselves:

1. what are the implications wrt to deployed hardware
2. if there is a forwarding penalty

/hannes

On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote:
[ … ]

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 12 Sep 2013 14:10:18 +0000

> can you *share* your proposed 'extension header' spec ?

when ready, yes. It's going to be submitted by Vancouver meeting.
In the mean time, I believe we can still talk about the charter 
or is the rule that we have to spec out all details first ?

s.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 12 Sep 2013 10:28:29 -0400

Stefano,

> or is the rule that we have to spec out all details first ?

When you both claim
" Most of SW/HW implementations today can handle this without incurring HW
performance penalty."
and that there is interoperability testing planned for an unstandardized
version and not wanting to wait
to document use-cases that would require it, then - yes - a certain degree
of transparency is desirable.

Personally, having it work both ways
   a) all ready, interoperable, no HW penalties (on any hardware?), and
needed
   b) not ready to fully document use-cases requiring it nor the proposed
header extensions

seems like remarkable double-think. To expect everyone to accept your
assertions of (a) without any of (b)
seems unusually absurd.

If you don't even have a draft documenting the proposed 'extension header'
spec, then the claim that it
works without penalty on all HW seems like an astonishing stretch.

Finally, work on drafts and discussions should happen between meetings too.
 It's much easier to focus on
specific drafts and issues when everything else in the IETF isn't
happening.   Deciding to focus only on the deadlines
associated with IETF meetings is part of what slows the IETF down.  I
believe that isn't your goal here...  Getting
continuous work is something that I, for instance, am trying to stress in
I2RS.

Regards,
Alia

> >>> What's the purpose of preserving the whole segment list throughout the
> path? In other words, isn't it enough to contain the information of ingress
> and egress nodes throughout the path?
> >>
> >>

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 12 Sep 2013 16:45:05 +0200

stefano,

> when ready, yes. It's going to be submitted by Vancouver meeting.
                                                ^^^^^^^^^^^^^^^^^^

HG> as per your email below i was under the impression that 'soon' is 'sooner' -
    and having a spec is precursor for doing interop testing. -
    looks like that you are not there yet.

---

     [ … ]
     As I mentioned in my charter proposal, we do have
     implementations and multi-vendor interoperability tests will
     happen soon. So, I just want to be sure we don't ignore this
     reality.
---

     in summary:
     the list hasn't seen a good case for both service-chaining
     and why we need another data plane in support for this.

     i concur therefore with stephane that we shall add exploration
     if those things are needed in the charter, but its a bit premature
     (also in lieu of written down use-cases and proposals) to make it
     mandatory to include now.

> or is the rule that we have to spec out all details first ?

HG> there is a difference between:

"i want the charter to look like this,
because this is what i am currently developing"

   and

"lets work on question(s) <a,b,c> in an open-forum and the
answers are going to shape what changes we need to existing
protocols and forwarding paradigms"

/hannes

---

From: John E Drake <[email-masked]>
Date: Thu, 12 Sep 2013 14:55:34 +0000

Stefano,

As I pointed out to Peter last week, it is much better to have the route a packet takes through a network than the route the ingress node thinks it will take.  Further, if the latter is used in conjunction with nodal segments, then all you will have is a loose source route.

Sent from my iPhone

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 12 Sep 2013 15:14:18 +0000

Alia, Hannes,

> Finally, work on drafts and discussions should happen between meetings too.  It's much easier to focus on
> specific drafts and issues when everything else in the IETF isn't happening.   Deciding to focus only on the deadlines
> associated with IETF meetings is part of what slows the IETF down.  I believe that isn't your goal here...  Getting
> continuous work is something that I, for instance, am trying to stress in I2RS.

the implementations interop tests are based on mpls data-plane.

What I'd like to see in the charter is that the control plane must/should 
be agnostic to data-plane instantiation so to support mpls and v6.

Note that we already have the SR-ISIS draft which _is_ data-plane agnostic.

Same in the mechanisms can be constructed, i.e., not bound to solely IGP 
but rather give the ability to other components to construct paths using 
segments.

My time availability doesn't allow me to go faster so I will submit SR-v6 
use-cases SR-IPv6 Extension Header and hopefully I'll be allowed to present 
them both at next meeting.

s.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 12 Sep 2013 16:08:27 +0000

Sorry, John, did not see your response but we've been having spam filter problems lately here.

No disagreement with "it is much better to have the route a packet takes through a network than the route the ingress node thinks it will take"

Although the deviations from the intended route need to controllable (on/off) so that centralized TE ( like SDN wants to do ) can be assured that its math is consistent with what is really happening in the network.

Cheers,

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Thursday, September 12, 2013 10:56 AM
To: Stefano Previdi (sprevidi)
Cc: Stephane Litkowski; Xuxiaohu; Rob Shakir; [email-masked]; Hannes Gredler
Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Stefano,

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Thu, 12 Sep 2013 16:43:36 +0000

Peter,

I can think of a least three reasons why there will be a difference between the source route computed by the ingress and the route a packet actually takes.  Viz, a transit node incorrectly processes the source route, a transit node performs fast reroute, and a transit node performs loose route expansion when the source route contains one or more node segments.

Yours Irrespectively,

John

> Sent: Thursday, September 12, 2013 9:08 AM
> To: [email-masked]
> No disagreement with "it is much better to have the route a packet takes
> through a network than the route the ingress node thinks it will take"
> 
> Although the deviations from the intended route need to controllable
> (on/off) so that centralized TE ( like SDN wants to do ) can be assured that its
> math is consistent with what is really happening in the network.
> 
> Cheers,
> 
> Peter
> 
> Of John E Drake
> As I pointed out to Peter last week, it is much better to have the route a
> packet takes through a network than the route the ingress node thinks it will
> take.  Further, if the latter is used in conjunction with nodal segments, then
> all you will have is a loose source route.
> 
> Sent from my iPhone
> 
> >>> 主题: Re: [Status] Good charter proposals from Hannes and Stefano :
> >>> try to merge ...
> >>>
> >>> Hi Xiaohu,
> >>>
> >>>>> 主题: Re: [Status] Good charter proposals from Hannes and Stefano :
> >>>>> try to merge ...
> >>>>>
> >>>>>
> >>>>>> "[SP] The architecture will support tunnel and non-tunnel
> >>>>>> paradigms  The architecture will support multiple dataplanes: MPLS
> and V6"
> >>>>>>
> >>> http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#p
> >>> age-9, "...The source route is encoded as an ordered list of segments
> instead of IP addresses..."
> >>> If so, why not directly use an ordered list of labels (i.e., MPLS
> >>> label stack) to do that (see
> >>> leveraging extensions headers. Hence the proposal that will consist
> >>> of defining a new Extension Header for SR where the segment list is
> >>> encoded and _preserved_ throughout the path.
> >>
> > availability of the segment list. v6 has good native properties that
> > allow to insert explicit/source routing paradigms in the forwarding
> > plane. Most of SW/HW implementations today can handle this without
> > incurring HW performance penalty.
> >
> > Thanks.
> > s.
> >
> >
> >>
> >> Best regards,
> >> Xiaohu
> >>
> >>> So, I do strongly believe we have to work on v6 and since we're in
> >>> the definition of a charter (i.e.: not the detailed review of the
> >>> solutions) I believe v6 should be part of it.
> >>>
> >>> Thanks.
> >>> s.
> >>>
> >>>
> >>>>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 12 Sep 2013 19:46:52 +0000

John, yes agree, 

The 'incorrect forwarding' one is interesting because you can go a long way before the error is found when the hops are strict local link identifiers. However it's possible to do a form of reverse segment check to minimize these errors if you are recording at least the previous hop but it's not foolproof of course.

Anyway - reversal is useful, recording reverse of where you've actually been is useful, forcing adherence to the ingress node's SR is useful, but so is allowing a degree of flexibility for fast reroute / loose hops.

Cheers,

Peter

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, September 12, 2013 12:44 PM
To: AshwoodsmithPeter; [email-masked]
Subject: RE: [Status] Good charter proposals from Hannes and Stefano : try to merge ...

Peter,

Yours Irrespectively,

John

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 13 Sep 2013 14:13:35 -0400

Stefano/Xiaohu,

On Wed, Sep 11, 2013 at 6:37 AM, Stefano Previdi (sprevidi) <
[email-masked]> wrote:

>
> >
> > I don't think it's suitable to mention developing IPv6 specific SR
> mechanism in the current charter unless there is no requirement for any
> change to the existing IPv6 data plane.
>
> http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-9,
> "...The source route is encoded as an ordered list of segments instead of
> IP addresses..." If so, why not directly use an ordered list of labels
> (i.e., MPLS label stack) to do that (see
[VK].  I strongly agree that we should be including v6 work within the

charter.  As noted at the BoF in Berlin, I made similar comments (along

with at least one other operator) of the need for this.

I think discounting a v6 data plan option at this point is premature and

will be ignoring input from operators which provided use case(s).

We should include it.

Regards,

Victor K