Jim,
------------------------------------------------------------------James N 
Guichard <james.n.guich...@huawei.com>2018年3月14日(星期三) 03:00Francois Clad 
(fclad) <fc...@cisco.com>; adr...@olddog.co.uk <adr...@olddog.co.uk>mpls 
<m...@ietf.org>; SPRING WG List <spring@ietf.org>; s...@ietf.org 
<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 <m...@ietf.org>; SPRING WG List <spring@ietf.org>; 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 <adr...@olddog.co.uk> 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.
<Xiaohu>  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 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 thing and recall this WG adaptation call.  Thanks 
Regards ... Zafar  From: mpls <mpls-boun...@ietf.org>
 on behalf of "Francois Clad (fclad)" <fc...@cisco.com>
Date: Thursday, March 8, 2018 at 5:21 AM
To: "徐小虎(义先)"
 <xiaohu....@alibaba-inc.com>
Cc: draft-farrel-mpls-sfc <draft-farrel-mpls-...@ietf.org>, "m...@ietf.org"
 <m...@ietf.org>, SPRING WG List <spring@ietf.org>, mpls-chairs 
<mpls-cha...@ietf.org>,
 mpls <mpls-boun...@ietf.org>
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in 
state "Call For Adoption By WG Issued" Hi Xiaohu, all,


I agree with the point raised by Xiaohu. The draft-farrel-mpls-sfc is copying 
ideas described in draft-xu-mpls-service-chaining. Please note that the work in 
draft-xu-mpls-service-chaining started one year before draft-farrel-mpls-sfc.


At IETF100, three drafts in this area were discussed / presented: - 
draft-xu-mpls-service-chaining - draft-farrel-mpls-sfc - 
draft-clad-spring-segment-routing-service-chaining


There was discussion over the mic on the right home for these drafts among SFC, 
SPRING and MPLS, but no consensus was reached.


As Xiaohu mentioned, draft-xu-mpls-service-chaining and 
draft-clad-spring-segment-routing-service-chaining have later merged as 
draft-xuclad-spring-sr-service-chaining. We have also requested a slot for 
presenting this draft during the upcoming IETF meeting.In this context, we 
believe that asking for WG adoption for one of these drafts is premature.Thanks,

Francois On 7 Mar 2018, at 01:13, 徐小虎(义先)
 <xiaohu....@alibaba-inc.com> wrote: Hi all,  As I had pointed out at the last 
IETF meeting, section 6 of this draft has an serious overlap with 
https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03 that
 has now been updated by 
https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01 with
 a merge with draft-clad-spring-segment-routing-service-chaining. Hence, I'm 
very interesting to know the intention of such rewritting of a given mechanism 
that has been described in another draft. Is there any special nutrition? Best 
regards,Xiaohu------------------------------------------------------------------发件人:IETF
 Secretariat <ietf-secretariat-re...@ietf.org>发送时间:2018年3月6日(星期二)
 22:09收件人:draft-farrel-mpls-sfc <draft-farrel-mpls-...@ietf.org>;
 mpls <m...@ietf.org>;
 mpls-chairs <mpls-cha...@ietf.org>主 题:[mpls]
 The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG 
Issued" 

The MPLS WG has placed draft-farrel-mpls-sfc in state

Call For Adoption By WG Issued (entered by Loa Andersson)


The document is available at
https://datatracker.ietf.org/doc/draft-farrel-mpls-sfc/


_______________________________________________

mpls mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mpls_______________________________________________

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

sfc mailing list
s...@ietf.org
https://www.ietf.org/mailman/listinfo/sfc 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to