Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

From: Martin Vigoureux <[email-masked]>
Date: Fri, 27 Jan 2017 12:05:05 +0100

Hello Working Group,

This email starts a 2-week Working Group Last Call on 
draft-ietf-spring-segment-routing-mpls-06 [1].

¤ Please read the document if you haven't read the most recent
version yet, and send your comments to the list, no later than the
*12th of February*.
Note that this is *not only* a call for comments on the document; it is 
also a call for support (or not) to publish this document as a Proposed 
Standard RFC.

¤ We have already polled for IPR knowledge on this document and all 
Authors have replied.
IPR exists against this document and has been disclosed [2].

Thank you

M&B

---
[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
[2] 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-mpls

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 27 Jan 2017 13:00:15 +0000

Hi, 

I have read the document and support publication.

Thanks,
Acee 

On 1/27/17, 6:05 AM, "spring on behalf of Martin Vigoureux"
<[email-masked] on behalf of [email-masked]> wrote:

>[1] 
>https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/
>[2] 
>_______________________________________________
>spring mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spring

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 27 Jan 2017 10:34:08 -0800

Hi Martin,

support as co-author.
 
Cheers,
Jeff

On 1/27/17, 03:05, "spring on behalf of Martin Vigoureux" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Working Group,

    
    
    Thank you
    
    M&B
    
    ---

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 27 Jan 2017 19:59:23 +0000

Support.

One quick comment: 

While section 3 correctly documents MPLS instantiation of SR -  given the constructs SR has (ADJ SID for example) it's good to document SID/Label depth implications in the deployments.

--
Uma C.

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Martin Vigoureux
Sent: Friday, January 27, 2017 3:05 AM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

Hello Working Group,

¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *12th of February*.
Note that this is *not only* a call for comments on the document; it is also a call for support (or not) to publish this document as a Proposed Standard RFC.

¤ We have already polled for IPR knowledge on this document and all Authors have replied.
IPR exists against this document and has been disclosed [2].

Thank you

M&B

---

---

From: Pushpasis Sarkar <[email-masked]>
Date: Sat, 28 Jan 2017 09:44:27 +0530

+1

Thanks and regards,
-Pushpasis

On Fri, Jan 27, 2017 at 6:30 PM, Acee Lindem (acee) <[email-masked]> wrote:

> >https://datatracker.ietf.org/ipr/search/?submit=draft&id=
> draft-ietf-spring
> >-segment-routing-mpls
> >

---

From: Martin Horneffer <[email-masked]>
Date: Mon, 30 Jan 2017 09:58:53 +0100

Hello,

support from me as co-author and operator.

Bets regards, Martin

Am 27.01.17 um 12:05 schrieb Martin Vigoureux:
> Note that this is *not only* a call for comments on the document; it 
> is also a call for support (or not) to publish this document as a 
> Proposed Standard RFC.
>

---

From: <[email-masked]>
Date: Mon, 30 Jan 2017 09:04:13 +0000

Support

-----Original Message-----
From: Martin Vigoureux [mailto:[email-masked]] 
Sent: Friday, January 27, 2017 12:05
To: [email-masked]
Cc: [email-masked]
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-06

Hello Working Group,

Thank you

M&B

---

_________________________________________________________________________________________________________________________

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: Martin Horneffer <[email-masked]>
Date: Mon, 30 Jan 2017 10:13:22 +0100

Hello Uma,

what kind of label depth discussion are you thinking of?

It seems to me this could easily become an endless discussion again. 
People seem to have very different views on it. Thus I'm not sure 
whether it would be suitable for this document.

BTW:

For my needs, bandwidth optimization is one of the major use cases for 
all traffic engineering technologies such as SR or RSVP.

We are currently supporting scientific university research about this, 
and first results give strong confirmation that for bandwidth 
optimization in real world networks you rarely need more than 1 
additional segment. Or rather, the additional efficiency gained by using 
mor than 1 additional segment is very small. We compare a global real 
backbone network with current routing, theoretical MCF optimization and 
realistic optimization with 1 (or 2 or 3) additional traffic engineering 
segments (aka 2-SR, 3-SR, 4-SR).
Thus, from my point of view, an SR optimized network would typically 
have the same label stack depth as a similarily RSVP optimized network 
in some places, and a smaller label stack for the overall average .

All other use-cases I found of serious interest so far all work with 1 
additional segment (i.e. label) at most.

Best regards, Martin

---

From: <[email-masked]>
Date: Mon, 30 Jan 2017 09:48:28 +0000

I also support the document.

Regards, Ruediger

-----Original Message-----
From: Martin Vigoureux [mailto:[email-masked]]
Sent: Friday, January 27, 2017 12:05
To: [email-masked]
Cc: [email-masked]
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-06

Hello Working Group,

Thank you

M&B

---

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: Stewart Bryant <[email-masked]>
Date: Mon, 30 Jan 2017 10:09:20 +0000

I agree.

Whilst, as indicated later in the thread, some of the cases studied so 
far may only need a single label, this is a powerful general purpose 
technology that  will be used for many purposes that have not yet been 
considered. Some discussion of the implication of the label stack limit 
imposed by current h/w and the need to consider this in future designs 
would be useful.

Stewart

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 30 Jan 2017 11:27:54 +0000

I agree with Martin,

I think we have discussed this at length and I wouldn't re-spin the debate (and come to the same conclusion again and again). The manageability section of the architecture draft mention that a node may want to signal its stack capabilities and we have igp extensions for that.

s.

> On Jan 30, 2017, at 10:13 AM, Martin Horneffer <[email-masked]> wrote:
> 
> Hello Uma,
> 
> It seems to me this could easily become an endless discussion again. People seem to have very different views on it. Thus I'm not sure whether it would be suitable for this document.
> 
> BTW:
> 
> For my needs, bandwidth optimization is one of the major use cases for all traffic engineering technologies such as SR or RSVP.
> 
> We are currently supporting scientific university research about this, and first results give strong confirmation that for bandwidth optimization in real world networks you rarely need more than 1 additional segment. Or rather, the additional efficiency gained by using mor than 1 additional segment is very small. We compare a global real backbone network with current routing, theoretical MCF optimization and realistic optimization with 1 (or 2 or 3) additional traffic engineering segments (aka 2-SR, 3-SR, 4-SR).
> Thus, from my point of view, an SR optimized network would typically have the same label stack depth as a similarily RSVP optimized network in some places, and a smaller label stack for the overall average .
> 
> All other use-cases I found of serious interest so far all work with 1 additional segment (i.e. label) at most.
> 
> Best regards, Martin
> 
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 30 Jan 2017 11:51:02 +0000

Stefano,

This is the document that someone interested in SR from and an MPLS 
perspective may well start with. A discussion on the issue of label 
stack depth and the practical constrains is thus very much in scope. The 
fact that you had a debate in the past immediately points to the need 
for a summary of the key issues and conclusions in this document.

Stewart

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 30 Jan 2017 17:39:49 +0000

Hi Martin, Stefano,

>It seems to me this could easily become an endless discussion again. People seem to have very different views on it. Thus I'm not sure whether it would be suitable for this document.

Sorry, that was not at all my intention to get into an endless discussion.
Being an SR MPLS data plane document, I felt discussion or reference to SID depth related aspects would be important. This is one of the aspects we contended with, when SR is being discussed in MBH deployments in my previous organization.

> The manageability section of the architecture draft mention that a node may want to signal its stack capabilities and we have igp extensions for that.

I am fine with referencing both or a summary as pointed by Stewart below at some appropriate place in the document.

--
Uma C.

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Monday, January 30, 2017 3:51 AM
To: Stefano Previdi (sprevidi) <[email-masked]>; Martin Horneffer <[email-masked]>
Cc: [email-masked]; [email-masked]; Martin Vigoureux <[email-masked]>; Uma Chunduri <[email-masked]>; [email-masked]
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06

Stefano,

This is the document that someone interested in SR from and an MPLS perspective may well start with. A discussion on the issue of label stack depth and the practical constrains is thus very much in scope. The fact that you had a debate in the past immediately points to the need for a summary of the key issues and conclusions in this document.

Stewart

On 30/01/2017 11:27, Stefano Previdi (sprevidi) wrote:
>>> Subject: [spring] WG Last Call for 
>>> draft-ietf-spring-segment-routing-mpls-06
>>>
>>> Hello Working Group,
>>>

---

From: Edward Crabbe <[email-masked]>
Date: Mon, 30 Jan 2017 12:30:32 -0800

Hi Martin;

Support as co-author.

cheers,
   -ed

On Fri, Jan 27, 2017 at 3:05 AM, Martin Vigoureux <
[email-masked]> wrote:

> [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=dra
> ft-ietf-spring-segment-routing-mpls
>

---

From: Rob Shakir <[email-masked]>
Date: Mon, 30 Jan 2017 21:55:17 +0000

Hi Martin,

Support, as a co-author.

r.