Subject: Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

From: Robert Raszuk <[email-masked]>
Date: Mon, 2 Apr 2018 13:35:16 +0200

Daniel,

I actually don't think that removal of SR references is a good thing here.
The draft still uses source based label stacking as well as global (domain
wide) meaning of a label. So even without calling it SR it is still based
on SR architecture.

Best,
R

On Sun, Apr 1, 2018 at 5:50 AM, Bernier, Daniel <[email-masked]>
wrote:

> +1,
>
> As explained on the list, with the SR reference removed from
> draft-barrel-mpls-sfc, I have no opposition for it to progress that is IF
> the WG actually believes it needs to. I did question it's need as an label
> based implementation of RFC7665 while we already
> draft-bess-service-chaining to do chain services on existing MPLS platforms.
>
> Cheers,
>
> Daniel Bernier
>

---

From: Loa Andersson <[email-masked]>
Date: Mon, 2 Apr 2018 16:42:03 +0200

Working Group,

I sent this mail some time ago, however I can't see that it
actually reached it destinations.

/Loa

> Working Group, Wim, et.al.,
> 
> We had very good support to adopt already version-04.
> 
> However, after a mail from the author, saying they wanted to make
> come changes in the document, we allowed for publication of
> version-05.
> 
> This version were adopted as a working group document.
> 
> Please note the the wg chairs has to do the consensus call when
> e.g. adopting a document as working group document. We found
> that we had a "rough consensus" to adopt the document.
> 
> This decision was taken by the wg chairs, which is fully within
> the IETF process.
> 
> That decision is taken, the issues that has been pointed out are
> noted. These issues need to be resolved on the mailing list and
> rough consensus need to be reached for text changes in the document.
> 
> Actually the members of the working group have much more influence on
> a working group document, than on an individual draft.
> 
> It would be far better if we now focused on proposing text changes,
> rather than discussing processes.
> 
> /Loa
> mpls wg co-chair
> 
> On 2018-03-30 20:59, Henderickx, Wim (Nokia - BE/Antwerp) wrote:
>> Deborah,
>>
>> There seems to be a flaw in the process here. There were major 
>> objections to the draft against WG adoption. A new draft was spun, so 
>> I would expect a new WG adoption call to happen and get the WG 
>> feedback + decide afterwards if the draft gets adopted or not. The 
>> last part is completely missing. Without such procedure whats the 
>> point of having a WG.
>>
>> So, it would at least be fair per IETF principles to do another WG 
>> adoption call and see what happens.
>>
>> Cheers,
>>
>> Wim
>>
>> *From: *"BRUNGARD, DEBORAH A" <[email-masked]>
>> *Date: *Thursday, 29 March 2018 at 22:03
>> *To: *Robert Raszuk <[email-masked]>
>> *Cc: *"Henderickx, Wim (Nokia - BE/Antwerp)" 
>> <[email-masked]>, "[email-masked]" <[email-masked]>, "徐小虎 
>> (义先)" <[email-masked]>, "[email-masked]" <[email-masked]>, 
>> draft-farrel-mpls-sfc <[email-masked]>, 
>> "[email-masked]" <[email-masked]>, mpls 
>> <[email-masked]>
>> *Subject: *RE: [sfc] [mpls] Working Group adoption of 
>> draft-farrel-mpls-sfc
>>
>> Hi Robert,
>>
>> Looking at the email threads, there was good support for this draft on 
>> the list (look at earlier responses) recognizing it as a needed 
>> approach when the NSH was not supported. The authors have added 
>> sentences to further clarify this does not replace the benefits of 
>> NSH, it is not “fully redundant”. Everyone will have different 
>> approaches for migration depending on their networks and probably 
>> large operators will need to support multiple approaches in various 
>> parts of their network. Just as different approaches for technology 
>> and control are used. As you say, NSH can not be introduced overnight. 
>> But SFCs are being used now, and we need to help the industry 
>> understand potential migration approaches and tradeoffs.
>>
>> This is now a working group document. If you have an alternative MPLS 
>> approach, propose it. Often working group documents get respun several 
>> times.
>>
>> Thanks,
>>
>> Deborah
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of 
>> *Robert Raszuk
>> *Sent:* Thursday, March 29, 2018 3:12 PM
>> *To:* BRUNGARD, DEBORAH A <[email-masked]>
>> *Cc:* Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; 
>> [email-masked]; 徐小虎(义先) <[email-masked]>; 
>> [email-masked]; draft-farrel-mpls-sfc <[email-masked]>; 
>> [email-masked]; mpls <[email-masked]>
>> *Subject:* Re: [sfc] [mpls] Working Group adoption of 
>> draft-farrel-mpls-sfc
>>
>> Dear Deborah,
>>
>> Let me perhaps clarify that our comments were not focused on which WG 
>> this draft should progress in, but if it should progress at all.
>>
>> Forwarding plane is not something companies can spin overnight and 
>> number of us do believe that IETF has already made a call as to 
>> encoding choice of SFC being NSH header. Introducing  MPLS labels to 
>> partially mimic it will likely not help, but disturb the NSH 
>> deployments. It will also introduce development conflicts due to both 
>> hardware and human resource constrains.
>>
>> Moreover as it was also pointed out during the discussion and to which 
>> no one responded MPLS in the data plane has been successfully 
>> developed and deployed in SFC application with the help of 
>> draft-ietf-bess-service-chaining. Control plane is much easier to 
>> extend then to define yet one more data plane.
>>
>> So what are the real technical reasons to introduce fully redundant 
>> data plane encoding for SFC ? And that is regardless in which WG that 
>> would happen.
>>
>> Kind regards,
>>
>> Robert.
>>
>> On Thu, Mar 29, 2018 at 8:57 PM, BRUNGARD, DEBORAH A 
>> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>     Hi,
>>
>>     Both myself (AD for MPLS) and Martin (AD for SFC and SPRING) were
>>     consulted on this draft and we agreed for it to progress in MPLS.
>>
>>     WG adoption allows the document to be a document of the working
>>     group vs. the authors. If you have input for the document, provide
>>     it on the MPLS list. The document will be coordinated at key
>>     transitions with SFC. This is not the first time that documents
>>     early in their timelines may seem to overlap in the different
>>     groups, and need the authors to collaborate to sort out/merge, as
>>     these documents are ultimately products of IETF, and not the
>>     individual authors.
>>
>>     I noted below it is said that this new version does not eliminate
>>     the conflict with the other draft’s approach. It is best to say
>>     specifically which text is in conflict and do a proposal to align.
>>
>>     Thanks,
>>
>>     Deborah
>>
>>     *From:* sfc
>>     [mailto:[email-masked]<mailto:[email-masked]>] *On
>>     Behalf Of *Robert Raszuk
>>     *Sent:* Thursday, March 29, 2018 8:06 AM
>>     *To:* Henderickx, Wim (Nokia - BE/Antwerp)
>>     <[email-masked]<mailto:[email-masked]>>
>>     *Cc:* [email-masked]<mailto:[email-masked]>; 徐小虎(义先)
>>     <[email-masked]<mailto:[email-masked]>>;
>>     [email-masked]<mailto:[email-masked]>; draft-farrel-mpls-sfc
>>     
>> <[email-masked]<mailto:[email-masked]>>;
>>     [email-masked]<mailto:[email-masked]>; mpls
>>     <[email-masked]<mailto:[email-masked]>>
>>     *Subject:* Re: [sfc] [mpls] Working Group adoption of
>>     draft-farrel-mpls-sfc
>>
>>     Hey Wim,
>>
>>     It is very obvious on what basis this adoption happened ....
>>
>>     If ADs do not take any serious action here it will progress smooth &
>>     direct to RFC.
>>
>>     I am only a bit puzzled why the WG last call has not started yet on
>>     this :/.
>>
>>     Best,
>>
>>     R.
>>
>>     On Wed, Mar 28, 2018 at 10:25 AM, Henderickx, Wim (Nokia -
>>     BE/Antwerp)
>>     <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>         Similar comment here on what basis do we adopt this. There were
>>         serious issues and although a new draft was posted they have not
>>         been addressed. On what basis do you adopt this? I thought IETF
>>         works on basis of consensus and in my view this was not achieved
>>         so far.
>>
>>          From iPhone
>>
>>         
>> ------------------------------------------------------------------------
>>
>>         *From:*mpls
>>         <[email-masked]<mailto:[email-masked]>> on behalf
>>         of 徐小虎(义先)
>>         <[email-masked]<mailto:[email-masked]>>
>>         *Sent:* Wednesday, March 28, 2018 10:17:04 AM
>>         *To:* mpls; [email-masked]<mailto:[email-masked]>
>>         *Cc:* draft-farrel-mpls-sfc;
>>         [email-masked]<mailto:[email-masked]>;
>>         [email-masked]<mailto:[email-masked]>
>>         *Subject:* Re: [mpls] Working Group adoption of
>>         draft-farrel-mpls-sfc
>>
>>         Hi Loa,
>>
>>         I don't believe the modification in Section 6 of
>>         draft-farrel-mpls-sfc
>>         
>> (https://tools.ietf.org/rfcdiff?url2=draft-farrel-mpls-sfc-05.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfarrel-2Dmpls-2Dsfc-2D05.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=ztYp9cmCmsjVMZ_-dGDWFg9kO1Kj7tP9b3VpgMVoJrw&e=>) 
>>
>>         has eliminated the serious conflict with the SR-MPLS-based SFC
>>         approach as described in
>>         
>> https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dmpls-2Dservice-2Dchaining-2D03&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=G-AiwBZi02SAyGhGBxiXhU_BHgQcuYKJlxpyeTYsgz0&e=> (note 
>>
>>         that this draft has been merged into
>>         
>> https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dclad-2Dspring-2Dsr-2Dservice-2Dchaining-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=Ul-MW_AEUW2CKbWwZ3C0KOPM0gW5dUwxoMFR050i1T0&e=>), 
>>
>>         as had been pointed by many people before.
>>
>>         Therefore, it seems a little bit unreasonable to hurry the
>>         adoption of the current version, IMHO.
>>
>>         Xiaohu
>>
>>             
>> ------------------------------------------------------------------
>>
>>             Loa Andersson <[email-masked]<mailto:[email-masked]>>
>>
>>             2018年3月28日(星期三) 15:56
>>
>>             
>> [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
>>
>>             draft-farrel-mpls-sfc
>>             
>> <[email-masked]<mailto:[email-masked]>>;
>>             
>> [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>;
>>             
>> [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>> 
>>
>>
>>             [mpls] Working Group adoption of draft-farrel-mpls-sfc
>>
>>             Working Group,
>>
>>             
>> The MPLS working group have decided to adopt draft-farrel-mpls-sfc-05 as
>>             an MPLS working group document.
>>
>>             
>> Can the authors please post draft-ietf-mpls-sfc-00, without any other
>>             than administrative (filename, version and dates) changes.
>>
>>             /Loa
>>             for the MPLS wg chairs
>>
>>             --
>>
>>             Loa Andersson                        email:
>>             [email-masked]<mailto:[email-masked]>
>>             Senior MPLS Expert
>>             Bronze Dragon Consulting             phone: +46 739 81 21 64
>>
>>             _______________________________________________
>>             mpls mailing list
>>             [email-masked]<mailto:[email-masked]>
>>             
>> https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=R5fzJWvbB4NSwtL3I3_FvNHHjJJsuKb8Cxf-2gQw6hI&e=> 
>>
>>
>>
>>         _______________________________________________
>>         mpls mailing list
>>         [email-masked]<mailto:[email-masked]>
>>         
>> https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=R5fzJWvbB4NSwtL3I3_FvNHHjJJsuKb8Cxf-2gQw6hI&e=> 
>>
>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Lizhenbin <[email-masked]>
Date: Mon, 2 Apr 2018 09:23:53 +0000

I agreed with Wim and Zafar’s suggestion. I do not think the new version of draft-farrel-mpls-sfc solves the confliction issue with the draft https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dclad-2Dspring-2Dsr-2Dservice-2Dchaining-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=Ul-MW_AEUW2CKbWwZ3C0KOPM0gW5dUwxoMFR050i1T0&e=>. The adoption will only propose more debates and concerns.

发件人: sfc [mailto:[email-masked]] 代表 Zafar Ali (zali)
发送时间: 2018年3月31日 4:40
收件人: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; Robert Raszuk <[email-masked]>
抄送: [email-masked]; 徐小虎(义先) <[email-masked]>; [email-masked]; draft-farrel-mpls-sfc <[email-masked]>; [email-masked]; mpls <[email-masked]>
主题: Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

Hi Loa, Deborah and all,

I agree with Wim's suggestion. The new version (draft-farrel-mpls-sfc-05) does not address the comments and concerns raised by the working group and acknowledged by the authors. The limited support came during the early stage of the pool before the issue concerning section 6 of the draft was raised. In other words, the limited support may have been influenced by the segment routing contents in the document, which authors have agreed to remove. SFC WG was also missed in the initial portion of the pool.

Given the circumstances, the only fair next step would be that the authors of draft-farrel-mpls-sfc first address the WG comments and concerns; they can then ask for the WG adoption. This way everyone will have a fair chance to vote on the correct contents.

Thanks

Regards ... Zafar

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 30, 2018 at 2:59 PM
To: "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "徐小虎(义先)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, draft-farrel-mpls-sfc <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

Deborah,

There seems to be a flaw in the process here. There were major objections to the draft against WG adoption. A new draft was spun, so I would expect a new WG adoption call to happen and get the WG feedback + decide afterwards if the draft gets adopted or not. The last part is completely missing. Without such procedure whats the point of having a WG.

So, it would at least be fair per IETF principles to do another WG adoption call and see what happens.

Cheers,
Wim

From: "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 29 March 2018 at 22:03
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "徐小虎(义先)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, draft-farrel-mpls-sfc <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

Hi Robert,

Looking at the email threads, there was good support for this draft on the list (look at earlier responses) recognizing it as a needed approach when the NSH was not supported. The authors have added sentences to further clarify this does not replace the benefits of NSH, it is not “fully redundant”. Everyone will have different approaches for migration depending on their networks and probably large operators will need to support multiple approaches in various parts of their network. Just as different approaches for technology and control are used. As you say, NSH can not be introduced overnight. But SFCs are being used now, and we need to help the industry understand potential migration approaches and tradeoffs.

This is now a working group document. If you have an alternative MPLS approach, propose it. Often working group documents get respun several times.

Thanks,
Deborah

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, March 29, 2018 3:12 PM
To: BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; draft-farrel-mpls-sfc <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

Dear Deborah,

Let me perhaps clarify that our comments were not focused on which WG this draft should progress in, but if it should progress at all.

Forwarding plane is not something companies can spin overnight and number of us do believe that IETF has already made a call as to encoding choice of SFC being NSH header. Introducing  MPLS labels to partially mimic it will likely not help, but disturb the NSH deployments. It will also introduce development conflicts due to both hardware and human resource constrains.

Moreover as it was also pointed out during the discussion and to which no one responded MPLS in the data plane has been successfully developed and deployed in SFC application with the help of draft-ietf-bess-service-chaining. Control plane is much easier to extend then to define yet one more data plane.

So what are the real technical reasons to introduce fully redundant data plane encoding for SFC ? And that is regardless in which WG that would happen.

Kind regards,
Robert.

On Thu, Mar 29, 2018 at 8:57 PM, BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Both myself (AD for MPLS) and Martin (AD for SFC and SPRING) were consulted on this draft and we agreed for it to progress in MPLS.

WG adoption allows the document to be a document of the working group vs. the authors. If you have input for the document, provide it on the MPLS list. The document will be coordinated at key transitions with SFC. This is not the first time that documents early in their timelines may seem to overlap in the different groups, and need the authors to collaborate to sort out/merge, as these documents are ultimately products of IETF, and not the individual authors.

I noted below it is said that this new version does not eliminate the conflict with the other draft’s approach. It is best to say specifically which text is in conflict and do a proposal to align.

Thanks,
Deborah

From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Thursday, March 29, 2018 8:06 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; draft-farrel-mpls-sfc <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

Hey Wim,

If ADs do not take any serious action here it will progress smooth & direct to RFC.

I am only a bit puzzled why the WG last call has not started yet on this :/.

Best,
R.

On Wed, Mar 28, 2018 at 10:25 AM, Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>> wrote:
Similar comment here on what basis do we adopt this. There were serious issues and although a new draft was posted they have not been addressed. On what basis do you adopt this? I thought IETF works on basis of consensus and in my view this was not achieved so far.

From iPhone

From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 28, 2018 10:17:04 AM
To: mpls; [email-masked]<mailto:[email-masked]>
Cc: draft-farrel-mpls-sfc; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Working Group adoption of draft-farrel-mpls-sfc

Hi Loa,

I don't believe the modification in Section 6 of draft-farrel-mpls-sfc (https://tools.ietf.org/rfcdiff?url2=draft-farrel-mpls-sfc-05.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfarrel-2Dmpls-2Dsfc-2D05.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=ztYp9cmCmsjVMZ_-dGDWFg9kO1Kj7tP9b3VpgMVoJrw&e=>) has eliminated the serious conflict with the SR-MPLS-based SFC approach as described in  https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dmpls-2Dservice-2Dchaining-2D03&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=G-AiwBZi02SAyGhGBxiXhU_BHgQcuYKJlxpyeTYsgz0&e=> (note that this draft has been merged into https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dclad-2Dspring-2Dsr-2Dservice-2Dchaining-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=Ul-MW_AEUW2CKbWwZ3C0KOPM0gW5dUwxoMFR050i1T0&e=>), as had been pointed by many people before.

Therefore, it seems a little bit unreasonable to hurry the adoption of the current version, IMHO.

Xiaohu
------------------------------------------------------------------
Loa Andersson <[email-masked]<mailto:[email-masked]>>
2018年3月28日(星期三) 15:56
[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
draft-farrel-mpls-sfc <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
[mpls] Working Group adoption of draft-farrel-mpls-sfc

Working Group,

/Loa
for the MPLS wg chairs

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Bernier, Daniel" <[email-masked]>
Date: Wed, 4 Apr 2018 03:25:52 +0000

Hi,

Robert, from what I gather, these labels (although it may be perceived as such) are there to represent in label stack format the SPI/SI of NSH providing path awareness at each hop in the network, not used in the forwarding path. The reference to SR seems only to be on wether one should use pop/swap or SR for transport ... not much added value in the draft except to affirm that it could run over an SR-MPLS implementation.

I agree that it is plays strangely close to SR architecture by the use of global labels for unique IDs. I am cautious about it though because it would mean that anyone that comes up with an idea of using globally assigned labels for a specific use case might be forbidden.

What I am really challenging is the necessity for this draft knowing that:

a) we have a working implementation of VPN based chaining with draft-bess-service-chaining where path info resides in BGP control-plane.

b) we have RFC8300 for service overlay where path info resides in the NSH header and is carried along the path.?

c) we have draft-xuclad-sr-service-chaining using segment-routing where path info is known at the edges and potentially computed at a controller.

Cheers,

Dan B

________________________________
From: [email-masked] <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Sent: Monday, April 2, 2018 7:35 AM
To: Bernier, Daniel
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

Daniel,

I actually don't think that removal of SR references is a good thing here. The draft still uses source based label stacking as well as global (domain wide) meaning of a label. So even without calling it SR it is still based on SR architecture.

Best,
R

On Sun, Apr 1, 2018 at 5:50 AM, Bernier, Daniel <[email-masked]<mailto:[email-masked]>> wrote:

+1,

As explained on the list, with the SR reference removed from draft-barrel-mpls-sfc, I have no opposition for it to progress that is IF the WG actually believes it needs to. I did question it's need as an label based implementation of RFC7665 while we already draft-bess-service-chaining to do chain services on existing MPLS platforms.

Cheers,

Daniel Bernier

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Sun, 8 Apr 2018 06:03:16 +0000

Loa, I still don’t see where the consensus was reached. I looked back at the tracker and you see same amount of people for as well as against and none of the issues raised have been addressed, based on the feedback you have seen.
So I really question the process here and 2nd you should run another poll on the new draft given the issues were not addressed.

On 02/04/2018, 16:42, "Loa Andersson" <[email-masked]> wrote:

    Working Group,

    /Loa

    
    --

---

From: "徐小虎(义先)" <[email-masked]>
Date: Sun, 08 Apr 2018 15:14:35 +0800

+1
Xiaohu
------------------------------------------------------------------Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>2018年4月8日(星期日) 14:03Loa Andersson <[email-masked]>; [email-masked] <[email-masked]>draft-farrel-mpls-sfc <[email-masked]>; [email-masked] <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked] <[email-masked]>Re: [mpls] Working Group adoption of draft-farrel-mpls-sfc
Loa, I still don’t see where the consensus was reached. I looked back at the tracker and you see same amount of people for as well as against and none of the issues raised have been addressed, based on the feedback you have seen.
So I really question the process here and 2nd you should run another poll on the new draft given the issues were not addressed.

    Working Group,

    /Loa

    > Working Group, Wim, et.al.,
    > 
    > We had very good support to adopt already version-04.
    > 
    > However, after a mail from the author, saying they wanted to make
    > come changes in the document, we allowed for publication of
    > version-05.
    > 
    > This version were adopted as a working group document.
    > 
    > Please note the the wg chairs has to do the consensus call when
    > e.g. adopting a document as working group document. We found
    > that we had a "rough consensus" to adopt the document.
    > 
    > This decision was taken by the wg chairs, which is fully within
    > the IETF process.
    > 
    > That decision is taken, the issues that has been pointed out are
    > noted. These issues need to be resolved on the mailing list and
    > rough consensus need to be reached for text changes in the document.
    > 
    > Actually the members of the working group have much more influence on
    > a working group document, than on an individual draft.
    > 
    > It would be far better if we now focused on proposing text changes,
    > rather than discussing processes.
    > 
    > /Loa
    > mpls wg co-chair
    > 
    > On 2018-03-30 20:59, Henderickx, Wim (Nokia - BE/Antwerp) wrote:
    >> Deborah,
    >>
    >> There seems to be a flaw in the process here. There were major 
    >> objections to the draft against WG adoption. A new draft was spun, so 
    >> I would expect a new WG adoption call to happen and get the WG 
    >> feedback + decide afterwards if the draft gets adopted or not. The 
    >> last part is completely missing. Without such procedure whats the 
    >> point of having a WG.
    >>
    >> So, it would at least be fair per IETF principles to do another WG 
    >> adoption call and see what happens.
    >>
    >> Cheers,
    >>
    >> Wim
    >>
    >> *From: *"BRUNGARD, DEBORAH A" <[email-masked]>
    >> *Date: *Thursday, 29 March 2018 at 22:03
    >> *To: *Robert Raszuk <[email-masked]>
    >> *Cc: *"Henderickx, Wim (Nokia - BE/Antwerp)" 
    >> <[email-masked]>, "[email-masked]" <[email-masked]>, "徐小虎 
    >> (义先)" <[email-masked]>, "[email-masked]" <[email-masked]>, 
    >> draft-farrel-mpls-sfc <[email-masked]>, 
    >> "[email-masked]" <[email-masked]>, mpls 
    >> <[email-masked]>
    >> *Subject: *RE: [sfc] [mpls] Working Group adoption of 
    >> draft-farrel-mpls-sfc
    >>
    >> Hi Robert,
    >>
    >> Looking at the email threads, there was good support for this draft on 
    >> the list (look at earlier responses) recognizing it as a needed 
    >> approach when the NSH was not supported. The authors have added 
    >> sentences to further clarify this does not replace the benefits of 
    >> NSH, it is not “fully redundant”. Everyone will have different 
    >> approaches for migration depending on their networks and probably 
    >> large operators will need to support multiple approaches in various 
    >> parts of their network. Just as different approaches for technology 
    >> and control are used. As you say, NSH can not be introduced overnight. 
    >> But SFCs are being used now, and we need to help the industry 
    >> understand potential migration approaches and tradeoffs.
    >>
    >> This is now a working group document. If you have an alternative MPLS 
    >> approach, propose it. Often working group documents get respun several 
    >> times.
    >>
    >> Thanks,
    >>
    >> Deborah
    >>
    >> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of 
    >> *Robert Raszuk
    >> *Sent:* Thursday, March 29, 2018 3:12 PM
    >> *To:* BRUNGARD, DEBORAH A <[email-masked]>
    >> *Cc:* Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; 
    >> [email-masked]; 徐小虎(义先) <[email-masked]>; 
    >> [email-masked]; draft-farrel-mpls-sfc <[email-masked]>; 
    >> [email-masked]; mpls <[email-masked]>
    >> *Subject:* Re: [sfc] [mpls] Working Group adoption of 
    >> draft-farrel-mpls-sfc
    >>
    >> Dear Deborah,
    >>
    >> Let me perhaps clarify that our comments were not focused on which WG 
    >> this draft should progress in, but if it should progress at all.
    >>
    >> Forwarding plane is not something companies can spin overnight and 
    >> number of us do believe that IETF has already made a call as to 
    >> encoding choice of SFC being NSH header. Introducing  MPLS labels to 
    >> partially mimic it will likely not help, but disturb the NSH 
    >> deployments. It will also introduce development conflicts due to both 
    >> hardware and human resource constrains.
    >>
    >> Moreover as it was also pointed out during the discussion and to which 
    >> no one responded MPLS in the data plane has been successfully 
    >> developed and deployed in SFC application with the help of 
    >> draft-ietf-bess-service-chaining. Control plane is much easier to 
    >> extend then to define yet one more data plane.
    >>
    >> So what are the real technical reasons to introduce fully redundant 
    >> data plane encoding for SFC ? And that is regardless in which WG that 
    >> would happen.
    >>
    >> Kind regards,
    >>
    >> Robert.
    >>
    >> On Thu, Mar 29, 2018 at 8:57 PM, BRUNGARD, DEBORAH A 
    >> <[email-masked]<mailto:[email-masked]>> wrote:
    >>
    >>     Hi,
    >>
    >>     Both myself (AD for MPLS) and Martin (AD for SFC and SPRING) were
    >>     consulted on this draft and we agreed for it to progress in MPLS.
    >>
    >>     WG adoption allows the document to be a document of the working
    >>     group vs. the authors. If you have input for the document, provide
    >>     it on the MPLS list. The document will be coordinated at key
    >>     transitions with SFC. This is not the first time that documents
    >>     early in their timelines may seem to overlap in the different
    >>     groups, and need the authors to collaborate to sort out/merge, as
    >>     these documents are ultimately products of IETF, and not the
    >>     individual authors.
    >>
    >>     I noted below it is said that this new version does not eliminate
    >>     the conflict with the other draft’s approach. It is best to say
    >>     specifically which text is in conflict and do a proposal to align.
    >>
    >>     Thanks,
    >>
    >>     Deborah
    >>
    >>     *From:* sfc
    >>     [mailto:[email-masked]<mailto:[email-masked]>] *On
    >>     Behalf Of *Robert Raszuk
    >>     *Sent:* Thursday, March 29, 2018 8:06 AM
    >>     *To:* Henderickx, Wim (Nokia - BE/Antwerp)
    >>     <[email-masked]<mailto:[email-masked]>>
    >>     *Cc:* [email-masked]<mailto:[email-masked]>; 徐小虎(义先)
    >>     <[email-masked]<mailto:[email-masked]>>;
    >>     [email-masked]<mailto:[email-masked]>; draft-farrel-mpls-sfc
    >>     
    >> <[email-masked]<mailto:[email-masked]>>;
    >>     [email-masked]<mailto:[email-masked]>; mpls
    >>     <[email-masked]<mailto:[email-masked]>>
    >>     *Subject:* Re: [sfc] [mpls] Working Group adoption of
    >>     draft-farrel-mpls-sfc
    >>
    >>     Hey Wim,
    >>
    >>     It is very obvious on what basis this adoption happened ....
    >>
    >>     If ADs do not take any serious action here it will progress smooth &
    >>     direct to RFC.
    >>
    >>     I am only a bit puzzled why the WG last call has not started yet on
    >>     this :/.
    >>
    >>     Best,
    >>
    >>     R.
    >>
    >>     On Wed, Mar 28, 2018 at 10:25 AM, Henderickx, Wim (Nokia -
    >>     BE/Antwerp)
    >>     <[email-masked]<mailto:[email-masked]>> wrote:
    >>
    >>         Similar comment here on what basis do we adopt this. There were
    >>         serious issues and although a new draft was posted they have not
    >>         been addressed. On what basis do you adopt this? I thought IETF
    >>         works on basis of consensus and in my view this was not achieved
    >>         so far.
    >>
    >>          From iPhone
    >>
    >>         
    >> ------------------------------------------------------------------------
    >>
    >>         *From:*mpls
    >>         <[email-masked]<mailto:[email-masked]>> on behalf
    >>         of 徐小虎(义先)
    >>         <[email-masked]<mailto:[email-masked]>>
    >>         *Sent:* Wednesday, March 28, 2018 10:17:04 AM
    >>         *To:* mpls; [email-masked]<mailto:[email-masked]>
    >>         *Cc:* draft-farrel-mpls-sfc;
    >>         [email-masked]<mailto:[email-masked]>;
    >>         [email-masked]<mailto:[email-masked]>
    >>         *Subject:* Re: [mpls] Working Group adoption of
    >>         draft-farrel-mpls-sfc
    >>
    >>         Hi Loa,
    >>
    >>         I don't believe the modification in Section 6 of
    >>         draft-farrel-mpls-sfc
    >>         
    >> (https://tools.ietf.org/rfcdiff?url2=draft-farrel-mpls-sfc-05.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfarrel-2Dmpls-2Dsfc-2D05.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=ztYp9cmCmsjVMZ_-dGDWFg9kO1Kj7tP9b3VpgMVoJrw&e=>) 
    >>
    >>         has eliminated the serious conflict with the SR-MPLS-based SFC
    >>         approach as described in
    >>         
    >> https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dmpls-2Dservice-2Dchaining-2D03&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=G-AiwBZi02SAyGhGBxiXhU_BHgQcuYKJlxpyeTYsgz0&e=> (note 
    >>
    >>         that this draft has been merged into
    >>         
    >> https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dclad-2Dspring-2Dsr-2Dservice-2Dchaining-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=Ul-MW_AEUW2CKbWwZ3C0KOPM0gW5dUwxoMFR050i1T0&e=>), 
    >>
    >>         as had been pointed by many people before.
    >>
    >>         Therefore, it seems a little bit unreasonable to hurry the
    >>         adoption of the current version, IMHO.
    >>
    >>         Xiaohu
    >>
    >>             
    >> ------------------------------------------------------------------
    >>
    >>             Loa Andersson <[email-masked]<mailto:[email-masked]>>
    >>
    >>             2018年3月28日(星期三) 15:56
    >>
    >>             
    >> [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
    >>
    >>             draft-farrel-mpls-sfc
    >>             
    >> <[email-masked]<mailto:[email-masked]>>;
    >>             
    >> [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>;
    >>             
    >> [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>> 
    >>
    >>
    >>             [mpls] Working Group adoption of draft-farrel-mpls-sfc
    >>
    >>             Working Group,
    >>
    >>             
    >> The MPLS working group have decided to adopt draft-farrel-mpls-sfc-05 as
    >>             an MPLS working group document.
    >>
    >>             
    >> Can the authors please post draft-ietf-mpls-sfc-00, without any other
    >>             than administrative (filename, version and dates) changes.
    >>
    >>             /Loa
    >>             for the MPLS wg chairs
    >>
    >>             --
    >>
    >>             Loa Andersson                        email:
    >>             [email-masked]<mailto:[email-masked]>
    >>             Senior MPLS Expert
    >>             Bronze Dragon Consulting             phone: +46 739 81 21 64
    >>
    >>             _______________________________________________
    >>             mpls mailing list
    >>             [email-masked]<mailto:[email-masked]>
    >>             
    >> https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=R5fzJWvbB4NSwtL3I3_FvNHHjJJsuKb8Cxf-2gQw6hI&e=> 
    >>
    >>
    >>
    >>         _______________________________________________
    >>         mpls mailing list
    >>         [email-masked]<mailto:[email-masked]>
    >>         
    >> https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=R5fzJWvbB4NSwtL3I3_FvNHHjJJsuKb8Cxf-2gQw6hI&e=> 
    >>
    >>
    >>
    >>
    >> _______________________________________________
    >> mpls mailing list
    >> [email-masked]
    >> https://www.ietf.org/mailman/listinfo/mpls
    >>
    > 
    
    --

---

From: Loa Andersson <[email-masked]>
Date: Mon, 9 Apr 2018 09:46:02 +0200

Wim, et.al.,

There are a number of things that could be discussed in this context.
We might view the IETF process slightly different.

The IETF allow for "rough consensus". Meaning that there mihgt be
some wg members that are "in the rough", i.e. not supporting the
decisions taken by the part of the working group forming the "rough
consensus" group.

Being in the rough is sometimes hard, the best way forward is often to
accept the decision and try to constructively contribute to e.g.
progressing a document.

You say that "none of the issues raised have been addressed", the
validity of the statement depends on what you mean by addressed.

"Addressed" is normally a language that we use when requesting
publication of a document. "Addressed" is more or less synonymous
with "solved".

In the context of working group adoption poll "addressed" in this
meaning is not necessary. "Addressed" in this context should mean
"recognized" and that all parties are willing to discuss the issues.

There are a few criteria for accepting a document as a working group
document

- the document is a good enough starting point
- enough support (rough consensus) in the working group to adopt
   the document
- there are enough people in the wg that are willing to work on
   the document
- any issues that are recognized in the poll, is deemed to be possible
   to during the working group process

All these three criteria are met. Especially for the third criteria
the wg chair believe that it is easier to resolve the issues if the
working group holds the revision control and make consensus calls
(explicit or implicit) on these issues or other text changes to the
document.

With this I hope we can can put this process discussion to the side
and instead focus on the technical issues.

/Loa
mpls wg co-chair

--

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 9 Apr 2018 09:44:20 +0000

Loa, the part where I disagree is the rough consensus since you see equal number of people for/against. I don’t call this rough consensus.

On 09/04/2018, 09:46, "Loa Andersson" <[email-masked]> wrote:

    Wim, et.al.,

    

    

    

    /Loa
    mpls wg co-chair

    --

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Mon, 9 Apr 2018 09:54:50 +0000

I agree with Wim. We have had a similar situation with a BIER draft WG adoption and the outcome is simple: work to resolve issues so a document has details and broader support. 

Bending the process that kept IETF producing quality for years creates a dangerous precedent. A WG draft adoption call is not a place for that. 

Andrew

Sent from my iPhone

> On Apr 9, 2018, at 11:44 AM, Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "徐小虎(义先)" <[email-masked]>
Date: Mon, 09 Apr 2018 18:22:24 +0800

I fully agree that the WG adoption poll should be started after the issues have been addressed.
Best regards,Xiaohu
------------------------------------------------------------------Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>2018年4月9日(星期一) 17:55"Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>[email-masked] <[email-masked]>; Robert Raszuk <[email-masked]>; draft-farrel-mpls-sfc <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>Re: [mpls] [sfc]  Working Group adoption of draft-farrel-mpls-sfc
I agree with Wim. We have had a similar situation with a BIER draft WG adoption and the outcome is simple: work to resolve issues so a document has details and broader support. 

Andrew

Sent from my iPhone

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Apr 2018 10:41:15 +0000

If you exclude co-authors it is not even equal ;)

Best,
R.

On Mon, Apr 9, 2018, 11:44 Henderickx, Wim (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> Loa, the part where I disagree is the rough consensus since you see equal
> number of people for/against. I don’t call this rough consensus.
>
>     > Loa, I still don’t see where the consensus was reached. I looked
> back at the tracker and you see same amount of people for as well as
> against and none of the issues raised have been addressed, based on the
> feedback you have seen.
>     > So I really question the process here and 2nd you should run another
> poll on the new draft given the issues were not addressed.
>     >
> on behalf
>     >      >> (
> https://tools.ietf.org/rfcdiff?url2=draft-farrel-mpls-sfc-05.txt<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfarrel-2Dmpls-2Dsfc-2D05.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=ztYp9cmCmsjVMZ_-dGDWFg9kO1Kj7tP9b3VpgMVoJrw&e=
> >)
>     >      >>
> https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dmpls-2Dservice-2Dchaining-2D03&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=G-AiwBZi02SAyGhGBxiXhU_BHgQcuYKJlxpyeTYsgz0&e=>
> (note
>     >      >>
> https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dclad-2Dspring-2Dsr-2Dservice-2Dchaining-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=Ul-MW_AEUW2CKbWwZ3C0KOPM0gW5dUwxoMFR050i1T0&e=
> >),
>     >      >>
>     >      >> [email-masked]<mailto:[email-masked]><
> [email-masked]<mailto:[email-masked]>>
>     >      >>
>     >      >>
>     >      >> https://www.ietf.org/mailman/listinfo/mpls<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=R5fzJWvbB4NSwtL3I3_FvNHHjJJsuKb8Cxf-2gQw6hI&e=
> >
>     >      >>
>     >      >>
>     >      >>
>     >      >> https://www.ietf.org/mailman/listinfo/mpls<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KYDHMX0VHLQFDKH4tDeCulCk3aZJkwGUKsyTKezhMLQ&s=R5fzJWvbB4NSwtL3I3_FvNHHjJJsuKb8Cxf-2gQw6hI&e=
> >
>     >      >>
>     >      >>
>     >      >>
>     >      >>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 9 Apr 2018 16:53:08 +0000

+1,

Thanks

Regards … Zafar

From: mpls <[email-masked]> on behalf of "徐小虎(义先)" <[email-masked]>
Reply-To: "徐小虎(义先)" <[email-masked]>
Date: Monday, April 9, 2018 at 6:23 AM
To: mpls <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Cc: draft-farrel-mpls-sfc <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>
Subject: Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc

Best regards,
Xiaohu

------------------------------------------------------------------
Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>
2018年4月9日(星期一) 17:55
"Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
[email-masked] <[email-masked]>; Robert Raszuk <[email-masked]>; draft-farrel-mpls-sfc <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc

Andrew

Sent from my iPhone

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Apr 2018 17:04:09 +0200

Rather than have a process discussion, I think we should go up a level 
and better understand the technical differences between the two drafts.

draft-farrel-mpls-sfc describes the actions at a hop in terms of a tuple 
that mirrors the SFC approach that allows a short indication of 
potentially re-entrant chains. In its simplest form it uses a compact 
MPLS stack to describe an arbitarily complex path that is compatile with 
simple edge routers which are often challenged in terms of the number of 
labels that they can push.

draft-xu-clad-spring-sr-service-chaining unrolls the path and explicitly 
calls out each hop and each function into the label stack. This results 
in a much larger MPLS label stack that will challenge some edge routers. 
The way that we generally deal with imposition limits is through the use 
of binding-SIDs, which in the limiting case resolves to the approach in 
draft-farrel with the limitation that the position on the path is 
implicit in the label stack size rather than explicitly specified by the SI.

Mid-flight path changes (if such things are needed) is clearly simpler 
with draft-farrel.

The short stack in draft-farrel comes at the cost of greater network 
forwarding stack, and the long stack is the price that draft-xu-clad 
pays for the reduction in forwarding state.

The optimal design point between forwarding and control plane state is 
something that is dependent on many parameters, and is dependent on many 
network and operational factors, so much so, that don't think it is wise 
to rule either out of scope at this stage.

The hybrid mode in section 6 of draft-farrel supports the mixed mode in 
section 7 of the draft. This allows the construction of SFCs that are 
the concatination of two or more compacted sub-chains. This allows the 
operator to deploy a solution with the advantages of draft-farrel 
together with some of the flexibility of draft-xu-clad.

At this stage the two drafts are sufficienly different that I think we 
need to proceed with both at least to the point where we fully 
understand the detailed consequences of the two approachs and the 
scenarios where each finds it's niche.

After developing a better understanding the detail of each design, their 
control plane, and operational contexts and how each maps to customer 
network requirements, we can move the drafts to the appropriate IETF 
track. Such tracks may be anything from abandonment to IETF standard for 
one or both of these approaches.

Meanwhile I think that we need to focus our efforts on a deeper 
understanding of the technology and how each might make the Internet 
work better,  rather than spending effort on arguing about IETF process.

- Stewart

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 12 Apr 2018 15:11:52 +0000

+1

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, April 12, 2018 11:04 AM
To: Bernier, Daniel <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

- Stewart

_______________________________________________
sfc mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sfc&d=DwIF-g&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=sHc8KKHgu76CAgLkfNsMIfWnNnc6IgMiA5m1eRlUIb4&s=6RsCWXgjUI-aMZvAu85xXSLT4pn1Z2LDUEWqijS5C5U&e=

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Apr 2018 15:19:38 +0000

Stewart and all,
I concur with Stewart with one minor correction: the "simple edge routers" are not the only category of routers that would have problems with imposition of a very deep label stack. And the problem with such stacks goes beyond imposition if effective ECMP is supposed to be used by transit routers, because the labels that carry entropy are located somewhere at the bottom of the label stack and therefore may be not readable by transit routers even if imposition succeeded...

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, April 12, 2018 6:04 PM
To: Bernier, Daniel <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc

Rather than have a process discussion, I think we should go up a level and better understand the technical differences between the two drafts.

draft-farrel-mpls-sfc describes the actions at a hop in terms of a tuple that mirrors the SFC approach that allows a short indication of potentially re-entrant chains. In its simplest form it uses a compact MPLS stack to describe an arbitarily complex path that is compatile with simple edge routers which are often challenged in terms of the number of labels that they can push.

draft-xu-clad-spring-sr-service-chaining unrolls the path and explicitly calls out each hop and each function into the label stack. This results in a much larger MPLS label stack that will challenge some edge routers. 
The way that we generally deal with imposition limits is through the use of binding-SIDs, which in the limiting case resolves to the approach in draft-farrel with the limitation that the position on the path is implicit in the label stack size rather than explicitly specified by the SI.

Mid-flight path changes (if such things are needed) is clearly simpler with draft-farrel.

The short stack in draft-farrel comes at the cost of greater network forwarding stack, and the long stack is the price that draft-xu-clad pays for the reduction in forwarding state.

The optimal design point between forwarding and control plane state is something that is dependent on many parameters, and is dependent on many network and operational factors, so much so, that don't think it is wise to rule either out of scope at this stage.

The hybrid mode in section 6 of draft-farrel supports the mixed mode in section 7 of the draft. This allows the construction of SFCs that are the concatination of two or more compacted sub-chains. This allows the operator to deploy a solution with the advantages of draft-farrel together with some of the flexibility of draft-xu-clad.

At this stage the two drafts are sufficienly different that I think we need to proceed with both at least to the point where we fully understand the detailed consequences of the two approachs and the scenarios where each finds it's niche.

After developing a better understanding the detail of each design, their control plane, and operational contexts and how each maps to customer network requirements, we can move the drafts to the appropriate IETF track. Such tracks may be anything from abandonment to IETF standard for one or both of these approaches.

Meanwhile I think that we need to focus our efforts on a deeper understanding of the technology and how each might make the Internet work better,  rather than spending effort on arguing about IETF process.

- Stewart

___________________________________________________________________________

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Apr 2018 17:31:51 +0200

Hi Stewart,

1.

> In its simplest form it uses a compact MPLS stack to describe an
arbitarily complex path

What exactly is "compact" in MPLS label stack as defined in
draft-ietf-mpls-sfc ?

     -------------------
    ~   Tunnel Labels   ~
    +-------------------+
    ~     Optional      ~
    ~   Entropy Label   ~
    +-------------------+ - - -
    | SFC Context Label |
    +-------------------+  Basic unit of MPLS label stack for SFC
    |     SF Label      |
    +-------------------+ - - -
    | SFC Context Label |
    +-------------------+  Basic unit of MPLS label stack for SFC
    |     SF Label      |
    +-------------------+ - - -
    ~                   ~
    +-------------------+ - - -
    | SFC Context Label |
    +-------------------+  Basic unit of MPLS label stack for SFC
    |     SF Label      |
    +-------------------+ - - -
    |                   |
    ~    Payload        ~
    |                   |
     -------------------

           Figure 3: The MPLS SFC Label Stack for Label Stacking

2.

> draft-xu-clad-spring-sr-service-chaining unrolls the path and explicitly
calls out each hop
> and each function into the label stack.

That is precisely what draft-ietf-mpls-sfc also does as far as SF's are
concerned.

Other network elements which do not participate in SFs are not aware of
service function states and all they are doing is transporting mpls packets
to and between SFs. Both drafts are identical here.

What differences in network state do you see in transit nodes ? With that
please keep in mind that LDP's network state with locally significant
labels is far greater then SR network state with global/domain wide labels.

Last the core of the comments where focused on using NSH and not to make
any judgement which way of producing alternatives to it is better/worse.

Best,
R.

On Thu, Apr 12, 2018 at 5:04 PM, Stewart Bryant <[email-masked]>
wrote:

>
> Rather than have a process discussion, I think we should go up a level and
> better understand the technical differences between the two drafts.
>
> that mirrors the SFC approach that allows a short indication of potentially
> re-entrant chains. In its simplest form it uses a compact MPLS stack to
> describe an arbitarily complex path that is compatile with simple edge
> routers which are often challenged in terms of the number of labels that
> they can push.
>
> calls out each hop and each function into the label stack. This results in
> a much larger MPLS label stack that will challenge some edge routers. The
> way that we generally deal with imposition limits is through the use of
> binding-SIDs, which in the limiting case resolves to the approach in
> draft-farrel with the limitation that the position on the path is implicit
> in the label stack size rather than explicitly specified by the SI.
>
> forwarding stack, and the long stack is the price that draft-xu-clad pays
> for the reduction in forwarding state.
>
> network and operational factors, so much so, that don't think it is wise to
> rule either out of scope at this stage.
>
> section 7 of the draft. This allows the construction of SFCs that are the
> concatination of two or more compacted sub-chains. This allows the operator
> to deploy a solution with the advantages of draft-farrel together with some
> of the flexibility of draft-xu-clad.
>
> need to proceed with both at least to the point where we fully understand
> the detailed consequences of the two approachs and the scenarios where each
> finds it's niche.
>
> network requirements, we can move the drafts to the appropriate IETF track.
> Such tracks may be anything from abandonment to IETF standard for one or
> both of these approaches.
>
> understanding of the technology and how each might make the Internet work
> better,  rather than spending effort on arguing about IETF process.
>
> - Stewart
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Apr 2018 18:05:31 +0200

Hi Robert,

> What exactly is "compact" in MPLS label stack as defined in 

I was talking about the lable swapping method in Section 5.

The section 6 text below makes sense when you need to concatinate a 
number of tuples. Obviously there comes a point where optimum stack size 
swaps from one design to the other. That is why I don't want to make a 
choice without understanding the properties and operational considerations.

> > draft-xu-clad-spring-sr-service-chaining unrolls the path and 
> explicitly calls out each hop
> That is precisely what draft-ietf-mpls-sfc also does as far as SF's 
> are concerned.

No, it has two modes, each with different properties, and these have 
different properties from draft-xu-clad.

>
> Other network elements which do not participate in SFs are not aware 
> of service function states and all they are doing is transporting mpls 
> packets to and between SFs. Both drafts are identical here.
>
> What differences in network state do you see in transit nodes ? With 
> that please keep in mind that LDP's network state with locally 
> significant labels is far greater then SR network state with 
> global/domain wide labels.

Are well, there is the whole question of whether nodal labels in the IGP 
is SR or MPLS. My understanding of the archaeology of MPLS is that 
putting such labels in the IGP was the original design choice, but this 
was abandoned in favour of more expeditious deployment ... but we digress.

You base question is however more complex than it seems on the surface. 
NP memory state is enormously more expensive ($$$) than route processor 
state. SR pushes that expensive state to the most cost sensitive 
components in the network (the ingress routers). The payback is a 
reduction in path state in the core. On the otherhand binding SIDs add 
back that state. So this question can only be adresssed in the wider 
contest of the network topology, the application set, the implementation 
constraints and the set of SR features needed.

>
> Last the core of the comments where focused on using NSH and not to 
> make any judgement which way of producing alternatives to it is 
> better/worse.

If you have end to end NSH, then use it. Both of these drafts focus on 
what to do if you do not have end to end  NSH technology available.

- Stewart

>
> Best,
> R.
>
>
> On Thu, Apr 12, 2018 at 5:04 PM, Stewart Bryant 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Rather than have a process discussion, I think we should go up a
>     level and better understand the technical differences between the
>     two drafts.
>
>     draft-farrel-mpls-sfc describes the actions at a hop in terms of a
>     tuple that mirrors the SFC approach that allows a short indication
>     of potentially re-entrant chains. In its simplest form it uses a
>     compact MPLS stack to describe an arbitarily complex path that is
>     compatile with simple edge routers which are often challenged in
>     terms of the number of labels that they can push.
>
>     draft-xu-clad-spring-sr-service-chaining unrolls the path and
>     explicitly calls out each hop and each function into the label
>     stack. This results in a much larger MPLS label stack that will
>     challenge some edge routers. The way that we generally deal with
>     imposition limits is through the use of binding-SIDs, which in the
>     limiting case resolves to the approach in draft-farrel with the
>     limitation that the position on the path is implicit in the label
>     stack size rather than explicitly specified by the SI.
>
>     The short stack in draft-farrel comes at the cost of greater
>     network forwarding stack, and the long stack is the price that
>     draft-xu-clad pays for the reduction in forwarding state.
>
>     The optimal design point between forwarding and control plane
>     state is something that is dependent on many parameters, and is
>     dependent on many network and operational factors, so much so,
>     that don't think it is wise to rule either out of scope at this stage.
>
>     The hybrid mode in section 6 of draft-farrel supports the mixed
>     mode in section 7 of the draft. This allows the construction of
>     SFCs that are the concatination of two or more compacted
>     sub-chains. This allows the operator to deploy a solution with the
>     advantages of draft-farrel together with some of the flexibility
>     of draft-xu-clad.
>
>     At this stage the two drafts are sufficienly different that I
>     think we need to proceed with both at least to the point where we
>     fully understand the detailed consequences of the two approachs
>     and the scenarios where each finds it's niche.
>
>     After developing a better understanding the detail of each design,
>     their control plane, and operational contexts and how each maps to
>     customer network requirements, we can move the drafts to the
>     appropriate IETF track. Such tracks may be anything from
>     abandonment to IETF standard for one or both of these approaches.
>
>     understanding of the technology and how each might make the
>     Internet work better,  rather than spending effort on arguing
>     about IETF process.
>
>     - Stewart
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Apr 2018 18:18:06 +0200

> state.

​100% agree. ​

SR pushes that expensive state to the most cost sensitive components in the
> network (the ingress routers). The payback is a reduction in path state in
> the core.
>

​So to be practical let's face the question how many services will be
traversed ? 1 ? 2 ? 3 ? Is this so much to worry about as far as transport
state is concerned in ingress node ? ​Keep in mind that with current
technology ingress may actually (and very often will be) the host not the
router for SRH insertion (especially in v6 deployments).

​In draft-ietf-mpls-sfc you may "win" the less state on the ingress, but
you loose big time as now SF need to know where to forward given packet
further by properly setting the outermost transport label ​after N-th SF
processing. Clearly you need good control plane assist for it. IMO so much
for big savings ... Opex complexity increases exponentially when you start
to troubleshoot it.
​​

> what to do if you do not have end to end  NSH technology available.

​It would be very helpful to say so in this draft in bold :). ​

Anyhow worse things get standardized these days so consider this to be my
last note on that one ....

Cheers,
R.

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 13 Apr 2018 09:35:01 +0800

Hi Stewart,
If draft-farrel* was just describing an MPLS-based SFC technology that is different from the MPLS-SR-based SFC technology that has been described in draft-xuclad*, that would be fine. However, draft-farrel* also described the technology that has been described in draft-xuclad* (see section 6) by "using a different name for the same thing". Note that the title of section 6 in those pervious versions of draft-farrel* is "MPLS Segment Routing". One co-author of draft-farrel* said they worked very hard to change the "Segment Routing" term to "label stack" term in the new version of draft-farrel* in order to deal with the overlapping issue. However, such change is just "using a different name for the same thing", and it doesn't solve the overlapping issue at all, as had been pointed out by many people. As said by one co-author of draft-farrel*, in a thread which is irrelavant to this overlapping issue, "using a different name for the same thing is not so clever:)". In fact, it would cause unneccessary confusions to implementors by describing the same technology within different drafts. More badly, it would set a bad precedant in the IETF of copying the idea of the existing draft by "using a different name for the same thing".
Best regards,
Xiaohu------------------------------------------------------------------Stewart Bryant <[email-masked]>2018年4月12日(星期四) 23:04"Bernier, Daniel" <[email-masked]>; Robert Raszuk <[email-masked]>[email-masked] <[email-masked]>; [email-masked] <[email-masked]>Re: [mpls] [sfc]  Working Group adoption of draft-farrel-mpls-sfc

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Apr 2018 07:27:30 +0200

Hi Xiaohu

What an earlier version of the draft said is of no importance. What it says going forward is what counts.

Perhaps the way to address your concern is to include some text of the form that I used in my email of yesterday to describe to the reader the difference in approach. This is consistent with earlier advice in this discussion to reference the work from which this forked.

- Stewart

Sent from my iPad

> On 13 Apr 2018, at 03:35, 徐小虎(义先) <[email-masked]> wrote:
> 
> Hi Stewart,
> 
> If draft-farrel* was just describing an MPLS-based SFC technology that is different from the MPLS-SR-based SFC technology that has been described in draft-xuclad*, that would be fine. However, draft-farrel* also described the technology that has been described in draft-xuclad* (see section 6) by "using a different name for the same thing". Note that the title of section 6 in those pervious versions of draft-farrel* is 
> "MPLS Segment Routing". One co-author of draft-farrel* said they worked very hard to change the "Segment Routing" term to "label stack" term in the new version of draft-farrel* in order to deal with the overlapping issue. However, such change is just "using a different name for the same thing", and it doesn't solve the overlapping issue at all, as had been pointed out by many people. As said by one co-author of draft-farrel*, in a thread which is irrelavant to this overlapping issue, "using a different name for the same thing is not so clever:)". In fact, it would cause unneccessary confusions to implementors by describing the same technology within different drafts. More badly, it would set a bad precedant in the IETF of copying the idea of the existing draft by "using a different name for the same thing".
> 
> Best regards,
> Xiaohu
> Stewart Bryant <[email-masked]>
> 2018年4月12日(星期四) 23:04
> "Bernier, Daniel" <[email-masked]>; Robert Raszuk <[email-masked]>
> [email-masked] <[email-masked]>; [email-masked] <[email-masked]>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 13 Apr 2018 14:23:11 +0800

Hi Stewart,
Thanks for your response. For the SR-based SFC mechanism that has been described in draft-xuclad*, it's not helpful to describe it again in another draft. The most simple and efficient way to address the overlapping issue is to reference draft-xuclad* rather than "using a different name for the same thing". I'm looking forward to seeing the revision of draft-farrel* that would address the overlapping issue concretely.
If co-authors of draft-farrel* believed the current text as described in draft-xuclad* is not good enough or misses something important, any comments and suggestions are more than welcome.
Best regards,Xiaohu------------------------------------------------------------------Stewart Bryant <[email-masked]>2018年4月13日(星期五) 13:27徐小虎(义先) <[email-masked]>mpls <[email-masked]>; "Bernier, Daniel" <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>Re: [mpls] [sfc]  Working Group adoption of draft-farrel-mpls-sfc
Hi Xiaohu
What an earlier version of the draft said is of no importance. What it says going forward is what counts.
Perhaps the way to address your concern is to include some text of the form that I used in my email of yesterday to describe to the reader the difference in approach. This is consistent with earlier advice in this discussion to reference the work from which this forked.
- Stewart

Sent from my iPad

Hi Stewart,

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Apr 2018 09:10:13 +0200

On 13/04/2018 08:23, 徐小虎(义先) wrote:
> Hi Stewart,
>
> Thanks for your response. For the SR-based SFC mechanism that has been 
> described in draft-xuclad*, it's not helpful to describe it again in 
> another draft. The most simple and efficient way to address the 
> overlapping issue is to reference draft-xuclad* rather 
> than"using a different name for the same thing". I'm looking forward 
> to seeing the revision of draft-farrel* that would address the 
> overlapping issue concretely.

Please read what I said.

There are subtle but important technical differences between the two 
approaches.

- Stewart

>
> If co-authors of draft-farrel* believed the current text as described 
> in draft-xuclad* is not good enough or misses something important, any 
> comments and suggestions are more than welcome.

I will send you some text to include in draft-xuclad that points to the 
important differences in the approach taken in draft-farrel. This will 
clarify the issue to the reader.

I hope that this is an acceptable resolution of this issue.

- Stewart

>     2018年4月13日(星期五) 13:27
>     徐小虎(义先) <[email-masked]>
>     mpls <[email-masked]>; "Bernier, Daniel"
>     <[email-masked]>; Robert Raszuk <[email-masked]>;
>     What an earlier version of the draft said is of no importance.
>     What it says going forward is what counts.
>
>     Perhaps the way to address your concern is to include some text of
>     the form that I used in my email of yesterday to describe to the
>     reader the difference in approach. This is consistent with earlier
>     advice in this discussion to reference the work from which this
>     forked.
>
>     - Stewart
>
>
>
>     Sent from my iPad
>
>     On 13 Apr 2018, at 03:35, 徐小虎(义先) <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     Hi Stewart,
>
>     If draft-farrel* was just describing an MPLS-based SFC technology
>     that is different from the MPLS-SR-based SFC technology that has
>     been described in draft-xuclad*, that would be fine. However,
>     draft-farrel* also described the technology that has been
>     described in draft-xuclad* (see section 6) by
>     "using a different name for the same thing". Note that the title
>     of section 6 in those pervious versions of draft-farrel* is
>
>     "MPLS Segment Routing". One co-author of draft-farrel* said they worked very hard to change the "Segment Routing" term to "label stack" term in the new version of draft-farrel* in order to deal with the overlapping issue. However, such change is just"using a different name for the same thing", and it doesn't solve
>     the overlapping issue at all, as had been pointed out by many people. As said by one co-author of draft-farrel*, in a thread which is irrelavant to this overlapping issue,"using a different name for the same thing is not so clever:)". In
>     fact, it would cause unneccessary confusions to implementors by
>     describing the same technology within different drafts. More
>     badly, it would set a bad precedant in the IETF of copying the
>     idea of the existing draft by
>     "using a different name for the same thing".
>
>
>     Best regards,
>     Xiaohu
>     Stewart Bryant <[email-masked]
>     <mailto:[email-masked]>>
>     2018年4月12日(星期四) 23:04
>     "Bernier, Daniel" <[email-masked]
>     <mailto:[email-masked]>>; Robert Raszuk <[email-masked]
>     <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>     <[email-masked] <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sun, 15 Apr 2018 04:44:09 +0000

Dear Stewart, WG Chairs and the WG,

I do not agree with Stewart’s points and will response in a separate email. But all that is just noise and that cannot resolve the issue at hand.

A countless time, Xiaohu has raised the issue that the intellectual property for the contents in section 6 of draft-farrel-mpls-sfc belongs to draft-xu-mpls-service-chaining. Please see one of Xiaohu's recent emails with the subject "[spring] For the fairness and justice of the IETF culture" dated Thursday, April 5, 2018 at 12:34 AM, copied in the following.

This issue was also raised by many during the WG adoption poll of the document. The chairs adopted the work with the promise of fixing the issue. Specifically, in the email to announce the adoption of the ID to the WG, the chair(s) mentioned the following:

"That decision is taken, the issues that has been pointed out are
noted. These issues need to be resolved on the mailing list and
rough consensus need to be reached for text changes in the document.
Actually the members of the working group have much more influence on
a working group document, than on an individual draft.
It would be far better if we now focused on proposing text changes,
rather than discussing processes."

This is a serious issue; we need to remove section 6 from draft- farrel-mpls-sfc to move forward. These contents will proceed in draft-xu*, where the contents started initially. Everyone will have a fair chance to contribute to the contents as part of collaborations on draft-xu*.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of "徐小虎(义先)" <[email-masked]>
Date: Thursday, April 5, 2018 at 12:34 AM
To: "[email-masked]" <[email-masked]>, SPRING WG List <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [spring] For the fairness and justice of the IETF culture//Re: [mpls] What to do with draft-ietf-mpls-sfc-00.txt

Hi all,

As I had pointed out before, this draft describes two MPLS-based SFC
approaches: one is how to encode the NSH info, more specifically, the SPI
and SI info by two MPLS labels, which is still a stateful SFC mechanism
just like NSH; another is how to leverage the MPLS-SR to realize a
stateless SFC (see section 6).

It has been pointed out by many people that section 6 of the draft copies
the
idea of (https://tools.ietf.org/html/draft-xu-mpls-service-chaining)
without any technology contribution except replacing “MPLS Segment
Routing” by “Label Stack”. Funnily, one author of draft-ietf-mpls-sfc
had inadvertently admitted
"using a different name for the same thing is not so clever" (see
https://mailarchive.ietf.org/arch/msg/mpls/y7FTc38ysVf6PyJlA04MEFSN9nc) in
another thread.

IMHO, the indulgence towards such behavior of copying
ideas of existing drafts with word tricks would seriously trample
underfoot the fairness and justice of the IETF culture. At least, it would
badly damage the interest and enthusiasm of IETF participants, especially
newcomers and non-native speakers of English.

Best regards,
Xiaohu

From: mpls <[email-masked]> on behalf of Stewart Bryant <[email-masked]>
Date: Friday, April 13, 2018 at 3:10 AM
To: "徐小虎(义先)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, mpls <[email-masked]>, Robert Raszuk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc

Please read what I said.

There are subtle but important technical differences between the two approaches.

- Stewart

I will send you some text to include in draft-xuclad that points to the important differences in the approach taken in draft-farrel. This will clarify the issue to the reader.

- Stewart

Best regards,
Xiaohu
------------------------------------------------------------------
Stewart Bryant <[email-masked]><mailto:[email-masked]>
2018年4月13日(星期五) 13:27
徐小虎(义先) <[email-masked]><mailto:[email-masked]>
mpls <[email-masked]><mailto:[email-masked]>; "Bernier, Daniel" <[email-masked]><mailto:[email-masked]>; Robert Raszuk <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc

Hi Xiaohu

- Stewart

Sent from my iPad

On 13 Apr 2018, at 03:35, 徐小虎(义先) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stewart,

Best regards,
Xiaohu
------------------------------------------------------------------
Stewart Bryant <[email-masked]<mailto:[email-masked]>>
2018年4月12日(星期四) 23:04
"Bernier, Daniel" <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc

- Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 15 Apr 2018 10:55:55 -0400

Zafar, et al,

Perhaps the fairest to all concerned is for the MPLS WG to adopt both
drafts, and then it will be up to the WG (rather than the authors) to best
determine the technical details going forward, and how best to document
them. That way the work becomes the consensus product of the WG.

Cheers,
Andy

On Sun, Apr 15, 2018 at 12:44 AM, Zafar Ali (zali) <[email-masked]> wrote:

> I do not agree with Stewart’s points and will response in a separate
> email. But all that is just noise and that cannot resolve the issue at
> hand.
>
>
>
> A countless time, Xiaohu has raised the issue that the intellectual
> property for the contents in section 6 of draft-farrel-mpls-sfc belongs to
> draft-xu-mpls-service-chaining. Please see one of Xiaohu's recent emails
> with the subject *"[spring] For the fairness and justice of the IETF
> culture"* dated Thursday, April 5, 2018 at 12:34 AM, copied in the
> following.
>
>
>
> This issue was also raised by many during the WG adoption poll of the
> document. The chairs adopted the work with the promise of fixing the issue.
> Specifically, in the email to announce the adoption of the ID to the WG,
> the chair(s) mentioned the following:
>
>
>
> This is a serious issue; we need to remove section 6 from draft-
> farrel-mpls-sfc to move forward. These contents will proceed in draft-xu*,
> where the contents started initially. Everyone will have a fair chance to
> contribute to the contents as part of collaborations on draft-xu*.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *spring <[email-masked]> on behalf of "徐小虎(义先)" <
> [email-masked]>
> *Date: *Thursday, April 5, 2018 at 12:34 AM
> *To: *"[email-masked]" <[email-masked]>, SPRING WG List <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *[spring] For the fairness and justice of the IETF culture//Re:
> [mpls] What to do with draft-ietf-mpls-sfc-00.txt
>
>
>
> Hi all,
>
>
>
> *From: *mpls <[email-masked]> on behalf of Stewart Bryant <
> [email-masked]>
> *Date: *Friday, April 13, 2018 at 3:10 AM
> *To: *"徐小虎(义先)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, mpls <[email-masked]>,
> Robert Raszuk <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [mpls] [sfc] Working Group adoption of
> draft-farrel-mpls-sfc
>
>
>
>
>
>
>
> overlapping issue is to reference draft-xuclad* rather than
> "using a different name for the same thing". I'm looking forward to
> seeing the revision of draft-farrel* that would address the overlapping
> issue concretely.
>
>
> Please read what I said.
>
> If co-authors of draft-farrel* believed the current text as described in
> draft-xuclad* is not good enough or misses something important, any
> Stewart Bryant <[email-masked]> <[email-masked]>
>
> 2018年4月13日(星期五) 13:27
>
> 徐小虎(义先) <[email-masked]> <[email-masked]>
>
> mpls <[email-masked]> <[email-masked]>; "Bernier, Daniel"
> <[email-masked]> <[email-masked]>; Robert Raszuk
> <[email-masked]> <[email-masked]>; [email-masked] <[email-masked]>
> <[email-masked]>; [email-masked] <[email-masked]> <[email-masked]>
>
> Perhaps the way to address your concern is to include some text of the
> form that I used in my email of yesterday to describe to the reader the
> difference in approach. This is consistent with earlier advice in this
> discussion to reference the work from which this forked.
>
>
>
> - Stewart
>
>
>
>
>
> Sent from my iPad
>
>
> If draft-farrel* was just describing an MPLS-based SFC technology that is
> different from the MPLS-SR-based SFC technology that has been described in
> draft-xuclad*, that would be fine. However, draft-farrel* also described
> the technology that has been described in draft-xuclad* (see section 6) by
> "using a different name for the same thing". Note that the title of
> section 6 in those pervious versions of draft-farrel* is
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 17 Apr 2018 07:49:10 -0400

To be completely clear, the two drafts I was referring to in my email below
are draft-xuclad-spring-sr-service-chaining-01 and draft-ietf-mpls-sfc-00.

Cheers,
Andy

---

From: Adrian Farrel <[email-masked]>
Date: Mon, 23 Apr 2018 12:14:44 +0000

Hi Zafar,

Thank you for the comments.  We are not aware that any IPR has been disclosed in relation to any of the relevant drafts.  If there are such IPR issues, we encourage them to be disclosed in accordance with the IETF policy.  In the meantime, we believe our draft remains appropriate and do not agree that Section 6 should be removed.

Thanks,
Adrian

From: mpls [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: 15 April 2018 05:44
To: Stewart Bryant; 徐小虎 (义先)
Cc: [email-masked]<mailto:[email-masked]>; SPRING WG List; Robert Raszuk; [email-masked]<mailto:[email-masked]>; mpls
Subject: Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc

Thanks

Regards … Zafar