Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

[Mach Chen]

Hi Sasha,

Thanks for your prompt response!

Section 2.1.1 discusses some potential directions for Path segment ID 
assignment and distribution, there are several ways that can be used. IGP based 
solution is good for the case where more nodes within the domain needs to learn 
the Path Segment ID. For the use cases as mentioned in Section 3, the nodes 
that need to learn the Path Segment ID are mainly the ingress LSR. For a 
centralized model, the centralized controller may also need to learn the Path 
Segment ID. So, for these use case, a point-2-point model (e.g., BGP) or 
request/reply model (e.g., PCEP) seems more suitable.  How do you think?

Best regards,
Mach

> -Original Message-
> From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
> Sent: Tuesday, March 13, 2018 7:30 PM
> To: Mach Chen 
> Cc: spring@ietf.org; Shell Nakash ; Michael
> Gorokhovsky ; Dmitry Valdman
> ; Stewart Bryant ;
> Ron Sdayoor ; Hemmy Yona
> ; draft-cheng-spring-mpls-path-segm...@ietf.org
> Subject: RE: Comments on draft-cheng-spring-mpls-path-segment-01
> 
> Mach,
> Lots of thanks for a prompt and very encouraging response!
> One more question:
> 
> Do you and your colleagues plan to define the mechanism for distribution of
> the Path Segment ID in IGP?
> (Usually such mechanisms are defined in dedicated drafts separately for OSPF
> and ISIS, but, at least, it should be nice to mention the fact in the draft).
> 
> Regards,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mach Chen
> Sent: Tuesday, March 13, 2018 1:22 PM
> To: Alexander Vainshtein ; draft-cheng-
> spring-mpls-path-segm...@ietf.org
> Cc: spring@ietf.org; Shell Nakash ; Michael
> Gorokhovsky ; Dmitry Valdman
> ; Stewart Bryant ;
> Ron Sdayoor ; Hemmy Yona
> 
> Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01
> 
> Hi Sasha,
> 
> Many thanks for your valuable comments!
> 
> Please see my responses inline...
> 
> >
> > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander
> > Vainshtein
> > Sent: Sunday, March 11, 2018 9:44 PM
> > To: draft-cheng-spring-mpls-path-segm...@ietf.org
> > Cc: spring@ietf.org; Shell Nakash ; Michael
> > Gorokhovsky ; Dmitry Valdman
> > ; Stewart Bryant
> > ; Ron Sdayoor ;
> > Hemmy Yona 
> > Subject: [spring] Comments on draft-cheng-spring-mpls-path-segment-01
> >
> > Dear authors of draft-cheng-spring-mpls-path-segment-01, and I have a
> > few comments.
> >
> > 1. From my POV, the draft addresses the problem of identifying an
> > incoming SR LSP at the tail-end node.
> > a. This problem is real because SR LSPs, by their very nature, are
> > MP2P
> > (merging) LSPs.
> > b. The draft does not try to solve the problem of SR LSP
> > identification in transit nodes.
> 
> Yes, that's the intention.
> 
> > 2. The draft proposes two solutions (one-label and two-label) for the
> > above- mentioned problem, and the authors expect the WG to discuss
> > these solutions and to select the preferred one. As I see it:
> > a. Both uses cases discussed in Section 3 of the draft can be
> > addressed with any of these solutions b. IMHO and FWIW, as long as
> > SR-MPLS leaves multicast out of scope (as mentioned in Section 6 of
> > the SR Architecture draft), any future issue with identification of SR
> > LSPs that can be addressed with the two-label solution can also be
> > addressed with the one-label solution c. The two-label solution
> > requires support of upstream-allocated labels and context-specific
> > label spaces, i.e., adds substantial implementation complexity. The
> > one-label solution can be implemented using just per platform label space of
> downstream-allocated labels.
> > d. Based on these considerations, my preference (FWIW) is for
> > one-label solution.
> 
> I also have the same preference as yours.
> 
> > 3. The draft lists both the already mentioned SR Architecture draft
> > and the SR- MPLS draft as Informative references, but the SRV6 Routing
> > Header draft appears as a Normative reference. From my POV, the first
> > two documents MUST be Normative references and the last one - an
> > Informative reference, because the draft only deals with SR-MPLS.
> 
> Agree, will update it in the next revision.
> 
> >
> > Hopefully,  these notes can be useful.
> 
> Very useful, as always!
> 
> 

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 

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

[Francois Clad (fclad)]

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.

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

The drafts also did not stay dormant after IETF100. There were email 
conversations among the authors of the concerned drafts 
(https://mailarchive.ietf.org/arch/msg/mpls/bmH5QH65b2Non2Y7qNEBBI_kSOA).

Authors of draft-xu- and draft-clad- followed the proper IETF process, 
discussed and merged the contents. They published 
draft-xuclad-spring-sr-service-chaining-01 and asked WG for a "presentation 
slot" at IETF100. Only to find that draft-farrel-mpls-sfc used a backdoor to 
force this "WG adaption call"!

One also has to question the timing of this adaption call when the WGs are 
meeting face-to-face in a couple of weeks. Is it no longer IETF spirit to make 
use of the face-to-face to do the right thing, especially when we are meeting 
in two weeks?

In the light of the above, my request to the authors of draft-farrel and MPLS 
WG chairs to please do the right 

Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

[Alexander Vainshtein]

Uma,

Lots of thanks for bringing the draft in 
question to 
my attention.



Regards,

Sasha



Office: +972-39266302

Cell:  +972-549266302

Email:   alexander.vainsht...@ecitele.com





-Original Message-
From: Uma Chunduri [mailto:uma.chund...@huawei.com]
Sent: Tuesday, March 13, 2018 5:52 PM
To: Alexander Vainshtein ; Mach Chen 

Cc: spring@ietf.org; Shell Nakash ; Michael 
Gorokhovsky ; Dmitry Valdman 
; draft-cheng-spring-mpls-path-segm...@ietf.org; 
Stewart Bryant ; Ron Sdayoor 
; Hemmy Yona 
Subject: RE: Comments on draft-cheng-spring-mpls-path-segment-01



We recently published a 00 version, undergoing an update to be published during 
IETF week (presented @ LSR WG).

It addresses label stack reduction for any non-shortest path LSPs including an 
optional path traffic statistics.



https://www.ietf.org/mail-archive/web/dmm/current/msg03162.html



It would help for SRH more when it comes to TE path. Check out DMM WG (3GPP SA2 
study & proposals) discussions off late.



Best,

--

Uma C.





-Original Message-

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein

Sent: Tuesday, March 13, 2018 4:30 AM

To: Mach Chen >

Cc: spring@ietf.org; Shell Nakash 
>; Michael 
Gorokhovsky 
>; 
Dmitry Valdman >; 
draft-cheng-spring-mpls-path-segm...@ietf.org;
 Stewart Bryant >; 
Ron Sdayoor >; Hemmy 
Yona >

Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01



Mach,

Lots of thanks for a prompt and very encouraging response!

One more question:



Do you and your colleagues plan to define the mechanism for distribution of the 
Path Segment ID in IGP?

(Usually such mechanisms are defined in dedicated drafts separately for OSPF 
and ISIS, but, at least, it should be nice to mention the fact in the draft).



Regards,

Sasha



Office: +972-39266302

Cell:  +972-549266302

Email:   
alexander.vainsht...@ecitele.com



-Original Message-

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mach Chen

Sent: Tuesday, March 13, 2018 1:22 PM

To: Alexander Vainshtein 
>; 
draft-cheng-spring-mpls-path-segm...@ietf.org

Cc: spring@ietf.org; Shell Nakash 
>; Michael 
Gorokhovsky 
>; 
Dmitry Valdman >; 
Stewart Bryant >; Ron 
Sdayoor >; Hemmy Yona 
>

Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01



Hi Sasha,



Many thanks for your valuable comments!



Please see my responses inline...



>

> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander

> Vainshtein

> Sent: Sunday, March 11, 2018 9:44 PM

> To: 
> draft-cheng-spring-mpls-path-segm...@ietf.org

> Cc: spring@ietf.org; Shell Nakash 
> >; Michael

> Gorokhovsky 
> >; 
> Dmitry Valdman

> >; Stewart 
> Bryant

> >; Ron Sdayoor 
> >;

> Hemmy Yona >

> Subject: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

>

> Dear authors of draft-cheng-spring-mpls-path-segment-01, and I have a

> few comments.

>

> 1. From my POV, the draft addresses the problem of identifying an

> incoming SR LSP at the tail-end node.

> a. This problem is real because SR LSPs, by their very nature, are

> MP2P

> (merging) LSPs.

> b. The draft does not try to solve the problem of SR LSP

> identification in 

Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

[Uma Chunduri]

Sorry, minor correction:

3GPP SA2 ==> 3GPP CT4

And it helps most of the proposals including SRH, SR-MPLS, LISP, ILA (?) ..

Best,
--
Uma C.

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Uma Chunduri
Sent: Tuesday, March 13, 2018 8:52 AM
To: Alexander Vainshtein ; Mach Chen 

Cc: spring@ietf.org; Shell Nakash ; Michael 
Gorokhovsky ; Dmitry Valdman 
; draft-cheng-spring-mpls-path-segm...@ietf.org; 
Stewart Bryant ; Ron Sdayoor 
; Hemmy Yona 
Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

We recently published a 00 version, undergoing an update to be published during 
IETF week (presented @ LSR WG). 
It addresses label stack reduction for any non-shortest path LSPs including an 
optional path traffic statistics.

https://www.ietf.org/mail-archive/web/dmm/current/msg03162.html 

It would help for SRH more when it comes to TE path. Check out DMM WG (3GPP SA2 
study & proposals) discussions off late.

Best,
--
Uma C.


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, March 13, 2018 4:30 AM
To: Mach Chen 
Cc: spring@ietf.org; Shell Nakash ; Michael 
Gorokhovsky ; Dmitry Valdman 
; draft-cheng-spring-mpls-path-segm...@ietf.org; 
Stewart Bryant ; Ron Sdayoor 
; Hemmy Yona 
Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

Mach,
Lots of thanks for a prompt and very encouraging response!
One more question: 

Do you and your colleagues plan to define the mechanism for distribution of the 
Path Segment ID in IGP?
(Usually such mechanisms are defined in dedicated drafts separately for OSPF 
and ISIS, but, at least, it should be nice to mention the fact in the draft).

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mach Chen
Sent: Tuesday, March 13, 2018 1:22 PM
To: Alexander Vainshtein ; 
draft-cheng-spring-mpls-path-segm...@ietf.org
Cc: spring@ietf.org; Shell Nakash ; Michael 
Gorokhovsky ; Dmitry Valdman 
; Stewart Bryant ; Ron 
Sdayoor ; Hemmy Yona 
Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

Hi Sasha,

Many thanks for your valuable comments!

Please see my responses inline...

> 
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander 
> Vainshtein
> Sent: Sunday, March 11, 2018 9:44 PM
> To: draft-cheng-spring-mpls-path-segm...@ietf.org
> Cc: spring@ietf.org; Shell Nakash ; Michael 
> Gorokhovsky ; Dmitry Valdman 
> ; Stewart Bryant 
> ; Ron Sdayoor ; 
> Hemmy Yona 
> Subject: [spring] Comments on draft-cheng-spring-mpls-path-segment-01
> 
> Dear authors of draft-cheng-spring-mpls-path-segment-01, and I have a 
> few comments.
> 
> 1. From my POV, the draft addresses the problem of identifying an 
> incoming SR LSP at the tail-end node.
> a. This problem is real because SR LSPs, by their very nature, are 
> MP2P
> (merging) LSPs.
> b. The draft does not try to solve the problem of SR LSP 
> identification in transit nodes.

Yes, that's the intention.

> 2. The draft proposes two solutions (one-label and two-label) for the
> above- mentioned problem, and the authors expect the WG to discuss 
> these solutions and to select the preferred one. As I see it:
> a. Both uses cases discussed in Section 3 of the draft can be 
> addressed with any of these solutions b. IMHO and FWIW, as long as 
> SR-MPLS leaves multicast out of scope (as mentioned in Section 6 of 
> the SR Architecture draft), any future issue with identification of SR 
> LSPs that can be addressed with the two-label solution can also be 
> addressed with the one-label solution c. The two-label solution 
> requires support of upstream-allocated labels and context-specific 
> label spaces, i.e., adds substantial implementation complexity. The 
> one-label solution can be implemented using just per platform label space of 
> downstream-allocated labels.
> d. Based on these considerations, my preference (FWIW) is for 
> one-label solution.

I also have the same preference as yours. 

> 3. The draft lists both the already mentioned SR Architecture draft 
> 

Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

[Uma Chunduri]

We recently published a 00 version, undergoing an update to be published during 
IETF week (presented @ LSR WG). 
It addresses label stack reduction for any non-shortest path LSPs including an 
optional path traffic statistics.

https://www.ietf.org/mail-archive/web/dmm/current/msg03162.html 

It would help for SRH more when it comes to TE path. Check out DMM WG (3GPP SA2 
study & proposals) discussions off late.

Best,
--
Uma C.


-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, March 13, 2018 4:30 AM
To: Mach Chen 
Cc: spring@ietf.org; Shell Nakash ; Michael 
Gorokhovsky ; Dmitry Valdman 
; draft-cheng-spring-mpls-path-segm...@ietf.org; 
Stewart Bryant ; Ron Sdayoor 
; Hemmy Yona 
Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

Mach,
Lots of thanks for a prompt and very encouraging response!
One more question: 

Do you and your colleagues plan to define the mechanism for distribution of the 
Path Segment ID in IGP?
(Usually such mechanisms are defined in dedicated drafts separately for OSPF 
and ISIS, but, at least, it should be nice to mention the fact in the draft).

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mach Chen
Sent: Tuesday, March 13, 2018 1:22 PM
To: Alexander Vainshtein ; 
draft-cheng-spring-mpls-path-segm...@ietf.org
Cc: spring@ietf.org; Shell Nakash ; Michael 
Gorokhovsky ; Dmitry Valdman 
; Stewart Bryant ; Ron 
Sdayoor ; Hemmy Yona 
Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

Hi Sasha,

Many thanks for your valuable comments!

Please see my responses inline...

> 
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander 
> Vainshtein
> Sent: Sunday, March 11, 2018 9:44 PM
> To: draft-cheng-spring-mpls-path-segm...@ietf.org
> Cc: spring@ietf.org; Shell Nakash ; Michael 
> Gorokhovsky ; Dmitry Valdman 
> ; Stewart Bryant 
> ; Ron Sdayoor ; 
> Hemmy Yona 
> Subject: [spring] Comments on draft-cheng-spring-mpls-path-segment-01
> 
> Dear authors of draft-cheng-spring-mpls-path-segment-01, and I have a 
> few comments.
> 
> 1. From my POV, the draft addresses the problem of identifying an 
> incoming SR LSP at the tail-end node.
> a. This problem is real because SR LSPs, by their very nature, are 
> MP2P
> (merging) LSPs.
> b. The draft does not try to solve the problem of SR LSP 
> identification in transit nodes.

Yes, that's the intention.

> 2. The draft proposes two solutions (one-label and two-label) for the
> above- mentioned problem, and the authors expect the WG to discuss 
> these solutions and to select the preferred one. As I see it:
> a. Both uses cases discussed in Section 3 of the draft can be 
> addressed with any of these solutions b. IMHO and FWIW, as long as 
> SR-MPLS leaves multicast out of scope (as mentioned in Section 6 of 
> the SR Architecture draft), any future issue with identification of SR 
> LSPs that can be addressed with the two-label solution can also be 
> addressed with the one-label solution c. The two-label solution 
> requires support of upstream-allocated labels and context-specific 
> label spaces, i.e., adds substantial implementation complexity. The 
> one-label solution can be implemented using just per platform label space of 
> downstream-allocated labels.
> d. Based on these considerations, my preference (FWIW) is for 
> one-label solution.

I also have the same preference as yours. 

> 3. The draft lists both the already mentioned SR Architecture draft 
> and the SR- MPLS draft as Informative references, but the SRV6 Routing 
> Header draft appears as a Normative reference. From my POV, the first 
> two documents MUST be Normative references and the last one - an 
> Informative reference, because the draft only deals with SR-MPLS.

Agree, will update it in the next revision.

> 
> Hopefully,  these notes can be useful.

Very useful, as always!

Thanks,
Mach

> 
> Regards,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> 

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

___

This e-mail message is intended for 

Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

[Alexander Vainshtein]

Mach,
Lots of thanks for a prompt and very encouraging response!
One more question: 

Do you and your colleagues plan to define the mechanism for distribution of the 
Path Segment ID in IGP?
(Usually such mechanisms are defined in dedicated drafts separately for OSPF 
and ISIS, but, at least, it should be nice to mention the fact in the draft).

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mach Chen
Sent: Tuesday, March 13, 2018 1:22 PM
To: Alexander Vainshtein ; 
draft-cheng-spring-mpls-path-segm...@ietf.org
Cc: spring@ietf.org; Shell Nakash ; Michael 
Gorokhovsky ; Dmitry Valdman 
; Stewart Bryant ; Ron 
Sdayoor ; Hemmy Yona 
Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

Hi Sasha,

Many thanks for your valuable comments!

Please see my responses inline...

> 
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander 
> Vainshtein
> Sent: Sunday, March 11, 2018 9:44 PM
> To: draft-cheng-spring-mpls-path-segm...@ietf.org
> Cc: spring@ietf.org; Shell Nakash ; Michael 
> Gorokhovsky ; Dmitry Valdman 
> ; Stewart Bryant 
> ; Ron Sdayoor ; 
> Hemmy Yona 
> Subject: [spring] Comments on draft-cheng-spring-mpls-path-segment-01
> 
> Dear authors of draft-cheng-spring-mpls-path-segment-01, and I have a 
> few comments.
> 
> 1. From my POV, the draft addresses the problem of identifying an 
> incoming SR LSP at the tail-end node.
> a. This problem is real because SR LSPs, by their very nature, are 
> MP2P
> (merging) LSPs.
> b. The draft does not try to solve the problem of SR LSP 
> identification in transit nodes.

Yes, that's the intention.

> 2. The draft proposes two solutions (one-label and two-label) for the 
> above- mentioned problem, and the authors expect the WG to discuss 
> these solutions and to select the preferred one. As I see it:
> a. Both uses cases discussed in Section 3 of the draft can be 
> addressed with any of these solutions b. IMHO and FWIW, as long as 
> SR-MPLS leaves multicast out of scope (as mentioned in Section 6 of 
> the SR Architecture draft), any future issue with identification of SR 
> LSPs that can be addressed with the two-label solution can also be 
> addressed with the one-label solution c. The two-label solution 
> requires support of upstream-allocated labels and context-specific 
> label spaces, i.e., adds substantial implementation complexity. The 
> one-label solution can be implemented using just per platform label space of 
> downstream-allocated labels.
> d. Based on these considerations, my preference (FWIW) is for 
> one-label solution.

I also have the same preference as yours. 

> 3. The draft lists both the already mentioned SR Architecture draft 
> and the SR- MPLS draft as Informative references, but the SRV6 Routing 
> Header draft appears as a Normative reference. From my POV, the first 
> two documents MUST be Normative references and the last one - an 
> Informative reference, because the draft only deals with SR-MPLS.

Agree, will update it in the next revision.

> 
> Hopefully,  these notes can be useful.

Very useful, as always!

Thanks,
Mach

> 
> Regards,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> 

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

___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___

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

Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01

[Mach Chen]

Hi Sasha,

Many thanks for your valuable comments!

Please see my responses inline...

> 
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander
> Vainshtein
> Sent: Sunday, March 11, 2018 9:44 PM
> To: draft-cheng-spring-mpls-path-segm...@ietf.org
> Cc: spring@ietf.org; Shell Nakash ; Michael
> Gorokhovsky ; Dmitry Valdman
> ; Stewart Bryant ;
> Ron Sdayoor ; Hemmy Yona
> 
> Subject: [spring] Comments on draft-cheng-spring-mpls-path-segment-01
> 
> Dear authors of draft-cheng-spring-mpls-path-segment-01, and I have a few
> comments.
> 
> 1. From my POV, the draft addresses the problem of identifying an incoming SR
> LSP at the tail-end node.
> a. This problem is real because SR LSPs, by their very nature, are MP2P
> (merging) LSPs.
> b. The draft does not try to solve the problem of SR LSP identification in 
> transit
> nodes.

Yes, that's the intention.

> 2. The draft proposes two solutions (one-label and two-label) for the above-
> mentioned problem, and the authors expect the WG to discuss these solutions
> and to select the preferred one. As I see it:
> a. Both uses cases discussed in Section 3 of the draft can be addressed with 
> any
> of these solutions b. IMHO and FWIW, as long as SR-MPLS leaves multicast out
> of scope (as mentioned in Section 6 of the SR Architecture draft), any future
> issue with identification of SR LSPs that can be addressed with the two-label
> solution can also be addressed with the one-label solution c. The two-label
> solution requires support of upstream-allocated labels and context-specific
> label spaces, i.e., adds substantial implementation complexity. The one-label
> solution can be implemented using just per platform label space of
> downstream-allocated labels.
> d. Based on these considerations, my preference (FWIW) is for one-label
> solution.

I also have the same preference as yours. 

> 3. The draft lists both the already mentioned SR Architecture draft and the 
> SR-
> MPLS draft as Informative references, but the SRV6 Routing Header draft
> appears as a Normative reference. From my POV, the first two documents
> MUST be Normative references and the last one - an Informative reference,
> because the draft only deals with SR-MPLS.

Agree, will update it in the next revision.

> 
> Hopefully,  these notes can be useful.

Very useful, as always!

Thanks,
Mach

> 
> Regards,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> 

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