Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[John E Drake]

Robert,

My apologies,  I thought you were talking about this draft:  
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02, which is 
the draft to which I was referring in my reply to you.

Yours Irrespectively,

John

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Wednesday, March 14, 2018 12:38 PM
To: John E Drake 
Cc: EXT - daniel.bern...@bell.ca ; mpls 
; SPRING WG List ; s...@ietf.org; James N 
Guichard ; adr...@olddog.co.uk; Francois Clad 
(fclad) 
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

> [JD  They both draw upon the same heritage.

I respectfully disagree John with that. One should not equate control plane 
solution with data plane embedded solution. Those are completely different 
spaces and different heritages.

I would further claim that we do have much more heritage in control plane path 
steering rather then in data plane embedding of the same.

Cheers,
R.



On Wed, Mar 14, 2018 at 5:30 PM, John E Drake 
> wrote:
Robert,

Comments inline

Yours Irrespectively,

John

From: rras...@gmail.com 
[mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Wednesday, March 14, 2018 12:00 PM
To: John E Drake >
Cc: EXT - daniel.bern...@bell.ca 
>; mpls 
>; SPRING WG List 
>; s...@ietf.org; 
James N Guichard 
>; 
adr...@olddog.co.uk; Francois Clad (fclad) 
>
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

Daniel,

It has a multiplicity of issues, primarily wrt scalability and ease of 
configuration.


​Am I reading your comment correctly that draft-ietf-bess-service-chaining-04 
is unscalable and hard to configure and draft ​draft-farrel-mpls-sfc is 
superior ?


[JD]  The authors of that draft provided much input and guidance to the authors 
of ​draft-farrel-mpls-sfc.


Please observe that your own Juniper products are based already for a long time 
on the former and as you admited no one has any product based on the latter.


[JD]  I am not sure of your point.


Doesn't this makes it a bit of an odd argument ? Also please do notice that  
draft-ietf-bess-service-chaining-04 vastly reuses 20 years of experience of 
L3VPNs service so your claim may be IMHO a little weak :)


[JD  They both draw upon the same heritage.


Cheers,
R.


 Yours Irrespectively,
John

From: spring [mailto:spring-boun...@ietf.org] 
On Behalf Of Bernier, Daniel
Sent: Wednesday, March 14, 2018 10:54 AM
To: John E Drake >; Robert Raszuk 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
James N Guichard 
>; 
adr...@olddog.co.uk; Francois Clad (fclad) 
>
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"


Hi John,



Don't we already have 
draft-fm-bess-service-chaining-01
 to perform service chains with existing MPLS implementations ?



Thanks,​



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Robert Raszuk]

 *> [JD  They both draw upon the same heritage.*

I respectfully disagree John with that. One should not equate control plane
solution with data plane embedded solution. Those are completely different
spaces and different heritages.

I would further claim that we do have much more heritage in control plane
path steering rather then in data plane embedding of the same.

Cheers,
R.



On Wed, Mar 14, 2018 at 5:30 PM, John E Drake  wrote:

> Robert,
>
>
>
> Comments inline
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Wednesday, March 14, 2018 12:00 PM
> *To:* John E Drake 
> *Cc:* EXT - daniel.bern...@bell.ca ; mpls <
> m...@ietf.org>; SPRING WG List ; s...@ietf.org; James N
> Guichard ; adr...@olddog.co.uk; Francois
> Clad (fclad) 
> *Subject:* Re: [spring] [mpls] [sfc] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi John,
>
>
>
> Daniel,
>
>
>
> It has a multiplicity of issues, primarily wrt scalability and ease of
> configuration.
>
>
>
>
>
> ​Am I reading your comment correctly that draft-ietf-bess-service-chaining-04
> is unscalable and hard to configure and draft ​draft-farrel-mpls-sfc is
> superior ?
>
>
>
>
>
> *[JD]  The authors of that draft provided much input and guidance to the
> authors of ​draft-farrel-mpls-sfc. *
>
>
>
>
>
> Please observe that your own Juniper products are based already for a long
> time on the former and as you admited no one has any product based on the
> latter.
>
>
>
>
>
> *[JD]  I am not sure of your point.*
>
>
>
>
>
> Doesn't this makes it a bit of an odd argument ? Also please do notice
> that  draft-ietf-bess-service-chaining-04 vastly reuses 20 years of
> experience of L3VPNs service so your claim may be IMHO a little weak :)
>
>
>
>
>
> *[JD  They both draw upon the same heritage. *
>
>
>
>
>
> Cheers,
> R.
>
>
>
>
>
>  Yours Irrespectively,
>
> John
>
>
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Bernier,
> Daniel
> *Sent:* Wednesday, March 14, 2018 10:54 AM
> *To:* John E Drake ; Robert Raszuk 
> *Cc:* mpls ; SPRING WG List ; s...@ietf.org;
> James N Guichard ; adr...@olddog.co.uk;
> Francois Clad (fclad) 
>
> *Subject:* Re: [spring] [mpls] [sfc] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi John,
>
>
>
> Don't we already have draft-fm-bess-service-chaining-01
> 
> to perform service chains with existing MPLS implementations ?
>
>
>
> Thanks,​
>
>
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[John E Drake]

Robert,

Comments inline

Yours Irrespectively,

John

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Wednesday, March 14, 2018 12:00 PM
To: John E Drake 
Cc: EXT - daniel.bern...@bell.ca ; mpls 
; SPRING WG List ; s...@ietf.org; James N 
Guichard ; adr...@olddog.co.uk; Francois Clad 
(fclad) 
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

Daniel,

It has a multiplicity of issues, primarily wrt scalability and ease of 
configuration.


​Am I reading your comment correctly that draft-ietf-bess-service-chaining-04 
is unscalable and hard to configure and draft ​draft-farrel-mpls-sfc is 
superior ?


[JD]  The authors of that draft provided much input and guidance to the authors 
of ​draft-farrel-mpls-sfc.


Please observe that your own Juniper products are based already for a long time 
on the former and as you admited no one has any product based on the latter.


[JD]  I am not sure of your point.


Doesn't this makes it a bit of an odd argument ? Also please do notice that  
draft-ietf-bess-service-chaining-04 vastly reuses 20 years of experience of 
L3VPNs service so your claim may be IMHO a little weak :)


[JD  They both draw upon the same heritage.


Cheers,
R.


 Yours Irrespectively,
John

From: spring [mailto:spring-boun...@ietf.org] 
On Behalf Of Bernier, Daniel
Sent: Wednesday, March 14, 2018 10:54 AM
To: John E Drake >; Robert Raszuk 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
James N Guichard 
>; 
adr...@olddog.co.uk; Francois Clad (fclad) 
>
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"


Hi John,



Don't we already have 
draft-fm-bess-service-chaining-01
 to perform service chains with existing MPLS implementations ?



Thanks,​


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Robert Raszuk]

Hi John,

Daniel,
>
>
>
> It has a multiplicity of issues, primarily wrt scalability and ease of
> configuration.
>
>

​Am I reading your comment correctly that
draft-ietf-bess-service-chaining-04 is unscalable and hard to configure and
draft ​draft-farrel-mpls-sfc is superior ?

Please observe that your own Juniper products are based already for a long
time on the former and as you admited no one has any product based on the
latter.

Doesn't this makes it a bit of an odd argument ? Also please do notice
that  draft-ietf-bess-service-chaining-04 vastly reuses 20 years of
experience of L3VPNs service so your claim may be IMHO a little weak :)

Cheers,
R.



>  Yours Irrespectively,
>
> John
>
>
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Bernier,
> Daniel
> *Sent:* Wednesday, March 14, 2018 10:54 AM
> *To:* John E Drake ; Robert Raszuk 
> *Cc:* mpls ; SPRING WG List ; s...@ietf.org;
> James N Guichard ; adr...@olddog.co.uk;
> Francois Clad (fclad) 
> *Subject:* Re: [spring] [mpls] [sfc] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi John,
>
>
>
> Don't we already have draft-fm-bess-service-chaining-01
> 
> to perform service chains with existing MPLS implementations ?
>
>
>
> Thanks,​
>
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[John E Drake]

Daniel,

It has a multiplicity of issues, primarily wrt scalability and ease of 
configuration.

Yours Irrespectively,

John

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Bernier, Daniel
Sent: Wednesday, March 14, 2018 10:54 AM
To: John E Drake ; Robert Raszuk 
Cc: mpls ; SPRING WG List ; s...@ietf.org; 
James N Guichard ; adr...@olddog.co.uk; Francois 
Clad (fclad) 
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"


Hi John,



Don't we already have 
draft-fm-bess-service-chaining-01
 to perform service chains with existing MPLS implementations ?



Thanks,​



Daniel Bernier


From: spring > on 
behalf of John E Drake >
Sent: Wednesday, March 14, 2018 8:51 AM
To: Robert Raszuk
Cc: mpls; SPRING WG List; s...@ietf.org; James N 
Guichard; adr...@olddog.co.uk; Francois Clad (fclad)
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Robert,

The point is to re-purpose existing MPLS hardware in the short-term to build 
service function forwarders.

Yours Irrespectively,

John

From: rras...@gmail.com [mailto:rras...@gmail.com] On 
Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:52 PM
To: John E Drake >
Cc: James N Guichard 
>; Francois 
Clad (fclad) >; 
adr...@olddog.co.uk; mpls 
>; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

However, early adopters were concerned about the availability of hardware NSH 
implementations and asked us to include the option of using an MPLS label stack 
to carry the [SPI, SI], which we did.

Are you saying that there is more service function hardware out there in the 
market which support MPLS [SPI,SI] encoding then those supporting NSH ? If so 
and if you or someone will list and compare both I am game to progress this 
work - no issue. If not I really do not see much point.

So far I have seen zero of the former and quite a bit of the latter hence my 
post.

Yours,
Robert.



On Tue, Mar 13, 2018 at 10:44 PM, John E Drake 
> wrote:
Robert,

Comments inline.

Yours Irrespectively,

John

From: rras...@gmail.com 
[mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:13 PM
To: John E Drake >
Cc: James N Guichard 
>; Francois 
Clad (fclad) >; 
adr...@olddog.co.uk; mpls 
>; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

There is one point which I am missing in this discussion ... why we are over 
and over duplicating ways to solve the same problem. Is there some sort of 
starvation of the problems to be solved ? Or is there an issue of "technology 
not invented here must be bad" ?

[JD]  ‘BGP Control Plane for NSH SFC ‘ ( 
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02),
 the control plane companion to the subject draft is, as its title indicates, 
designed to work using the NSH.  However, early adopters were concerned about 
the availability of hardware NSH implementations and asked us to include the 
option of using an MPLS label stack to carry the [SPI, SI], which we did.

You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when "to 
handle 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[John E Drake]

Hi,

I think there is a fundamental difference between the subject draft and 
draft-xuclad-spring-sr-service-chaining-01.  Despite your co-author Wim’s 
assertions to the contrary [1], the latter draft is describing how to use 
segment routing rather than NSH for service function path traversal.

The subject draft still uses NSH for service function traversal but augments it 
with the capability to allow a Classifier to target, on an exception basis, one 
or more specific SFFs along a service function path.  This is described in:  
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02#section-7.6,
  
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02#section-7.7,
 https://tools.ietf.org/html/draft-farrel-mpls-sfc-04#section-7.

This is a capability that I think could usefully be added to the NSH.

Yours Irrespectively,

John

[1]  “I would advocate the need to define a way in MPLS and SR/SPRING to 
transport NSH, but we don’t have to reencode NSH in another encapsulation. Just 
use it as is.”

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of ???(??)
Sent: Tuesday, March 13, 2018 9:35 PM
To: spring ; Francois Clad (fclad) ; 
adr...@olddog.co.uk
Cc: mpls ; SPRING WG List ; s...@ietf.org
Subject: Re: [mpls] [spring] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"


Jim,

--
James N Guichard 
>
2018年3月14日(星期三) 03:00
Francois Clad (fclad) >; 
adr...@olddog.co.uk 
>
mpls >; SPRING WG List 
>; s...@ietf.org 
>
Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state 
"Call For Adoption By WG Issued"

Hi Francois,

One comment below ..

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: adr...@olddog.co.uk
Cc: mpls >; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi Adrian,

On 9 Mar 2018, at 10:17, Adrian Farrel 
> wrote:

I, too, hope we can move to a technical discussion of the differences between 
the proposals

The issue is that, from a technical point of view, there is no difference 
between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the 
solution that was originally documented in draft-xu-mpls-service-chaining, as 
Xiaohu pointed out several times.


Jim> as far as I can tell this is not exactly true.. 
draft-xu-mpls-service-chaining-00 talks about using an MPLS label to identify a 
service segment. Draft-farrel-mpls-sfc talks about using 2 labels, an SFC 
context label and an SF label, to essentially mimic NSH behavior. The authors 
of that draft even go as far as to say (about the context label) “.. using the 
semantics of the SPI is exactly as defined in [RFC8300]”  which is exactly what 
you state you don’t want to do in draft-xuclad-spring-sr-service-chaining. 
Therefore I am not sure how you can come to the conclusion that there is no 
difference between the two solutions.



  draft-xu* talks about using 2 labels as well, see Section 3.1 of  
https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03#page-7. The only 
difference that I can find is draft-farrel* interpretes  "node segment label" 
as "context label".



BTW, this reminds me of almost the same thing just happened between 
https://tools.ietf.org/html/draft-xu-mpls-unified-source-routing-instruction-04 
and https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-03#page-5 where 
the latter interpretes "label stack" as "instruction stack".



Xiaohu



Jim

Considering that draft-xu-mpls-service-chaining was submitted almost one year 
before draft-farrel-mpls-sfc, the MPLS Segment Routing approach described in 
section 6 of draft-farrel-mpls-sfc belongs in draft-xu-mpls-service-chaining, 
which is now draft-xuclad-spring-sr-service-chaining.

To be fair to draft-xu-mpls-service-chaining, I believe that 
draft-farrel-mpls-sfc should be re-spinned without section 6 before continuing 
towards WG adoption.

Thanks,
Francois


and not spend time thrashing around in IETF politics. I'm sure the ADs will 
help us understand what is written in the various WG charters, so our best next 
step would be to read (you know, like all the words :-) what is in the drafts.

However, since Zafar ascribes to me something that I did 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Bernier, Daniel]

Hi John,


Don't we already have 
draft-fm-bess-service-chaining-01
 to perform service chains with existing MPLS implementations ?


Thanks,​


Daniel Bernier


From: spring  on behalf of John E Drake 

Sent: Wednesday, March 14, 2018 8:51 AM
To: Robert Raszuk
Cc: mpls; SPRING WG List; s...@ietf.org; James N Guichard; adr...@olddog.co.uk; 
Francois Clad (fclad)
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Robert,

The point is to re-purpose existing MPLS hardware in the short-term to build 
service function forwarders.

Yours Irrespectively,

John

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:52 PM
To: John E Drake 
Cc: James N Guichard ; Francois Clad (fclad) 
; adr...@olddog.co.uk; mpls ; SPRING WG List 
; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

However, early adopters were concerned about the availability of hardware NSH 
implementations and asked us to include the option of using an MPLS label stack 
to carry the [SPI, SI], which we did.

Are you saying that there is more service function hardware out there in the 
market which support MPLS [SPI,SI] encoding then those supporting NSH ? If so 
and if you or someone will list and compare both I am game to progress this 
work - no issue. If not I really do not see much point.

So far I have seen zero of the former and quite a bit of the latter hence my 
post.

Yours,
Robert.



On Tue, Mar 13, 2018 at 10:44 PM, John E Drake 
> wrote:
Robert,

Comments inline.

Yours Irrespectively,

John

From: rras...@gmail.com 
[mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:13 PM
To: John E Drake >
Cc: James N Guichard 
>; Francois 
Clad (fclad) >; 
adr...@olddog.co.uk; mpls 
>; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

There is one point which I am missing in this discussion ... why we are over 
and over duplicating ways to solve the same problem. Is there some sort of 
starvation of the problems to be solved ? Or is there an issue of "technology 
not invented here must be bad" ?

[JD]  ‘BGP Control Plane for NSH SFC ‘ ( 
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02),
 the control plane companion to the subject draft is, as its title indicates, 
designed to work using the NSH.  However, early adopters were concerned about 
the availability of hardware NSH implementations and asked us to include the 
option of using an MPLS label stack to carry the [SPI, SI], which we did.

You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when "to 
handle situations in which the NSH is not ubiquitously deployed." What are 
those situations considering that MPLS requires IP both control plane and 
forwarding to be in place so does NSH.

[JD]  See above

Would now all of the v-service vendors need to support both ways of encoding 
service/function IDs ?

[JD]  I would expect a graceful transition, i.e., one SFF at a time, from MPLS 
label stack to NSH, and the control plane draft explicitly includes the 
infrastructure necessary to allow both to be included, on a hop by hop basis, 
in the same service function path (the instantiation of a service function 
chain.)

Isn't this waist of everyone's time and effort ?

[JD]  See above

Last - how does  draft-farrel-mpls-sfc works in only IPv6 IP networks ? Oh 
maybe there is and not going to be such thing ?

[JD]  Like a charm.  The underlay would be IPv6, perhaps w/ SR, and the overlay 
would be NSH.  We use the Encapsulation attribute to completely decouple the 
overlay and underlay networks.

 Best,
Robert.


On Tue, Mar 13, 2018 at 9:59 PM, John E Drake 
> wrote:
Jim,

Excellent point.  We thought a context label was crucial in order 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[John E Drake]

Wim,

Comment inline

Yours Irrespectively,

John

From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:wim.henderi...@nokia.com]
Sent: Wednesday, March 14, 2018 4:38 AM
To: Robert Raszuk ; John E Drake 
Cc: mpls ; SPRING WG List ; s...@ietf.org; 
James N Guichard ; adr...@olddog.co.uk; Francois 
Clad (fclad) 
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

I have the same observation as Robert here. The IETF has focussed on using NSH 
as a mechanism for service chaining in SFC WG. We finally see some 
implementations coming alive. With this proposal we will start from scratch as 
all SFF and SF implementations will have to be modified. NSH was and still is a 
hard journey to lineup all implementations.
draft-farrel-mpls-sfc is an alternative way to encode the same information of 
NSH in an MPLS friendly manner. Why do we need this and what’s wrong with NSH 
is the question we should ask first before considering to adopt this work.

I would advocate the need to define a way in MPLS and SR/SPRING to transport 
NSH, but we don’t have to reencode NSH in another encapsulation. Just use it as 
is.


[JD]  Please see:   ‘BGP Control Plane for NSH SFC ‘ ( 
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02),



From: spring > on 
behalf of Robert Raszuk >
Date: Tuesday, 13 March 2018 at 22:51
To: John E Drake >
Cc: mpls >, SPRING WG List 
>, 
"s...@ietf.org" >, 
James N Guichard 
>, 
"adr...@olddog.co.uk" 
>, "Francois Clad (fclad)" 
>
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

However, early adopters were concerned about the availability of hardware NSH 
implementations and asked us to include the option of using an MPLS label stack 
to carry the [SPI, SI], which we did.

Are you saying that there is more service function hardware out there in the 
market which support MPLS [SPI,SI] encoding then those supporting NSH ? If so 
and if you or someone will list and compare both I am game to progress this 
work - no issue. If not I really do not see much point.

So far I have seen zero of the former and quite a bit of the latter hence my 
post.

Yours,
Robert.



On Tue, Mar 13, 2018 at 10:44 PM, John E Drake 
> wrote:
Robert,

Comments inline.

Yours Irrespectively,

John

From: rras...@gmail.com 
[mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:13 PM
To: John E Drake >
Cc: James N Guichard 
>; Francois 
Clad (fclad) >; 
adr...@olddog.co.uk; mpls 
>; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

There is one point which I am missing in this discussion ... why we are over 
and over duplicating ways to solve the same problem. Is there some sort of 
starvation of the problems to be solved ? Or is there an issue of "technology 
not invented here must be bad" ?

[JD]  ‘BGP Control Plane for NSH SFC ‘ ( 
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02),
 the control plane companion to the subject draft is, as its title indicates, 
designed to work using the NSH.  However, early adopters were concerned about 
the availability of hardware NSH implementations and asked us to include the 
option of using an MPLS label stack to carry the [SPI, SI], which we did.

You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when "to 
handle situations in which the NSH is not ubiquitously deployed." What are 
those situations considering that MPLS requires IP both control plane and 
forwarding to be in place so does NSH.

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[John E Drake]

Robert,

The point is to re-purpose existing MPLS hardware in the short-term to build 
service function forwarders.

Yours Irrespectively,

John

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:52 PM
To: John E Drake 
Cc: James N Guichard ; Francois Clad (fclad) 
; adr...@olddog.co.uk; mpls ; SPRING WG List 
; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

However, early adopters were concerned about the availability of hardware NSH 
implementations and asked us to include the option of using an MPLS label stack 
to carry the [SPI, SI], which we did.

Are you saying that there is more service function hardware out there in the 
market which support MPLS [SPI,SI] encoding then those supporting NSH ? If so 
and if you or someone will list and compare both I am game to progress this 
work - no issue. If not I really do not see much point.

So far I have seen zero of the former and quite a bit of the latter hence my 
post.

Yours,
Robert.



On Tue, Mar 13, 2018 at 10:44 PM, John E Drake 
> wrote:
Robert,

Comments inline.

Yours Irrespectively,

John

From: rras...@gmail.com 
[mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:13 PM
To: John E Drake >
Cc: James N Guichard 
>; Francois 
Clad (fclad) >; 
adr...@olddog.co.uk; mpls 
>; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

There is one point which I am missing in this discussion ... why we are over 
and over duplicating ways to solve the same problem. Is there some sort of 
starvation of the problems to be solved ? Or is there an issue of "technology 
not invented here must be bad" ?

[JD]  ‘BGP Control Plane for NSH SFC ‘ ( 
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02),
 the control plane companion to the subject draft is, as its title indicates, 
designed to work using the NSH.  However, early adopters were concerned about 
the availability of hardware NSH implementations and asked us to include the 
option of using an MPLS label stack to carry the [SPI, SI], which we did.

You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when "to 
handle situations in which the NSH is not ubiquitously deployed." What are 
those situations considering that MPLS requires IP both control plane and 
forwarding to be in place so does NSH.

[JD]  See above

Would now all of the v-service vendors need to support both ways of encoding 
service/function IDs ?

[JD]  I would expect a graceful transition, i.e., one SFF at a time, from MPLS 
label stack to NSH, and the control plane draft explicitly includes the 
infrastructure necessary to allow both to be included, on a hop by hop basis, 
in the same service function path (the instantiation of a service function 
chain.)

Isn't this waist of everyone's time and effort ?

[JD]  See above

Last - how does  draft-farrel-mpls-sfc works in only IPv6 IP networks ? Oh 
maybe there is and not going to be such thing ?

[JD]  Like a charm.  The underlay would be IPv6, perhaps w/ SR, and the overlay 
would be NSH.  We use the Encapsulation attribute to completely decouple the 
overlay and underlay networks.

 Best,
Robert.


On Tue, Mar 13, 2018 at 9:59 PM, John E Drake 
> wrote:
Jim,

Excellent point.  We thought a context label was crucial in order to achieve 
scalability (2**40) bits.  A single 20 bit globally unique SFI identifier 
didn’t seem to be practical to us.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On 
Behalf Of James N Guichard
Sent: Tuesday, March 13, 2018 3:00 PM
To: Francois Clad (fclad) >; 
adr...@olddog.co.uk

Cc: mpls >; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Henderickx, Wim (Nokia - BE/Antwerp)]

I have the same observation as Robert here. The IETF has focussed on using NSH 
as a mechanism for service chaining in SFC WG. We finally see some 
implementations coming alive. With this proposal we will start from scratch as 
all SFF and SF implementations will have to be modified. NSH was and still is a 
hard journey to lineup all implementations.
draft-farrel-mpls-sfc is an alternative way to encode the same information of 
NSH in an MPLS friendly manner. Why do we need this and what’s wrong with NSH 
is the question we should ask first before considering to adopt this work.

I would advocate the need to define a way in MPLS and SR/SPRING to transport 
NSH, but we don’t have to reencode NSH in another encapsulation. Just use it as 
is.


From: spring  on behalf of Robert Raszuk 

Date: Tuesday, 13 March 2018 at 22:51
To: John E Drake 
Cc: mpls , SPRING WG List , "s...@ietf.org" 
, James N Guichard , 
"adr...@olddog.co.uk" , "Francois Clad (fclad)" 

Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

However, early adopters were concerned about the availability of hardware NSH 
implementations and asked us to include the option of using an MPLS label stack 
to carry the [SPI, SI], which we did.

Are you saying that there is more service function hardware out there in the 
market which support MPLS [SPI,SI] encoding then those supporting NSH ? If so 
and if you or someone will list and compare both I am game to progress this 
work - no issue. If not I really do not see much point.

So far I have seen zero of the former and quite a bit of the latter hence my 
post.

Yours,
Robert.



On Tue, Mar 13, 2018 at 10:44 PM, John E Drake 
> wrote:
Robert,

Comments inline.

Yours Irrespectively,

John

From: rras...@gmail.com 
[mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:13 PM
To: John E Drake >
Cc: James N Guichard 
>; Francois 
Clad (fclad) >; 
adr...@olddog.co.uk; mpls 
>; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

There is one point which I am missing in this discussion ... why we are over 
and over duplicating ways to solve the same problem. Is there some sort of 
starvation of the problems to be solved ? Or is there an issue of "technology 
not invented here must be bad" ?

[JD]  ‘BGP Control Plane for NSH SFC ‘ ( 
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02), the 
control plane companion to the subject draft is, as its title indicates, 
designed to work using the NSH.  However, early adopters were concerned about 
the availability of hardware NSH implementations and asked us to include the 
option of using an MPLS label stack to carry the [SPI, SI], which we did.

You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when "to 
handle situations in which the NSH is not ubiquitously deployed." What are 
those situations considering that MPLS requires IP both control plane and 
forwarding to be in place so does NSH.

[JD]  See above

Would now all of the v-service vendors need to support both ways of encoding 
service/function IDs ?

[JD]  I would expect a graceful transition, i.e., one SFF at a time, from MPLS 
label stack to NSH, and the control plane draft explicitly includes the 
infrastructure necessary to allow both to be included, on a hop by hop basis, 
in the same service function path (the instantiation of a service function 
chain.)

Isn't this waist of everyone's time and effort ?

[JD]  See above

Last - how does  draft-farrel-mpls-sfc works in only IPv6 IP networks ? Oh 
maybe there is and not going to be such thing ?

[JD]  Like a charm.  The underlay would be IPv6, perhaps w/ SR, and the overlay 
would be NSH.  We use the Encapsulation attribute to completely decouple the 
overlay and underlay networks.

 Best,
Robert.


On Tue, Mar 13, 2018 at 9:59 PM, John E Drake 
> wrote:
Jim,

Excellent point.  We thought a context label was crucial in order to achieve 
scalability (2**40) bits.  A single 20 bit globally unique SFI identifier 
didn’t seem to be practical to us.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On 
Behalf Of James N Guichard
Sent: Tuesday, March 13, 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[徐小虎(义先)]

Jim,
--James N 
Guichard 2018年3月14日(星期三) 03:00Francois Clad 
(fclad) ; adr...@olddog.co.uk mpls 
; SPRING WG List ; s...@ietf.org 
Re: [spring] [mpls] [sfc] The MPLS WG has placed 
draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
Hi Francois, One comment below .. From: mpls [mailto:mpls-boun...@ietf.org]
On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: adr...@olddog.co.uk
Cc: mpls ; SPRING WG List ; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued" Hi Adrian,

On 9 Mar 2018, at 10:17, Adrian Farrel  wrote: I, too, 
hope we can move to a technical discussion of the differences between the 
proposals
 The issue is that, from a technical point of view, there is no difference 
between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the 
solution that was originally documented in draft-xu-mpls-service-chaining, as 
Xiaohu
 pointed out several times. Jim> as far as I can tell this is not exactly 
true.. draft-xu-mpls-service-chaining-00 talks about using an MPLS label to 
identify a service segment. Draft-farrel-mpls-sfc talks about using 2 labels, 
an SFC context label and an SF label, to essentially mimic NSH behavior. The 
authors of that draft even go as far as to say (about the context label) “.. 
using the semantics of the SPI is exactly as defined in [RFC8300]”  which is 
exactly what you state you don’t want to do in 
draft-xuclad-spring-sr-service-chaining. Therefore I am not sure how you can 
come to the conclusion that there is no difference between the two solutions.
  draft-xu* talks about using 2 labels as well, see Section 3.1 of  
https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03#page-7. The only 
difference that I can find is draft-farrel* interpretes  "node segment label" 
as "context label". 
BTW, this reminds me of almost the same thing just happened between 
https://tools.ietf.org/html/draft-xu-mpls-unified-source-routing-instruction-04 
and https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-03#page-5 where 
the latter interpretes "label stack" as "instruction stack". 
Xiaohu
Jim


Considering that draft-xu-mpls-service-chaining was submitted almost one year 
before draft-farrel-mpls-sfc, the MPLS Segment Routing approach described in 
section 6 of draft-farrel-mpls-sfc belongs in draft-xu-mpls-service-chaining, 
which is now draft-xuclad-spring-sr-service-chaining.


To be fair to draft-xu-mpls-service-chaining, I believe that 
draft-farrel-mpls-sfc should be re-spinned without section 6 before continuing 
towards WG adoption.


Thanks,

Francois 

and not spend time thrashing around in IETF politics. I'm sure the ADs will 
help us understand what is written in the various WG charters, so our best next 
step
 would be to read (you know, like all the words :-) what is in the drafts. 
However, since Zafar ascribes to me something that I did not say and that is 
not recorded in the minutes, perhaps I can set that straight. He said... > From 
IETF process viewpoint, this call for adaption is like putting the "cart ahead 
of the horse."> MPLS WG comes last in the process after there is an agreement 
from Spring and SFC groups> on the need for MPLS data plane changes proposed by 
the draft. I raised this point at the mic> at SFC WG meeting at IETF100 and 
Adrian agreed to it. I.e., MPLS WG comes at the last stage> in the process; 
expert to review this work does not sit in the MPLS WG. According to the 
minutes, Zafar said... | Zafar Ali: before defining the solution, is this the 
right approach in SFC? Starting| in MPLS WG is wrong thing to do. And I 
responded... | Adrian: This was already presented in SFC WG today. In the SFC 
WG I said... | - The draft discusses how MPLS can be used for SFC. It is being 
discussed in the|MPLS working group.| - We are looking at environments in 
which deployed MPLS routers can be used|for creating an SFC, rather than 
using NSH. If you want my opinion:- The SFC WG is chartered to work on NSH 
only- The MPLS WG is chartered to work on MPLS- This draft asks for MPLS code 
points so can only be in MPLS- This draft must be reviewed in SFC and SPRING as 
it progresses and   certainly at WG last call Adrian From: mpls
 [mailto:mpls-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 09 March 2018 00:02
To: Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; s...@ietf.org; draft-farrel-mpls-sfc; mpls-chairs; 
mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in 
state "Call For Adoption By WG Issued"
Importance: High Dear MPLS WG Chairs and the authors of draft-farrel-mpls-sfc,  
I would like to draw your attention to the 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Robert Raszuk]

Hi John,

*However, early adopters were concerned about the availability of hardware
NSH implementations and asked us to include the option of using an MPLS
label stack to carry the [SPI, SI], which we did.*

Are you saying that there is more service function hardware out there in
the market which support MPLS [SPI,SI] encoding then those supporting NSH ?
If so and if you or someone will list and compare both I am game to
progress this work - no issue. If not I really do not see much point.

So far I have seen zero of the former and quite a bit of the latter hence
my post.

Yours,
Robert.



On Tue, Mar 13, 2018 at 10:44 PM, John E Drake  wrote:

> Robert,
>
>
>
> Comments inline.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, March 13, 2018 5:13 PM
> *To:* John E Drake 
> *Cc:* James N Guichard ; Francois Clad
> (fclad) ; adr...@olddog.co.uk; mpls ;
> SPRING WG List ; s...@ietf.org
> *Subject:* Re: [mpls] [sfc] [spring] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi John,
>
>
>
> There is one point which I am missing in this discussion ... why we are
> over and over duplicating ways to solve the same problem. Is there some
> sort of starvation of the problems to be solved ? Or is there an issue of
> "technology not invented here must be bad" ?
>
>
>
> *[JD]  ‘BGP Control Plane for NSH SFC ‘ (
> https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02
> ),
> the control plane companion to the subject draft is, as its title
> indicates, designed to work using the NSH.  However, early adopters were
> concerned about the availability of hardware NSH implementations and asked
> us to include the option of using an MPLS label stack to carry the [SPI,
> SI], which we did.*
>
>
>
> You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when
> "to handle situations in which the NSH is not ubiquitously deployed." What
> are those situations considering that MPLS requires IP both control plane
> and forwarding to be in place so does NSH.
>
>
>
> *[JD]  See above*
>
>
>
> Would now all of the v-service vendors need to support both ways of
> encoding service/function IDs ?
>
>
>
> *[JD]  I would expect a graceful transition, i.e., one SFF at a time, from
> MPLS label stack to NSH, and the control plane draft explicitly includes
> the infrastructure necessary to allow both to be included, on a hop by hop
> basis, in the same service function path (the instantiation of a service
> function chain.)*
>
>
>
> Isn't this waist of everyone's time and effort ?
>
>
>
> *[JD]  See above*
>
>
>
> Last - how does  draft-farrel-mpls-sfc works in only IPv6 IP networks ?
> Oh maybe there is and not going to be such thing ?
>
>
>
> *[JD]  Like a charm.  The underlay would be IPv6, perhaps w/ SR, and the
> overlay would be NSH.  We use the Encapsulation attribute to completely
> decouple the overlay and underlay networks. *
>
>
>
>  Best,
> Robert.
>
>
>
>
>
> On Tue, Mar 13, 2018 at 9:59 PM, John E Drake  wrote:
>
> Jim,
>
>
>
> Excellent point.  We thought a context label was crucial in order to
> achieve scalability (2**40) bits.  A single 20 bit globally unique SFI
> identifier didn’t seem to be practical to us.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *James N
> Guichard
> *Sent:* Tuesday, March 13, 2018 3:00 PM
> *To:* Francois Clad (fclad) ; adr...@olddog.co.uk
>
>
> *Cc:* mpls ; SPRING WG List ; s...@ietf.org
> *Subject:* Re: [mpls] [sfc] [spring] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi Francois,
>
>
>
> One comment below ..
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org ] *On
> Behalf Of *Francois Clad (fclad)
> *Sent:* Tuesday, March 13, 2018 2:27 PM
> *To:* adr...@olddog.co.uk
> *Cc:* mpls ; SPRING WG List ; s...@ietf.org
> *Subject:* Re: [mpls] [sfc] [spring] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi Adrian,
>
>
>
> On 9 Mar 2018, at 10:17, Adrian Farrel  wrote:
>
>
>
> I, too, hope we can move to a technical discussion of the differences
> between the proposals
>
>
>
> The issue is that, from a technical point of view, there is no difference
> between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and
> the solution that was originally documented in 
> draft-xu-mpls-service-chaining, as
> Xiaohu pointed out several times.
>
>
>
> Jim> as far as I can tell this is not exactly true.. 
> 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[John E Drake]

Robert,

Comments inline.

Yours Irrespectively,

John

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:13 PM
To: John E Drake 
Cc: James N Guichard ; Francois Clad (fclad) 
; adr...@olddog.co.uk; mpls ; SPRING WG List 
; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

There is one point which I am missing in this discussion ... why we are over 
and over duplicating ways to solve the same problem. Is there some sort of 
starvation of the problems to be solved ? Or is there an issue of "technology 
not invented here must be bad" ?

[JD]  ‘BGP Control Plane for NSH SFC ‘ ( 
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02), the 
control plane companion to the subject draft is, as its title indicates, 
designed to work using the NSH.  However, early adopters were concerned about 
the availability of hardware NSH implementations and asked us to include the 
option of using an MPLS label stack to carry the [SPI, SI], which we did.

You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when "to 
handle situations in which the NSH is not ubiquitously deployed." What are 
those situations considering that MPLS requires IP both control plane and 
forwarding to be in place so does NSH.

[JD]  See above

Would now all of the v-service vendors need to support both ways of encoding 
service/function IDs ?

[JD]  I would expect a graceful transition, i.e., one SFF at a time, from MPLS 
label stack to NSH, and the control plane draft explicitly includes the 
infrastructure necessary to allow both to be included, on a hop by hop basis, 
in the same service function path (the instantiation of a service function 
chain.)

Isn't this waist of everyone's time and effort ?

[JD]  See above

Last - how does  draft-farrel-mpls-sfc works in only IPv6 IP networks ? Oh 
maybe there is and not going to be such thing ?

[JD]  Like a charm.  The underlay would be IPv6, perhaps w/ SR, and the overlay 
would be NSH.  We use the Encapsulation attribute to completely decouple the 
overlay and underlay networks.

 Best,
Robert.


On Tue, Mar 13, 2018 at 9:59 PM, John E Drake 
> wrote:
Jim,

Excellent point.  We thought a context label was crucial in order to achieve 
scalability (2**40) bits.  A single 20 bit globally unique SFI identifier 
didn’t seem to be practical to us.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On 
Behalf Of James N Guichard
Sent: Tuesday, March 13, 2018 3:00 PM
To: Francois Clad (fclad) >; 
adr...@olddog.co.uk

Cc: mpls >; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi Francois,

One comment below ..

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: adr...@olddog.co.uk
Cc: mpls >; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi Adrian,

On 9 Mar 2018, at 10:17, Adrian Farrel 
> wrote:

I, too, hope we can move to a technical discussion of the differences between 
the proposals

The issue is that, from a technical point of view, there is no difference 
between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the 
solution that was originally documented in draft-xu-mpls-service-chaining, as 
Xiaohu pointed out several times.


Jim> as far as I can tell this is not exactly true.. 
draft-xu-mpls-service-chaining-00 talks about using an MPLS label to identify a 
service segment. Draft-farrel-mpls-sfc talks about using 2 labels, an SFC 
context label and an SF label, to essentially mimic NSH behavior. The authors 
of that draft even go as far as to say (about the context label) “.. using the 
semantics of the SPI is exactly as defined in [RFC8300]”  which is exactly what 
you state you don’t want to do in draft-xuclad-spring-sr-service-chaining. 
Therefore I am not sure how you can come to the conclusion that there is no 
difference between the two solutions.

Jim

Considering that draft-xu-mpls-service-chaining was submitted almost one year 
before draft-farrel-mpls-sfc, the MPLS Segment Routing approach described in 
section 6 of draft-farrel-mpls-sfc belongs in 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Robert Raszuk]

Hi John,

There is one point which I am missing in this discussion ... why we are
over and over duplicating ways to solve the same problem. Is there some
sort of starvation of the problems to be solved ? Or is there an issue of
"technology not invented here must be bad" ?

You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when
"to handle situations in which the NSH is not ubiquitously deployed." What
are those situations considering that MPLS requires IP both control plane
and forwarding to be in place so does NSH.

Would now all of the v-service vendors need to support both ways of
encoding service/function IDs ?

Isn't this waist of everyone's time and effort ?

Last - how does  draft-farrel-mpls-sfc works in only IPv6 IP networks ? Oh
maybe there is and not going to be such thing ?

Best,
Robert.


On Tue, Mar 13, 2018 at 9:59 PM, John E Drake  wrote:

> Jim,
>
>
>
> Excellent point.  We thought a context label was crucial in order to
> achieve scalability (2**40) bits.  A single 20 bit globally unique SFI
> identifier didn’t seem to be practical to us.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *James N
> Guichard
> *Sent:* Tuesday, March 13, 2018 3:00 PM
> *To:* Francois Clad (fclad) ; adr...@olddog.co.uk
>
> *Cc:* mpls ; SPRING WG List ; s...@ietf.org
> *Subject:* Re: [mpls] [sfc] [spring] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi Francois,
>
>
>
> One comment below ..
>
>
>
> *From:* mpls [mailto:mpls-boun...@ietf.org ] *On
> Behalf Of *Francois Clad (fclad)
> *Sent:* Tuesday, March 13, 2018 2:27 PM
> *To:* adr...@olddog.co.uk
> *Cc:* mpls ; SPRING WG List ; s...@ietf.org
> *Subject:* Re: [mpls] [sfc] [spring] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi Adrian,
>
>
>
> On 9 Mar 2018, at 10:17, Adrian Farrel  wrote:
>
>
>
> I, too, hope we can move to a technical discussion of the differences
> between the proposals
>
>
>
> The issue is that, from a technical point of view, there is no difference
> between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and
> the solution that was originally documented in 
> draft-xu-mpls-service-chaining, as
> Xiaohu pointed out several times.
>
>
>
> Jim> as far as I can tell this is not exactly true.. 
> draft-xu-mpls-service-chaining-00 talks about using an MPLS label to identify 
> a service segment. Draft-farrel-mpls-sfc talks about using 2 labels, an SFC 
> context label and an SF label, to essentially mimic NSH behavior. The authors 
> of that draft even go as far as to say (about the context label) “.. using 
> the semantics of the SPI is exactly as defined in [RFC8300]”  which is 
> exactly what you state you don’t want to do in 
> draft-xuclad-spring-sr-service-chaining. Therefore I am not sure how you can 
> come to the conclusion that there is no difference between the two solutions.
>
>
>
> Jim
>
>
> Considering that draft-xu-mpls-service-chaining was submitted almost one
> year before draft-farrel-mpls-sfc, the MPLS Segment Routing approach
> described in section 6 of draft-farrel-mpls-sfc belongs in
> draft-xu-mpls-service-chaining, which is now draft-xuclad-spring-sr-
> service-chaining.
>
> To be fair to draft-xu-mpls-service-chaining, I believe that
> draft-farrel-mpls-sfc should be re-spinned without section 6 before
> continuing towards WG adoption.
>
> Thanks,
> Francois
>
>
>
>
>
> and not spend time thrashing around in IETF politics. I'm sure the ADs
> will help us understand what is written in the various WG charters, so our
> best next step would be to read (you know, like all the words :-) what is
> in the drafts.
>
>
>
> However, since Zafar ascribes to me something that I did not say and that
> is not recorded in the minutes, perhaps I can set that straight.
>
>
>
> He said...
>
>
>
> > From IETF process viewpoint, this call for adaption is like putting the
> "cart ahead of the horse."
>
> > MPLS WG comes last in the process after there is an agreement from
> Spring and SFC groups
>
> > on the need for MPLS data plane changes proposed by the draft. I raised
> this point at the mic
>
> > at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG
> comes at the last stage
>
> > in the process; expert to review this work does not sit in the MPLS WG.
>
>
>
> According to the minutes, Zafar said...
>
>
>
> | Zafar Ali: before defining the solution, is this the right approach in
> SFC? Starting
>
> | in MPLS WG is wrong thing to do.
>
>
>
> And I responded...
>
>
>
> | Adrian: This was already presented in SFC WG today.
>
>
>
> In the SFC WG I said...
>
>
>
> | - The draft discusses how MPLS can be used for SFC. It is being
> discussed in the
>
> |MPLS working group.
>
> | - We 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[John E Drake]

Jim,

Excellent point.  We thought a context label was crucial in order to achieve 
scalability (2**40) bits.  A single 20 bit globally unique SFI identifier 
didn’t seem to be practical to us.

Yours Irrespectively,

John

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of James N Guichard
Sent: Tuesday, March 13, 2018 3:00 PM
To: Francois Clad (fclad) ; adr...@olddog.co.uk
Cc: mpls ; SPRING WG List ; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi Francois,

One comment below ..

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: adr...@olddog.co.uk
Cc: mpls >; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi Adrian,

On 9 Mar 2018, at 10:17, Adrian Farrel 
> wrote:

I, too, hope we can move to a technical discussion of the differences between 
the proposals

The issue is that, from a technical point of view, there is no difference 
between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the 
solution that was originally documented in draft-xu-mpls-service-chaining, as 
Xiaohu pointed out several times.


Jim> as far as I can tell this is not exactly true.. 
draft-xu-mpls-service-chaining-00 talks about using an MPLS label to identify a 
service segment. Draft-farrel-mpls-sfc talks about using 2 labels, an SFC 
context label and an SF label, to essentially mimic NSH behavior. The authors 
of that draft even go as far as to say (about the context label) “.. using the 
semantics of the SPI is exactly as defined in [RFC8300]”  which is exactly what 
you state you don’t want to do in draft-xuclad-spring-sr-service-chaining. 
Therefore I am not sure how you can come to the conclusion that there is no 
difference between the two solutions.

Jim

Considering that draft-xu-mpls-service-chaining was submitted almost one year 
before draft-farrel-mpls-sfc, the MPLS Segment Routing approach described in 
section 6 of draft-farrel-mpls-sfc belongs in draft-xu-mpls-service-chaining, 
which is now draft-xuclad-spring-sr-service-chaining.

To be fair to draft-xu-mpls-service-chaining, I believe that 
draft-farrel-mpls-sfc should be re-spinned without section 6 before continuing 
towards WG adoption.

Thanks,
Francois


and not spend time thrashing around in IETF politics. I'm sure the ADs will 
help us understand what is written in the various WG charters, so our best next 
step would be to read (you know, like all the words :-) what is in the drafts.

However, since Zafar ascribes to me something that I did not say and that is 
not recorded in the minutes, perhaps I can set that straight.

He said...

> From IETF process viewpoint, this call for adaption is like putting the "cart 
> ahead of the horse."
> MPLS WG comes last in the process after there is an agreement from Spring and 
> SFC groups
> on the need for MPLS data plane changes proposed by the draft. I raised this 
> point at the mic
> at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at 
> the last stage
> in the process; expert to review this work does not sit in the MPLS WG.

According to the minutes, Zafar said...

| Zafar Ali: before defining the solution, is this the right approach in SFC? 
Starting
| in MPLS WG is wrong thing to do.

And I responded...

| Adrian: This was already presented in SFC WG today.

In the SFC WG I said...

| - The draft discusses how MPLS can be used for SFC. It is being discussed in 
the
|MPLS working group.
| - We are looking at environments in which deployed MPLS routers can be used
|for creating an SFC, rather than using NSH.

If you want my opinion:
- The SFC WG is chartered to work on NSH only
- The MPLS WG is chartered to work on MPLS
- This draft asks for MPLS code points so can only be in MPLS
- This draft must be reviewed in SFC and SPRING as it progresses and
   certainly at WG last call

Adrian

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 09 March 2018 00:02
To: Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; s...@ietf.org; 
draft-farrel-mpls-sfc; mpls-chairs; mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in 
state "Call For Adoption By WG Issued"
Importance: High

Dear MPLS WG Chairs and the authors of draft-farrel-mpls-sfc,

I would like to draw your attention to the serious issue raised by Xiaohu and 
Francois.

Summary:

Please note that this working group adaption against the IETF process and its 
spirit. Please recall the adaption call.

Details:

Just to reiterate the 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[James N Guichard]

Hi Francois,

One comment below ..

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: adr...@olddog.co.uk
Cc: mpls ; SPRING WG List ; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi Adrian,


On 9 Mar 2018, at 10:17, Adrian Farrel 
> wrote:

I, too, hope we can move to a technical discussion of the differences between 
the proposals

The issue is that, from a technical point of view, there is no difference 
between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the 
solution that was originally documented in draft-xu-mpls-service-chaining, as 
Xiaohu pointed out several times.


Jim> as far as I can tell this is not exactly true.. 
draft-xu-mpls-service-chaining-00 talks about using an MPLS label to identify a 
service segment. Draft-farrel-mpls-sfc talks about using 2 labels, an SFC 
context label and an SF label, to essentially mimic NSH behavior. The authors 
of that draft even go as far as to say (about the context label) “.. using the 
semantics of the SPI is exactly as defined in [RFC8300]”  which is exactly what 
you state you don’t want to do in draft-xuclad-spring-sr-service-chaining. 
Therefore I am not sure how you can come to the conclusion that there is no 
difference between the two solutions.

Jim

Considering that draft-xu-mpls-service-chaining was submitted almost one year 
before draft-farrel-mpls-sfc, the MPLS Segment Routing approach described in 
section 6 of draft-farrel-mpls-sfc belongs in draft-xu-mpls-service-chaining, 
which is now draft-xuclad-spring-sr-service-chaining.

To be fair to draft-xu-mpls-service-chaining, I believe that 
draft-farrel-mpls-sfc should be re-spinned without section 6 before continuing 
towards WG adoption.

Thanks,
Francois



and not spend time thrashing around in IETF politics. I'm sure the ADs will 
help us understand what is written in the various WG charters, so our best next 
step would be to read (you know, like all the words :-) what is in the drafts.

However, since Zafar ascribes to me something that I did not say and that is 
not recorded in the minutes, perhaps I can set that straight.

He said...

> From IETF process viewpoint, this call for adaption is like putting the "cart 
> ahead of the horse."
> MPLS WG comes last in the process after there is an agreement from Spring and 
> SFC groups
> on the need for MPLS data plane changes proposed by the draft. I raised this 
> point at the mic
> at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at 
> the last stage
> in the process; expert to review this work does not sit in the MPLS WG.

According to the minutes, Zafar said...

| Zafar Ali: before defining the solution, is this the right approach in SFC? 
Starting
| in MPLS WG is wrong thing to do.

And I responded...

| Adrian: This was already presented in SFC WG today.

In the SFC WG I said...

| - The draft discusses how MPLS can be used for SFC. It is being discussed in 
the
|MPLS working group.
| - We are looking at environments in which deployed MPLS routers can be used
|for creating an SFC, rather than using NSH.

If you want my opinion:
- The SFC WG is chartered to work on NSH only
- The MPLS WG is chartered to work on MPLS
- This draft asks for MPLS code points so can only be in MPLS
- This draft must be reviewed in SFC and SPRING as it progresses and
   certainly at WG last call

Adrian

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 09 March 2018 00:02
To: Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; s...@ietf.org; 
draft-farrel-mpls-sfc; mpls-chairs; mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in 
state "Call For Adoption By WG Issued"
Importance: High

Dear MPLS WG Chairs and the authors of draft-farrel-mpls-sfc,

I would like to draw your attention to the serious issue raised by Xiaohu and 
Francois.

Summary:

Please note that this working group adaption against the IETF process and its 
spirit. Please recall the adaption call.

Details:

Just to reiterate the issue raised by Xiaohu and Francois. At last IETF we 
discussed 3 drafts (draft-xu-mpls-service-chaining-03, draft-farrel-mpls-sfc 
and draft-clad-spring-segment-routing-service-chaining) in SFC, Spring and MPLS 
WG. There was the specific conversation on which WG the work belongs, and the 
assumed follow-up was for the chairs and ADs to have the discussion on home for 
these drafts.

From IETF process viewpoint, this call for adaption is like putting the "cart 
ahead of the horse." MPLS WG comes last in the process after there is an 
agreement from Spring and SFC groups on the need for MPLS data plane changes 
proposed by the draft. I raised this point at the mic at SFC WG meeting at