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

["Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>]

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" <[e-mail]>
Date: Thursday, 29 March 2018 at 22:03
To: Robert Raszuk <[e-mail]>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>, "[e-mail]" <[e-mail]>, "徐小虎(义先)" <[e-mail]>, "[e-mail]" <[e-mail]>, draft-farrel-mpls-sfc <[e-mail]>, "[e-mail]" <[e-mail]>, mpls <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Thursday, March 29, 2018 3:12 PM
To: BRUNGARD, DEBORAH A <[e-mail]>
Cc: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>; [e-mail]; 徐小虎(义先) <[e-mail]>; [e-mail]; draft-farrel-mpls-sfc <[e-mail]>; [e-mail]; mpls <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Robert Raszuk
Sent: Thursday, March 29, 2018 8:06 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; 徐小虎(义先) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; draft-farrel-mpls-sfc <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; mpls <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of 徐小虎(义先) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 28, 2018 10:17:04 AM
To: mpls; [e-mail]<mailto:[e-mail]>
Cc: draft-farrel-mpls-sfc; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
2018年3月28日(星期三) 15:56
[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
draft-farrel-mpls-sfc <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
[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: [e-mail]<mailto:[e-mail]>
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]

_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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=>