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

From: Loa Andersson <[email-masked]>
Date: Wed, 28 Mar 2018 09:55:42 +0200

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]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 28 Mar 2018 16:17:04 +0800

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) 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 (note that this draft has been merged into https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00), 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]>2018年3月28日(星期三) 15:[email-masked] <[email-masked]>draft-farrel-mpls-sfc <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>[mpls] Working Group adoption of draft-farrel-mpls-sfc
Working Group,

/Loa
for the MPLS wg chairs

-- 

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 28 Mar 2018 08:25:35 +0000

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

Hi Loa,

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

Working Group,

/Loa
for the MPLS wg chairs

--

---

From: "Chengli (IP Technology Research)" <[email-masked]>
Date: Thu, 29 Mar 2018 11:59:26 +0000

I just reviewed the latest version,  it seems the content of section 6 is almost the same as version-04.

This overlaps with draft-xuclad-spring-sr-service-chaining, IMHO. 

It seems a little bit early to adopt this version before the conflictions addressed. 
 
BR,
Cheng

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Wednesday, March 28, 2018 3:56 PM
To: [email-masked]
Cc: draft-farrel-mpls-sfc <[email-masked]>; [email-masked]; [email-masked]
Subject: [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

--

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Mar 2018 14:05:50 +0200

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]> 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]> on behalf of 徐小虎(义先) <
> [email-masked]>
> *Sent:* Wednesday, March 28, 2018 10:17:04 AM
> *To:* mpls; [email-masked]
> *Cc:* draft-farrel-mpls-sfc; [email-masked]; [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) 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 (note that this draft has been merged into
> https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00),
> as had been pointed by many people before.
>
> draft-farrel-mpls-sfc <[email-masked]>; [email-masked] <
> [email-masked]>; [email-masked] <[email-masked]>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 29 Mar 2018 18:57:55 +0000

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]] On Behalf Of Robert Raszuk
Sent: Thursday, March 29, 2018 8:06 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
Cc: [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

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.

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

_______________________________________________
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=>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Mar 2018 21:11:59 +0200

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]> 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]] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, March 29, 2018 8:06 AM
> *To:* Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
> *Cc:* [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
>
>
>
> Hey Wim,
>
>
>
> 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
> 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=>),
> <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://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: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 29 Mar 2018 20:03:23 +0000

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,

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,

Best,
R.

From iPhone

Hi Loa,

Xiaohu

Working Group,

/Loa
for the MPLS wg chairs

--

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 30 Mar 2018 09:42:02 +0800

Hi Deborah and Martin,
draft-farrel* currently describes two SFC approaches : one is to encode the NSH info, more specifically, the SPI and SI info into two MPLS labels which is a stateful SFC approach just like NSH, another is to leverage the SR, most specifically MPLS-SR to realize a stateless SFC approach (see section 6). 
I wonder whether the former approach or both approaches should be pursued in the MPLS WG from your points of view as ADs.
BTW, as has been pointed out by many people before, the latter has overlapping with the approach as has been described in https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03 (Note that this draft has been proposed many years before and now it has been merged into https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00 which includes both MPLS-SR-based and SRv6-based SFC approaches). Fortunately, some author of draft-farrel* has acknoledged this overlapping issue indirectly in his previous email. Unfortunately, the current modifcation of section 6 DOES NOT solve the overlapping issue at all. 
Best regards,Xiaohu
------------------------------------------------------------------BRUNGARD, DEBORAH A <[email-masked]>2018年3月30日(星期五) 02:58Robert Raszuk <[email-masked]>; "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]>RE: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc
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]] On Behalf Of
Robert Raszuk
Sent: Thursday, March 29, 2018 8:06 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
Cc: [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 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]> 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 iPhoneFrom: mpls <[email-masked]> on behalf of
徐小虎(义先) <[email-masked]>
Sent: Wednesday, March 28, 2018 10:17:04 AM
To: mpls; [email-masked]
Cc: draft-farrel-mpls-sfc; 
[email-masked]; [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)
 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 (note
 that this draft has been merged into https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00),
 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]>2018年3月28日(星期三)
 15:[email-masked] <[email-masked]>draft-farrel-mpls-sfc <[email-masked]>;
[email-masked] <[email-masked]>;
[email-masked] <[email-masked]>[mpls] Working Group adoption of draft-farrel-mpls-sfc Working Group,

/Loa

for the MPLS wg chairs

-- 

Senior MPLS Expert

mpls mailing list
[email-masked]

mpls mailing list
[email-masked]

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 30 Mar 2018 04:37:53 +0000

Deborah, this draft does not address brownfield deployments as the draft tries to indicate/outline. You need to do support at min. 2 extra labels (for non SR) and most brownfield routers will have issues with it, 2nd you will require all SF(s) to be understanding this encapsulation which will not happen anytime soon (the draft explains a proxy but this is expensive and should be avoided in SFC), 3rd the meta data has major issues  and is not in-line with main data-stream, 4th it is yet another data-plane given the other 3 points this doesn’t make sense. If IETF just tries to standardize everyone comes up with we fail to give the right industry direction and people will ignore the work that is being done in IETF.

So again this is not a solution for brownfield as people try to pretend. I really fail to understand the process here.

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,

Thanks,
Deborah

Dear Deborah,

Kind regards,
Robert.

Thanks,
Deborah

Hey Wim,

Best,
R.

From iPhone

Hi Loa,

Xiaohu

Working Group,

/Loa
for the MPLS wg chairs

--

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 30 Mar 2018 18:59:27 +0000

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

Hi Robert,

Thanks,
Deborah

Dear Deborah,

Kind regards,
Robert.

Thanks,
Deborah

Hey Wim,

Best,
R.

From iPhone

Hi Loa,

Xiaohu

Working Group,

/Loa
for the MPLS wg chairs

--

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 30 Mar 2018 20:40:18 +0000

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]> on behalf of "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Friday, March 30, 2018 at 2:59 PM
To: "BRUNGARD, DEBORAH A" <[email-masked]>, Robert Raszuk <[email-masked]>
Cc: "[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

Deborah,

Cheers,
Wim

Hi Robert,

Thanks,
Deborah

Dear Deborah,

Kind regards,
Robert.

Thanks,
Deborah

Hey Wim,

Best,
R.

From iPhone

Hi Loa,

Xiaohu

Working Group,

/Loa
for the MPLS wg chairs

--

---

From: "徐小虎(义先)" <[email-masked]>
Date: Sat, 31 Mar 2018 06:36:27 +0800

Hi all,

I fully agree with Zafar's and Wim's suggestions.

Best regards,
Xiaohu 

来自钉钉专属商务邮箱------------------------------------------------------------------发件人：Zafar Ali (zali)<[email-masked]>日　期：2018年03月31日 04:40:18收件人：Henderickx, Wim (Nokia - BE/Antwerp)<[email-masked]>; BRUNGARD, DEBORAH A<[email-masked]>; Robert Raszuk<[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]>主　题：Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}

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

Cc: "[email-masked]" <[email-masked]>, "徐小虎(义先)"
 <[email-masked]>, "[email-masked]" <[email-masked]>, draft-farrel-mpls-sfc <[email-masked]>, "[email-masked]" <[email-masked]>, mpls <[email-masked]>

 

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.

Cheers,
Wim

From:
"BRUNGARD, DEBORAH A" <[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]>

 

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.

Thanks,
Deborah
 
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert Raszuk

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

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]>
 wrote:

Hi,

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.

Thanks,

Deborah

From: sfc [mailto:[email-masked]]
On Behalf Of Robert Raszuk

Cc: [email-masked];
徐小虎(义先)
 <[email-masked]>;
[email-masked]; draft-farrel-mpls-sfc <[email-masked]>;
[email-masked]; mpls <[email-masked]>

 

Hey Wim,

 

 

 

Best,

R.

 

On Wed, Mar 28, 2018 at 10:25 AM, Henderickx, Wim (Nokia - BE/Antwerp) <[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]>
 on behalf of 徐小虎(义先)
 <[email-masked]>

To: mpls; [email-masked]

Cc: draft-farrel-mpls-sfc; [email-masked];
[email-masked]

 

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)
 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 (note
 that this draft has been merged into https://tools.ietf.org/html/draft-xu-clad-spring-sr-service-chaining-00),
 as had been pointed by many people before.

 

Xiaohu

2018年3月28日(星期三)
 15:56

[email-masked]
 <[email-masked]>

[email-masked]
 <[email-masked]>;
[email-masked]
 <[email-masked]>

 

Working Group,

/Loa

for the MPLS wg chairs

-- 

Senior MPLS Expert

mpls mailing list

[email-masked]

mpls mailing list

[email-masked]

---

From: "Bernier, Daniel" <[email-masked]>
Date: Sun, 1 Apr 2018 03:50:45 +0000

+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: sfc <[email-masked]> on behalf of Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
Sent: Friday, March 30, 2018 2:59 PM
To: BRUNGARD, DEBORAH A; Robert Raszuk
Cc: [email-masked]; 徐小虎(义先); [email-masked]; draft-farrel-mpls-sfc; [email-masked]; mpls
Subject: Re: [sfc] [mpls] Working Group adoption of draft-farrel-mpls-sfc

Deborah,

Cheers,
Wim

Hi Robert,

Thanks,
Deborah

Dear Deborah,

Kind regards,
Robert.

Thanks,
Deborah

Hey Wim,

Best,
R.

From iPhone

Hi Loa,

Xiaohu

Working Group,

/Loa
for the MPLS wg chairs

--