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

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 9 Mar 2018 00:02:14 +0000

Dear MPLS WG Chairs and the authors of draft-farrel-mpls-sfc,

I would like to draw your attention to the serious issue raised by Xiaohu and Francois.

Summary:

Please note that this working group adaption against the IETF process and its spirit. Please recall the adaption call.

Details:

Just to reiterate the issue raised by Xiaohu and Francois. At last IETF we discussed 3 drafts (draft-xu-mpls-service-chaining-03, draft-farrel-mpls-sfc and draft-clad-spring-segment-routing-service-chaining) in SFC, Spring and MPLS WG. There was the specific conversation on which WG the work belongs, and the assumed follow-up was for the chairs and ADs to have the discussion on home for these drafts.

From IETF process viewpoint, this call for adaption is like putting the "cart ahead of the horse." MPLS WG comes last in the process after there is an agreement from Spring and SFC groups on the need for MPLS data plane changes proposed by the draft. I raised this point at the mic at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at the last stage in the process; expert to review this work does not sit in the MPLS WG.

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

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

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

In the light of the above, my request to the authors of draft-farrel and MPLS WG chairs to please do the right thing and recall this WG adaptation call.

Thanks

Regards ... Zafar

From: mpls <[email-masked]> on behalf of "Francois Clad (fclad)" <[email-masked]>
Date: Thursday, March 8, 2018 at 5:21 AM
To: "徐小虎(义先)" <[email-masked]>
Cc: draft-farrel-mpls-sfc <[email-masked]>, "[email-masked]" <[email-masked]>, SPRING WG List <[email-masked]>, mpls-chairs <[email-masked]>, mpls <[email-masked]>
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi Xiaohu, all,

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

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

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

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

On 7 Mar 2018, at 01:13, 徐小虎(义先) <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

As I had pointed out at the last IETF meeting, section 6 of this draft has an serious overlap with https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03 that has now been updated by https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01 with a merge with draft-clad-spring-segment-routing-service-chaining.

Hence, I'm very interesting to know the intention of such rewritting of a given mechanism that has been described in another draft. Is there any special nutrition?

Best regards,
Xiaohu
------------------------------------------------------------------
发件人：IETF Secretariat <[email-masked]<mailto:[email-masked]>>
发送时间：2018年3月6日(星期二) 22:09
收件人：draft-farrel-mpls-sfc <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; mpls-chairs <[email-masked]<mailto:[email-masked]>>
主　题：[mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

The MPLS WG has placed draft-farrel-mpls-sfc in state
Call For Adoption By WG Issued (entered by Loa Andersson)

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

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

---

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Fri, 9 Mar 2018 04:43:45 +0000

I second the concerns raised by Xiaohu, Francois, and Zafar.

From: mpls <[email-masked]> on behalf of "Zafar Ali (zali)" <[email-masked]>
Date: Thursday, March 8, 2018 at 7:02 PM
To: "Francois Clad (fclad)" <[email-masked]>, "徐小虎(义先)" <[email-masked]>
Cc: mpls <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, draft-farrel-mpls-sfc <[email-masked]>, mpls-chairs <[email-masked]>, mpls <[email-masked]>
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

---

From: Loa Andersson <[email-masked]>
Date: Fri, 9 Mar 2018 16:59:24 +0800

Zafar,

On 2018-03-09 08:02, Zafar Ali (zali) wrote:
> *Summary*:
> 
> Please note that this working group adaption against the IETF process 
> and its spirit. Please recall the adaption call.
> 

Interesting, can you point me to the RFC and text that we broke?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 9 Mar 2018 09:17:26 -0000

I, too, hope we can move to a technical discussion of the differences between the proposals and not spend time thrashing around in IETF politics. I'm sure the ADs will help us understand what is written in the various WG charters, so our best next step would be to read (you know, like all the words :-) what is in the drafts.
 
However, since Zafar ascribes to me something that I did not say and that is not recorded in the minutes, perhaps I can set that straight.
 
He said...
 
> From IETF process viewpoint, this call for adaption is like putting the "cart ahead of the horse."
> MPLS WG comes last in the process after there is an agreement from Spring and SFC groups
> on the need for MPLS data plane changes proposed by the draft. I raised this point at the mic
> at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at the last stage
> in the process; expert to review this work does not sit in the MPLS WG.
 
According to the minutes, Zafar said...
 
| Zafar Ali: before defining the solution, is this the right approach in SFC? Starting
| in MPLS WG is wrong thing to do.
 
And I responded...
 
| Adrian: This was already presented in SFC WG today.
 
In the SFC WG I said...
 
| - The draft discusses how MPLS can be used for SFC. It is being discussed in the
|    MPLS working group.
| - We are looking at environments in which deployed MPLS routers can be used
|    for creating an SFC, rather than using NSH.
 
If you want my opinion:
- The SFC WG is chartered to work on NSH only
- The MPLS WG is chartered to work on MPLS
- This draft asks for MPLS code points so can only be in MPLS
- This draft must be reviewed in SFC and SPRING as it progresses and
   certainly at WG last call
 
Adrian
 
From: mpls [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: 09 March 2018 00:02
To: Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; [email-masked]; draft-farrel-mpls-sfc; mpls-chairs; mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
Importance: High

 
Summary:

Details: 

 

 
 
Thanks
 
Regards ... Zafar

Hi Xiaohu, all,

 
On 7 Mar 2018, at 01:13, 徐小虎(义先) < <mailto:[email-masked]> [email-masked]> wrote:
 
Hi all, 
 
As I had pointed out at the last IETF meeting, section 6 of this draft has an serious overlap with  <https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03> https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03 that has now been updated by  <https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01> https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01 with a merge with draft-clad-spring-segment-routing-service-chaining.

Best regards,
Xiaohu
------------------------------------------------------------------
发件人：IETF Secretariat < <mailto:[email-masked]> [email-masked]>
发送时间：2018年3月6日(星期二) 22:09
收件人：draft-farrel-mpls-sfc < <mailto:[email-masked]> [email-masked]>; mpls < <mailto:[email-masked]> [email-masked]>; mpls-chairs < <mailto:[email-masked]> [email-masked]>
主　题：[mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

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

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

---

From: "Bernier, Daniel" <[email-masked]>
Date: Fri, 9 Mar 2018 05:14:58 +0000

​Hi,

As co-author of both initial draft-xu-mpls-service-chaining, draft-clad-spring-segment-routing-service-chaining and the merged draft-xuclad-spring-sr-service-chaining, I also have concerns about the current WG adoption process and haste.  I do hope we will be in a position to discuss in London, which is merely days away.

Thanks,

Daniel Bernier | Bell Canada​

________________________________
From: mpls <[email-masked]> on behalf of Kamran Raza (skraza) <[email-masked]>
Sent: Thursday, March 8, 2018 11:43 PM
To: Zafar Ali (zali); Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; [email-masked]; draft-farrel-mpls-sfc; mpls-chairs; mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Mar 2018 19:13:47 +0000

Daniel,

There work group adoption process started several months ago.  We asked Loa to initiate the process and he asked four members of the MPLS review team to review the draft, which they subsequently did, with all four indicating that they thought the draft should be adopted.  Then and only then did Loa initiate a poll for WG adoption on the MPLS mailing list.

I thought it might be useful for the author of the subject draft to share their perspective on the various drafts that have been mentioned on this thread.

From a technical perspective, the idea of using SR for service function chaining has been there since SR's advent, so any draft that talks about SFC using SR is not originating anything new. draft-xuclad-spring-sr-service-chaining clearly explains how SR can be used to steer packets between SFFs and cause them to be delivered to SFs. It may not be describing anything new or radical, but at the same time it may be a useful informational document for the SPRING working group.

The SFC working group may have an opinion on the use of the NSH as a metadata container in the MPLS-SR case, and may want to consider whether the draft is consistent with the SFC architecture.  E.g., it is not clear to me how SR can support branching, looping, and jumping which are a key element of the SFC architecture.

On the other hand, draft-farrel-mpls-sfc is about using the MPLS forwarding plane to achieve the forwarding behaviour defined in the SFC architecture. The principal use case for this draft is label swapping (which, as is noted in draft-xuclad-spring-sr-service-chaining, requires network state and so is not consistent with the SR architecture). However, since the MPLS data plane strives to be consistent across use cases, this draft also describes how one encoding can be applied to swapping or stacking, and we do see a use case where an arbitrary mix of label swapping and label stacking may be useful to allowing the ingress classifier to select specific SFFs along an SFP.

The IANA considerations sections give a good indication of where the drafts belong. draft-xuclad-spring-sr-service-chaining asks for allocations from the "Segment-routing with IPv6 dataplane (SRv6) Parameters"  registry: that registry has not been created yet, but is probably intended to be the registry discussed in draft-filsfils-spring-srv6-network-programming so the discussion would belong in SPRING. draft-farrel-mpls-sfc asks for allocations the "Special-Purpose Multiprotocol Label Switching (MPLS) Label Values" registry and that means it should be discussed in the MPLS WG.

In summary, when draft-xuclad-spring-sr-service-chaining references draft-farrel-mpls-sfc it says "This label stacking  (i.e., the SR approach described in draft-xuclad) is completely different from other proposals such as [RFC8300] and the MPLS label swapping mechanism described in [I-D.farrel-mpls-sfc]."

I agree with that statement and think each draft should progress at its own speed and in its own appropriate WG.

Yours Irrespectively,

John

From: Bernier, Daniel [mailto:[email-masked]]
Sent: Friday, March 9, 2018 12:15 AM
To: Kamran Raza (skraza) <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Francois Clad (fclad) <[email-masked]>; 徐小虎(义先) <[email-masked]>
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; draft-farrel-mpls-sfc <[email-masked]>; mpls-chairs <[email-masked]>; mpls <[email-masked]>
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

​Hi,

Thanks,

________________________________
From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of Kamran Raza (skraza) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 8, 2018 11:43 PM
To: Zafar Ali (zali); Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; [email-masked]<mailto:[email-masked]>; draft-farrel-mpls-sfc; mpls-chairs; mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 8, 2018 at 7:02 PM
To: "Francois Clad (fclad)" <[email-masked]<mailto:[email-masked]>>, "徐小虎(义先)" <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>, SPRING WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, draft-farrel-mpls-sfc <[email-masked]<mailto:[email-masked]>>, mpls-chairs <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Summary:

Details:

The drafts also did not stay dormant after IETF100. There were email conversations among the authors of the concerned drafts (https://mailarchive.ietf.org/arch/msg/mpls/bmH5QH65b2Non2Y7qNEBBI_kSOA<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_mpls_bmH5QH65b2Non2Y7qNEBBI-5FkSOA&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=VRZ07QBfjHv2WQ54Npi2jHbsARYMhnrPIeZQsybcv7U&s=zOxiFakxYXf_VFqS0zND68PwbDWDXD0AKG72-y84qbg&e=>).

Thanks

Regards ... Zafar

From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of "Francois Clad (fclad)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 8, 2018 at 5:21 AM
To: "徐小虎(义先)" <[email-masked]<mailto:[email-masked]>>
Cc: draft-farrel-mpls-sfc <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, SPRING WG List <[email-masked]<mailto:[email-masked]>>, mpls-chairs <[email-masked]<mailto:[email-masked]>>, mpls <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi Xiaohu, all,

Hi all,

As I had pointed out at the last IETF meeting, section 6 of this draft has an serious overlap with https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dmpls-2Dservice-2Dchaining-2D03&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=VRZ07QBfjHv2WQ54Npi2jHbsARYMhnrPIeZQsybcv7U&s=212moeSk18cZoEzJAI8TYXJcs7Wq9uQkz8PST4Tl2j4&e=> that has now been updated by https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxuclad-2Dspring-2Dsr-2Dservice-2Dchaining-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=VRZ07QBfjHv2WQ54Npi2jHbsARYMhnrPIeZQsybcv7U&s=6ldpZeey6POc2ikzxD8jx4vlJZLkBxlsPkqYSUAdCIo&e=> with a merge with draft-clad-spring-segment-routing-service-chaining.

Best regards,
Xiaohu

The document is available at
https://datatracker.ietf.org/doc/draft-farrel-mpls-sfc/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfarrel-2Dmpls-2Dsfc_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=VRZ07QBfjHv2WQ54Npi2jHbsARYMhnrPIeZQsybcv7U&s=DtXVvU8-bgvHWKUdxHIi5hfJE2iwwVIcN2voWs4DSss&e=>

[email-masked]<mailto:[email-masked]>

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Tue, 13 Mar 2018 18:27:03 +0000

Hi Adrian,

On 9 Mar 2018, at 10:17, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

I, too, hope we can move to a technical discussion of the differences between the proposals

The issue is that, from a technical point of view, there is no difference between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the solution that was originally documented in draft-xu-mpls-service-chaining, as Xiaohu pointed out several times.

Considering that draft-xu-mpls-service-chaining was submitted almost one year before draft-farrel-mpls-sfc, the MPLS Segment Routing approach described in section 6 of draft-farrel-mpls-sfc belongs in draft-xu-mpls-service-chaining, which is now draft-xuclad-spring-sr-service-chaining.

To be fair to draft-xu-mpls-service-chaining, I believe that draft-farrel-mpls-sfc should be re-spinned without section 6 before continuing towards WG adoption.

Thanks,
Francois

and not spend time thrashing around in IETF politics. I'm sure the ADs will help us understand what is written in the various WG charters, so our best next step would be to read (you know, like all the words :-) what is in the drafts.

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: James N Guichard <[email-masked]>
Date: Tue, 13 Mar 2018 18:59:36 +0000

Hi Francois,

One comment below ..

From: mpls [mailto:[email-masked]] On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: [email-masked]
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi Adrian,

Jim> as far as I can tell this is not exactly true.. draft-xu-mpls-service-chaining-00 talks about using an MPLS label to identify a service segment. Draft-farrel-mpls-sfc talks about using 2 labels, an SFC context label and an SF label, to essentially mimic NSH behavior. The authors of that draft even go as far as to say (about the context label) “.. using the semantics of the SPI is exactly as defined in [RFC8300]”  which is exactly what you state you don’t want to do in draft-xuclad-spring-sr-service-chaining. Therefore I am not sure how you can come to the conclusion that there is no difference between the two solutions.

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

---

From: John E Drake <[email-masked]>
Date: Tue, 13 Mar 2018 20:59:51 +0000

Jim,

Excellent point.  We thought a context label was crucial in order to achieve scalability (2**40) bits.  A single 20 bit globally unique SFI identifier didn’t seem to be practical to us.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Tuesday, March 13, 2018 3:00 PM
To: Francois Clad (fclad) <[email-masked]>; [email-masked]
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi Francois,

One comment below ..

From: mpls [mailto:[email-masked]] On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: [email-masked]<mailto:[email-masked]>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi Adrian,

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

The drafts also did not stay dormant after IETF100. There were email conversations among the authors of the concerned drafts (https://mailarchive.ietf.org/arch/msg/mpls/bmH5QH65b2Non2Y7qNEBBI_kSOA<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_mpls_bmH5QH65b2Non2Y7qNEBBI-5FkSOA&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=m-yc8M0wYF1jXzDEPWo3iUnoM43SPOpgJvQIpF6kYHA&e=>).

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

As I had pointed out at the last IETF meeting, section 6 of this draft has an serious overlap with https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dmpls-2Dservice-2Dchaining-2D03&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=UckZMQ6j33_dO8XnGXbarFxtcuHJrGDIsg2aAdG-sOk&e=> that has now been updated by https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxuclad-2Dspring-2Dsr-2Dservice-2Dchaining-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=EgLaNYJSlDEdK7n2o1EWQsLRHCJBnTmZM-HtaMLsMLc&e=> with a merge with draft-clad-spring-segment-routing-service-chaining.

Best regards,
Xiaohu

The document is available at
https://datatracker.ietf.org/doc/draft-farrel-mpls-sfc/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfarrel-2Dmpls-2Dsfc_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=eOBxho8eESw8vj3hUU0WF6BoW3Zu1CCi69KJRsBTt6k&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=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=Vy6H7zgumIaKzJb84UmsKCxcUsJYtXS_xqbcFgxdc3c&e=>
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=_74fpq8zHtLUzCRwAD_Doy3iW0OdJ5032fZhJGPgr-w&e=>

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sfc&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=nWWylOI0JVmT-t3N9mWaEFezzrqU6NxfM3FrKE3G0Pk&e=>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 13 Mar 2018 22:13:23 +0100

Hi John,

There is one point which I am missing in this discussion ... why we are
over and over duplicating ways to solve the same problem. Is there some
sort of starvation of the problems to be solved ? Or is there an issue of
"technology not invented here must be bad" ?

You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when
"to handle situations in which the NSH is not ubiquitously deployed." What
are those situations considering that MPLS requires IP both control plane
and forwarding to be in place so does NSH.

Would now all of the v-service vendors need to support both ways of
encoding service/function IDs ?

Isn't this waist of everyone's time and effort ?

Last - how does  draft-farrel-mpls-sfc works in only IPv6 IP networks ? Oh
maybe there is and not going to be such thing ?

Best,
Robert.

On Tue, Mar 13, 2018 at 9:59 PM, John E Drake <[email-masked]> wrote:

> Jim,
>
>
>
> Excellent point.  We thought a context label was crucial in order to
> achieve scalability (2**40) bits.  A single 20 bit globally unique SFI
> identifier didn’t seem to be practical to us.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* mpls [mailto:[email-masked]] *On Behalf Of *James N
> Guichard
> *Sent:* Tuesday, March 13, 2018 3:00 PM
> *To:* Francois Clad (fclad) <[email-masked]>; [email-masked]
>
> *Cc:* mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
> *Subject:* Re: [mpls] [sfc] [spring] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi Francois,
>
>
>
> One comment below ..
>
>
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Francois Clad (fclad)
> *Sent:* Tuesday, March 13, 2018 2:27 PM
> *To:* [email-masked]
> *Cc:* mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
> *Subject:* Re: [mpls] [sfc] [spring] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi Adrian,
>
>
>
> On 9 Mar 2018, at 10:17, Adrian Farrel <[email-masked]> wrote:
>
>
>
> The issue is that, from a technical point of view, there is no difference
> between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and
> the solution that was originally documented in draft-xu-mpls-service-chaining, as
> Xiaohu pointed out several times.
>
>
>
> Considering that draft-xu-mpls-service-chaining was submitted almost one
> year before draft-farrel-mpls-sfc, the MPLS Segment Routing approach
> described in section 6 of draft-farrel-mpls-sfc belongs in
> draft-xu-mpls-service-chaining, which is now draft-xuclad-spring-sr-
> service-chaining.
>
> To be fair to draft-xu-mpls-service-chaining, I believe that
> draft-farrel-mpls-sfc should be re-spinned without section 6 before
> continuing towards WG adoption.
>
> Thanks,
> Francois
>
>
>
>
>
> and not spend time thrashing around in IETF politics. I'm sure the ADs
> will help us understand what is written in the various WG charters, so our
> best next step would be to read (you know, like all the words :-) what is
> in the drafts.
>
>
>
> However, since Zafar ascribes to me something that I did not say and that
> is not recorded in the minutes, perhaps I can set that straight.
>
>
>
> He said...
>
>
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Zafar Ali (zali)
> *Sent:* 09 March 2018 00:02
> *To:* Francois Clad (fclad); 徐小虎(义先)
> *Cc:* mpls; SPRING WG List; [email-masked]; draft-farrel-mpls-sfc;
> mpls-chairs; mpls
> *Subject:* Re: [mpls] [spring] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
> *Importance:* High
>
>
>
> Please note that this working group adaption against the IETF process and
> its spirit. Please recall the adaption call.
>
>
>
> *Details*:
>
>
>
> Just to reiterate the issue raised by Xiaohu and Francois. At last IETF we
> discussed 3 drafts (draft-xu-mpls-service-chaining-03,
> draft-farrel-mpls-sfc and draft-clad-spring-segment-routing-service-chaining)
> in SFC, Spring and MPLS WG. There was the specific conversation on which WG
> the work belongs, and the assumed follow-up was for the chairs and ADs to
> have the discussion on home for these drafts.
>
>
>
> From IETF process viewpoint, this call for adaption is like putting the
> "cart ahead of the horse." MPLS WG comes last in the process after there is
> an agreement from Spring and SFC groups on the need for MPLS data plane
> changes proposed by the draft. I raised this point at the mic at SFC WG
> meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at the last
> stage in the process; expert to review this work does not sit in the MPLS
> WG.
>
>
>
> The drafts also did not stay dormant after IETF100. There were email
> conversations among the authors of the concerned drafts (
> https://mailarchive.ietf.org/arch/msg/mpls/bmH5QH65b2Non2Y7qNEBBI_kSOA
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_mpls_bmH5QH65b2Non2Y7qNEBBI-5FkSOA&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=m-yc8M0wYF1jXzDEPWo3iUnoM43SPOpgJvQIpF6kYHA&e=>
> ).
>
>
>
> Authors of draft-xu- and draft-clad- followed the proper IETF process,
> discussed and merged the contents. They published draft-xuclad-spring-sr-service-chaining-01
> and asked WG for a "presentation slot" at IETF100. Only to find that
> draft-farrel-mpls-sfc used a backdoor to force this "WG adaption call"!
>
>
>
> One also has to question the timing of this adaption call when the WGs are
> meeting face-to-face in a couple of weeks. Is it no longer IETF spirit to
> make use of the face-to-face to do the right thing, especially when we are
> meeting in two weeks?
>
>
>
> In the light of the above, my request to the authors of draft-farrel and
> MPLS WG chairs to please do the right thing and recall this WG adaptation
> call.
>
>
>
> Thanks
>
>
>
> Regards ... Zafar
>
>
>
>
>
> *From: *mpls <[email-masked]> on behalf of "Francois Clad (fclad)"
> <[email-masked]>
> *Date: *Thursday, March 8, 2018 at 5:21 AM
> *To: *"徐小虎(义先)" <[email-masked]>
> *Cc: *draft-farrel-mpls-sfc <[email-masked]>, "
> [email-masked]" <[email-masked]>, SPRING WG List <[email-masked]>,
> mpls-chairs <[email-masked]>, mpls <[email-masked]>
> *Subject: *Re: [mpls] [spring] The MPLS WG has placed
> draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
>
>
>
> Hi Xiaohu, all,
>
> I agree with the point raised by Xiaohu. The draft-farrel-mpls-sfc is
> copying ideas described in draft-xu-mpls-service-chaining. Please note
> that the work in draft-xu-mpls-service-chaining started one year before
> draft-farrel-mpls-sfc.
>
> There was discussion over the mic on the right home for these drafts among
> SFC, SPRING and MPLS, but no consensus was reached.
>
> As Xiaohu mentioned, draft-xu-mpls-service-chaining and
> draft-clad-spring-segment-routing-service-chaining have later merged
> as draft-xuclad-spring-sr-service-chaining. We have also requested a slot
> for presenting this draft during the upcoming IETF meeting.
>
> On 7 Mar 2018, at 01:13, 徐小虎(义先) <[email-masked]> wrote:
>
>
>
> Hi all,
>
>
>
> As I had pointed out at the last IETF meeting, section 6 of this draft has
> an serious overlap with https://tools.ietf.org/html/draft-xu-mpls-service-
> chaining-03
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dmpls-2Dservice-2Dchaining-2D03&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=UckZMQ6j33_dO8XnGXbarFxtcuHJrGDIsg2aAdG-sOk&e=>
>  that has now been updated by https://tools.ietf.org/
> html/draft-xuclad-spring-sr-service-chaining-01
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxuclad-2Dspring-2Dsr-2Dservice-2Dchaining-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=EgLaNYJSlDEdK7n2o1EWQsLRHCJBnTmZM-HtaMLsMLc&e=>
>  with a merge with draft-clad-spring-segment-routing-service-chaining.
>
>
>
> Hence, I'm very interesting to know the intention of such rewritting of a
> given mechanism that has been described in another draft. Is there any
> special nutrition?
>
>
>
> Best regards,
>
> Xiaohu
>
> 发件人：IETF Secretariat <[email-masked]>
>
> 收件人：draft-farrel-mpls-sfc <[email-masked]>; mpls <
> [email-masked]>; mpls-chairs <[email-masked]>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfarrel-2Dmpls-2Dsfc_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=eOBxho8eESw8vj3hUU0WF6BoW3Zu1CCi69KJRsBTt6k&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=Vy6H7zgumIaKzJb84UmsKCxcUsJYtXS_xqbcFgxdc3c&e=>
>
> [email-masked]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=_74fpq8zHtLUzCRwAD_Doy3iW0OdJ5032fZhJGPgr-w&e=>
>
>
>
> [email-masked]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sfc&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=nWWylOI0JVmT-t3N9mWaEFezzrqU6NxfM3FrKE3G0Pk&e=>
>
>
>

---

From: John E Drake <[email-masked]>
Date: Tue, 13 Mar 2018 21:44:20 +0000

Robert,

Comments inline.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:13 PM
To: John E Drake <[email-masked]>
Cc: James N Guichard <[email-masked]>; Francois Clad (fclad) <[email-masked]>; [email-masked]; mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi John,

There is one point which I am missing in this discussion ... why we are over and over duplicating ways to solve the same problem. Is there some sort of starvation of the problems to be solved ? Or is there an issue of "technology not invented here must be bad" ?

[JD]  ‘BGP Control Plane for NSH SFC ‘ ( https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02), the control plane companion to the subject draft is, as its title indicates, designed to work using the NSH.  However, early adopters were concerned about the availability of hardware NSH implementations and asked us to include the option of using an MPLS label stack to carry the [SPI, SI], which we did.

You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when "to handle situations in which the NSH is not ubiquitously deployed." What are those situations considering that MPLS requires IP both control plane and forwarding to be in place so does NSH.

[JD]  See above

Would now all of the v-service vendors need to support both ways of encoding service/function IDs ?

[JD]  I would expect a graceful transition, i.e., one SFF at a time, from MPLS label stack to NSH, and the control plane draft explicitly includes the infrastructure necessary to allow both to be included, on a hop by hop basis, in the same service function path (the instantiation of a service function chain.)

[JD]  See above

Last - how does  draft-farrel-mpls-sfc works in only IPv6 IP networks ? Oh maybe there is and not going to be such thing ?

[JD]  Like a charm.  The underlay would be IPv6, perhaps w/ SR, and the overlay would be NSH.  We use the Encapsulation attribute to completely decouple the overlay and underlay networks.

 Best,
Robert.

On Tue, Mar 13, 2018 at 9:59 PM, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Jim,

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of James N Guichard
Sent: Tuesday, March 13, 2018 3:00 PM
To: Francois Clad (fclad) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Francois,

One comment below ..

Hi Adrian,

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

_______________________________________________
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=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=aIvAamM2MsrmNIsMiGG4DnY2vL9aBbhe-npduXgbqKA&s=U5Y-B-3Uwb_RpxLQVNUkQuqxv7ONpkRA_8Z22R_fD1I&e=>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 13 Mar 2018 22:51:50 +0100

Hi John,

*However, early adopters were concerned about the availability of hardware
NSH implementations and asked us to include the option of using an MPLS
label stack to carry the [SPI, SI], which we did.*

Are you saying that there is more service function hardware out there in
the market which support MPLS [SPI,SI] encoding then those supporting NSH ?
If so and if you or someone will list and compare both I am game to
progress this work - no issue. If not I really do not see much point.

So far I have seen zero of the former and quite a bit of the latter hence
my post.

Yours,
Robert.

On Tue, Mar 13, 2018 at 10:44 PM, John E Drake <[email-masked]> wrote:

> Robert,
>
>
>
> Comments inline.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, March 13, 2018 5:13 PM
> *To:* John E Drake <[email-masked]>
> *Cc:* James N Guichard <[email-masked]>; Francois Clad
> (fclad) <[email-masked]>; [email-masked]; mpls <[email-masked]>;
> SPRING WG List <[email-masked]>; [email-masked]
> *[JD]  ‘BGP Control Plane for NSH SFC ‘ (
> https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02
> <https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02>),
> the control plane companion to the subject draft is, as its title
> indicates, designed to work using the NSH.  However, early adopters were
> concerned about the availability of hardware NSH implementations and asked
> us to include the option of using an MPLS label stack to carry the [SPI,
> SI], which we did.*
>
>
>
> *[JD]  See above*
> *[JD]  I would expect a graceful transition, i.e., one SFF at a time, from
> MPLS label stack to NSH, and the control plane draft explicitly includes
> the infrastructure necessary to allow both to be included, on a hop by hop
> basis, in the same service function path (the instantiation of a service
> function chain.)*
>
>
>
> *[JD]  See above*
> Last - how does  draft-farrel-mpls-sfc works in only IPv6 IP networks ?
> Oh maybe there is and not going to be such thing ?
>
>
>
> *[JD]  Like a charm.  The underlay would be IPv6, perhaps w/ SR, and the
> overlay would be NSH.  We use the Encapsulation attribute to completely
> decouple the overlay and underlay networks. *
>
>
>
>  Best,
> Robert.
>
>
>
>
>
> "cart ahead of the horse."
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=aIvAamM2MsrmNIsMiGG4DnY2vL9aBbhe-npduXgbqKA&s=U5Y-B-3Uwb_RpxLQVNUkQuqxv7ONpkRA_8Z22R_fD1I&e=>
>
>
>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 14 Mar 2018 09:35:19 +0800

Jim,
------------------------------------------------------------------James N Guichard <[email-masked]>2018年3月14日(星期三) 03:00Francois Clad (fclad) <[email-masked]>; [email-masked] <[email-masked]>mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked] <[email-masked]>Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
Hi Francois, One comment below .. From: mpls [mailto:[email-masked]]
On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: [email-masked]
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi Adrian,

On 9 Mar 2018, at 10:17, Adrian Farrel <[email-masked]> wrote: I, too, hope we can move to a technical discussion of the differences between the proposals
 The issue is that, from a technical point of view, there is no difference between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the solution that was originally documented in draft-xu-mpls-service-chaining, as Xiaohu
 pointed out several times. Jim> as far as I can tell this is not exactly true.. draft-xu-mpls-service-chaining-00 talks about using an MPLS label to identify a service segment. Draft-farrel-mpls-sfc talks about using 2 labels, an SFC context label and an SF label, to essentially mimic NSH behavior. The authors of that draft even go as far as to say (about the context label) “.. using the semantics of the SPI is exactly as defined in [RFC8300]”  which is exactly what you state you don’t want to do in draft-xuclad-spring-sr-service-chaining. Therefore I am not sure how you can come to the conclusion that there is no difference between the two solutions.
<Xiaohu>  draft-xu* talks about using 2 labels as well, see Section 3.1 of  https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03#page-7. The only difference that I can find is draft-farrel* interpretes  "node segment label" as "context label". 
BTW, this reminds me of almost the same thing just happened between https://tools.ietf.org/html/draft-xu-mpls-unified-source-routing-instruction-04 and https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-03#page-5 where the latter interpretes "label stack" as "instruction stack". 
Xiaohu
Jim

Thanks,

Francois 

and not spend time thrashing around in IETF politics. I'm sure the ADs will help us understand what is written in the various WG charters, so our best next step
 would be to read (you know, like all the words :-) what is in the drafts. However, since Zafar ascribes to me something that I did not say and that is not recorded in the minutes, perhaps I can set that straight. He said... > From IETF process viewpoint, this call for adaption is like putting the "cart ahead of the horse."> MPLS WG comes last in the process after there is an agreement from Spring and SFC groups> on the need for MPLS data plane changes proposed by the draft. I raised this point at the mic> at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at the last stage> in the process; expert to review this work does not sit in the MPLS WG. According to the minutes, Zafar said... | Zafar Ali: before defining the solution, is this the right approach in SFC? Starting| in MPLS WG is wrong thing to do. And I responded... | Adrian: This was already presented in SFC WG today. In the SFC WG I said... | - The draft discusses how MPLS can be used for SFC. It is being discussed in the|    MPLS working group.| - We are looking at environments in which deployed MPLS routers can be used|    for creating an SFC, rather than using NSH. If you want my opinion:- The SFC WG is chartered to work on NSH only- The MPLS WG is chartered to work on MPLS- This draft asks for MPLS code points so can only be in MPLS- This draft must be reviewed in SFC and SPRING as it progresses and   certainly at WG last call Adrian From: mpls
 [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: 09 March 2018 00:02
To: Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; [email-masked]; draft-farrel-mpls-sfc; mpls-chairs; mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
Importance: High Dear MPLS WG Chairs and the authors of draft-farrel-mpls-sfc,  I would like to draw your attention to the serious issue raised by Xiaohu and Francois.  Summary: Please note that this working group adaption against the IETF process and its spirit. Please recall the adaption call.  Details:  Just to reiterate the issue raised by Xiaohu and Francois. At last IETF we discussed 3 drafts (draft-xu-mpls-service-chaining-03, draft-farrel-mpls-sfc and draft-clad-spring-segment-routing-service-chaining)
 in SFC, Spring and MPLS WG. There was the specific conversation on which WG the work belongs, and the assumed follow-up was for the chairs and ADs to have the discussion on home for these drafts.  From IETF process viewpoint, this call for adaption is like putting the "cart ahead of the horse." MPLS WG comes last in the process after there is an agreement from Spring
 and SFC groups on the need for MPLS data plane changes proposed by the draft. I raised this point at the mic at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at the last stage in the process; expert to review this work does not sit
 in the MPLS WG. The drafts also did not stay dormant after IETF100. There were email conversations among the authors of the concerned drafts (https://mailarchive.ietf.org/arch/msg/mpls/bmH5QH65b2Non2Y7qNEBBI_kSOA).  Authors of draft-xu- and draft-clad- followed the proper IETF process, discussed and merged the contents. They published draft-xuclad-spring-sr-service-chaining-01 and asked
 WG for a "presentation slot" at IETF100. Only to find that draft-farrel-mpls-sfc used a backdoor to force this "WG adaption call"!  One also has to question the timing of this adaption call when the WGs are meeting face-to-face in a couple of weeks. Is it no longer IETF spirit to make use of the face-to-face
 to do the right thing, especially when we are meeting in two weeks?   In the light of the above, my request to the authors of draft-farrel and MPLS WG chairs to please do the right thing and recall this WG adaptation call.  Thanks Regards ... Zafar  From: mpls <[email-masked]>
 on behalf of "Francois Clad (fclad)" <[email-masked]>
Date: Thursday, March 8, 2018 at 5:21 AM
To: "徐小虎(义先)"
 <[email-masked]>
Cc: draft-farrel-mpls-sfc <[email-masked]>, "[email-masked]"
 <[email-masked]>, SPRING WG List <[email-masked]>, mpls-chairs <[email-masked]>,
 mpls <[email-masked]>
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi Xiaohu, all,

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

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

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

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

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

sfc mailing list
[email-masked]

---

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

I have the same observation as Robert here. The IETF has focussed on using NSH as a mechanism for service chaining in SFC WG. We finally see some implementations coming alive. With this proposal we will start from scratch as all SFF and SF implementations will have to be modified. NSH was and still is a hard journey to lineup all implementations.
draft-farrel-mpls-sfc is an alternative way to encode the same information of NSH in an MPLS friendly manner. Why do we need this and what’s wrong with NSH is the question we should ask first before considering to adopt this work.

I would advocate the need to define a way in MPLS and SR/SPRING to transport NSH, but we don’t have to reencode NSH in another encapsulation. Just use it as is.

From: spring <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Tuesday, 13 March 2018 at 22:51
To: John E Drake <[email-masked]>
Cc: mpls <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, James N Guichard <[email-masked]>, "[email-masked]" <[email-masked]>, "Francois Clad (fclad)" <[email-masked]>
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi John,

However, early adopters were concerned about the availability of hardware NSH implementations and asked us to include the option of using an MPLS label stack to carry the [SPI, SI], which we did.

Are you saying that there is more service function hardware out there in the market which support MPLS [SPI,SI] encoding then those supporting NSH ? If so and if you or someone will list and compare both I am game to progress this work - no issue. If not I really do not see much point.

So far I have seen zero of the former and quite a bit of the latter hence my post.

Yours,
Robert.

On Tue, Mar 13, 2018 at 10:44 PM, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Comments inline.

Yours Irrespectively,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:13 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: James N Guichard <[email-masked]<mailto:[email-masked]>>; Francois Clad (fclad) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mpls <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi John,

[JD]  See above

[JD]  See above

 Best,
Robert.

Yours Irrespectively,

John

Hi Francois,

One comment below ..

Hi Adrian,

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Mar 2018 12:51:08 +0000

Robert,

The point is to re-purpose existing MPLS hardware in the short-term to build service function forwarders.

Yours Irrespectively,

John

Sent: Tuesday, March 13, 2018 5:52 PM

Hi John,

Yours,
Robert.

Comments inline.

Yours Irrespectively,

John

Hi John,

[JD]  ‘BGP Control Plane for NSH SFC ‘ ( https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Dnsh-2Dbgp-2Dcontrol-2Dplane-2D02&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=UUQFBHF7EHbEZCus0CfOOwSDv6XEqBO4y6A5GaMwFNE&s=aXFnSMcArO2XMXtv2s4qBRbCVx4M5DZZfIGDN84Coow&e=>), the control plane companion to the subject draft is, as its title indicates, designed to work using the NSH.  However, early adopters were concerned about the availability of hardware NSH implementations and asked us to include the option of using an MPLS label stack to carry the [SPI, SI], which we did.

[JD]  See above

[JD]  See above

 Best,
Robert.

Yours Irrespectively,

John

Hi Francois,

One comment below ..

Hi Adrian,

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Mar 2018 13:00:56 +0000

Wim,

Comment inline

Yours Irrespectively,

John

From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:[email-masked]]
Sent: Wednesday, March 14, 2018 4:38 AM
To: Robert Raszuk <[email-masked]>; John E Drake <[email-masked]>
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; James N Guichard <[email-masked]>; [email-masked]; Francois Clad (fclad) <[email-masked]>
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[JD]  Please see:   ‘BGP Control Plane for NSH SFC ‘ ( https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02),

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 13 March 2018 at 22:51
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>, SPRING WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, James N Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Francois Clad (fclad)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi John,

Yours,
Robert.

Comments inline.

Yours Irrespectively,

John

Hi John,

[JD]  ‘BGP Control Plane for NSH SFC ‘ ( https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Dnsh-2Dbgp-2Dcontrol-2Dplane-2D02&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=yKnjyWDM5kfm2GPzIdFS-wXXQvmZkBkaq2aXRR-Vc6E&s=D4gx92kOehu9BdeoE5w-fqSHa2pLPLSXY-pNiYR3r58&e=>), the control plane companion to the subject draft is, as its title indicates, designed to work using the NSH.  However, early adopters were concerned about the availability of hardware NSH implementations and asked us to include the option of using an MPLS label stack to carry the [SPI, SI], which we did.

[JD]  See above

[JD]  See above

 Best,
Robert.

Yours Irrespectively,

John

Hi Francois,

One comment below ..

Hi Adrian,

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

---

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

John, the draft explains a control plane for SFC and can work on different encapsulations than described in draft-farrel-mpls-sfc.  Even standard NSH with MPLS label swap or SR/SPRING can be supported with https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02.
The discussion should be what is wrong with standard NSH and why we need a different format.

From: John E Drake <[email-masked]>
Date: Wednesday, 14 March 2018 at 14:01
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Robert Raszuk <[email-masked]>
Cc: mpls <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>, James N Guichard <[email-masked]>, "[email-masked]" <[email-masked]>, "Francois Clad (fclad)" <[email-masked]>
Subject: RE: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Wim,

Comment inline

Yours Irrespectively,

John

Hi John,

Yours,
Robert.

Comments inline.

Yours Irrespectively,

John

Hi John,

[JD]  See above

[JD]  See above

 Best,
Robert.

Yours Irrespectively,

John

Hi Francois,

One comment below ..

Hi Adrian,

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

---

From: "Bernier, Daniel" <[email-masked]>
Date: Wed, 14 Mar 2018 14:54:03 +0000

Hi John,

Don't we already have draft-fm-bess-service-chaining-01<https://tools.ietf.org/html/draft-fm-bess-service-chaining-01> to perform service chains with existing MPLS implementations ?

Thanks,​

Daniel Bernier

________________________________
From: spring <[email-masked]> on behalf of John E Drake <[email-masked]>
Sent: Wednesday, March 14, 2018 8:51 AM
To: Robert Raszuk
Cc: mpls; SPRING WG List; [email-masked]; James N Guichard; [email-masked]; Francois Clad (fclad)
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Robert,

Yours Irrespectively,

John

Hi John,

Yours,
Robert.

Comments inline.

Yours Irrespectively,

John

Hi John,

[JD]  See above

[JD]  See above

 Best,
Robert.

Yours Irrespectively,

John

Hi Francois,

One comment below ..

Hi Adrian,

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Mar 2018 15:02:07 +0000

Hi,

I think there is a fundamental difference between the subject draft and draft-xuclad-spring-sr-service-chaining-01.  Despite your co-author Wim’s assertions to the contrary [1], the latter draft is describing how to use segment routing rather than NSH for service function path traversal.

The subject draft still uses NSH for service function traversal but augments it with the capability to allow a Classifier to target, on an exception basis, one or more specific SFFs along a service function path.  This is described in:  https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02#section-7.6,  https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02#section-7.7, https://tools.ietf.org/html/draft-farrel-mpls-sfc-04#section-7.

This is a capability that I think could usefully be added to the NSH.

Yours Irrespectively,

John

[1]  “I would advocate the need to define a way in MPLS and SR/SPRING to transport NSH, but we don’t have to reencode NSH in another encapsulation. Just use it as is.”

From: mpls [mailto:[email-masked]] On Behalf Of ???(??)
Sent: Tuesday, March 13, 2018 9:35 PM
To: spring <[email-masked]>; Francois Clad (fclad) <[email-masked]>; [email-masked]
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [mpls] [spring] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Jim,

------------------------------------------------------------------
James N Guichard <[email-masked]<mailto:[email-masked]>>
2018年3月14日(星期三) 03:00
Francois Clad (fclad) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
mpls <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi Francois,

One comment below ..

Hi Adrian,

Xiaohu

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

The drafts also did not stay dormant after IETF100. There were email conversations among the authors of the concerned drafts (https://mailarchive.ietf.org/arch/msg/mpls/bmH5QH65b2Non2Y7qNEBBI_kSOA<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_mpls_bmH5QH65b2Non2Y7qNEBBI-5FkSOA&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=Xwv3MgDB8feljDqMR00xJnx5wBrUWcyYlXHdl9TVsa8&s=kPOH4rvMTW8O6ArGei4mMBW6kH0CiqF4vQGBRaz27Ho&e=>).

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

As I had pointed out at the last IETF meeting, section 6 of this draft has an serious overlap with https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dmpls-2Dservice-2Dchaining-2D03&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=Xwv3MgDB8feljDqMR00xJnx5wBrUWcyYlXHdl9TVsa8&s=QsMo-In6D5aAuiEB2kFmuXUY_YOZhDv_f6sszufwJC4&e=> that has now been updated by https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxuclad-2Dspring-2Dsr-2Dservice-2Dchaining-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=Xwv3MgDB8feljDqMR00xJnx5wBrUWcyYlXHdl9TVsa8&s=vKTDViMHeEHbcANOT-_DnpXphxVT4jF6hL5zpto2beA&e=> with a merge with draft-clad-spring-segment-routing-service-chaining.

Best regards,
Xiaohu

The document is available at
https://datatracker.ietf.org/doc/draft-farrel-mpls-sfc/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfarrel-2Dmpls-2Dsfc_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=Xwv3MgDB8feljDqMR00xJnx5wBrUWcyYlXHdl9TVsa8&s=fxuJ07snpcrDFdAitnUbJ8LkMn2MnH1Cs2GmDAO20RM&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=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=Xwv3MgDB8feljDqMR00xJnx5wBrUWcyYlXHdl9TVsa8&s=X9wcp68Y5pUf4W80QXFjQxENOOyy4grSHRoj2f_1TCc&e=>
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=Xwv3MgDB8feljDqMR00xJnx5wBrUWcyYlXHdl9TVsa8&s=2tsHzeSOHBKY4tnFPaiLvU6M4zByhGGJijaJi8qlq8I&e=>

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sfc&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=Xwv3MgDB8feljDqMR00xJnx5wBrUWcyYlXHdl9TVsa8&s=oAsU7DtoH3bkypy63NgGhenwP3CRA4hKtDieEMjOnY8&e=>

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Mar 2018 15:17:09 +0000

Daniel,

It has a multiplicity of issues, primarily wrt scalability and ease of configuration.

Yours Irrespectively,

John

From: spring [mailto:[email-masked]] On Behalf Of Bernier, Daniel
Sent: Wednesday, March 14, 2018 10:54 AM
To: John E Drake <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; James N Guichard <[email-masked]>; [email-masked]; Francois Clad (fclad) <[email-masked]>
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi John,

Don't we already have draft-fm-bess-service-chaining-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfm-2Dbess-2Dservice-2Dchaining-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=F3v0beOmsieoZ48B9JYfPjhGusHbW5F5SF9W20KcURU&s=UHNxeZF9m0BVCmAjG-ODELBOjV1v2yu25uDOeZSRw6g&e=> to perform service chains with existing MPLS implementations ?

Thanks,​

Daniel Bernier

________________________________
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of John E Drake <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 14, 2018 8:51 AM
To: Robert Raszuk
Cc: mpls; SPRING WG List; [email-masked]<mailto:[email-masked]>; James N Guichard; [email-masked]<mailto:[email-masked]>; Francois Clad (fclad)
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Robert,

Yours Irrespectively,

John

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

Hi John,

Yours,
Robert.

Comments inline.

Yours Irrespectively,

John

Hi John,

[JD]  See above

[JD]  See above

 Best,
Robert.

Yours Irrespectively,

John

Hi Francois,

One comment below ..

Hi Adrian,

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 14 Mar 2018 16:59:44 +0100

Hi John,

Daniel,
> It has a multiplicity of issues, primarily wrt scalability and ease of

​Am I reading your comment correctly that
draft-ietf-bess-service-chaining-04 is unscalable and hard to configure and
draft ​draft-farrel-mpls-sfc is superior ?

Please observe that your own Juniper products are based already for a long
time on the former and as you admited no one has any product based on the
latter.

Doesn't this makes it a bit of an odd argument ? Also please do notice
that  draft-ietf-bess-service-chaining-04 vastly reuses 20 years of
experience of L3VPNs service so your claim may be IMHO a little weak :)

Cheers,
R.

>  Yours Irrespectively,
>
> John
>
>
>
> *From:* spring [mailto:[email-masked]] *On Behalf Of *Bernier,
> Daniel
> *Sent:* Wednesday, March 14, 2018 10:54 AM
> *To:* John E Drake <[email-masked]>; Robert Raszuk <[email-masked]>
> *Cc:* mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked];
> James N Guichard <[email-masked]>; [email-masked];
> Francois Clad (fclad) <[email-masked]>
> *Subject:* Re: [spring] [mpls] [sfc] The MPLS WG has placed
> Don't we already have draft-fm-bess-service-chaining-01
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfm-2Dbess-2Dservice-2Dchaining-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=F3v0beOmsieoZ48B9JYfPjhGusHbW5F5SF9W20KcURU&s=UHNxeZF9m0BVCmAjG-ODELBOjV1v2yu25uDOeZSRw6g&e=>
> to perform service chains with existing MPLS implementations ?
>
>
>
> Thanks,​
>
>
>

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Mar 2018 16:30:16 +0000

Robert,

Comments inline

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, March 14, 2018 12:00 PM
To: John E Drake <[email-masked]>
Cc: EXT - [email-masked] <[email-masked]>; mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; James N Guichard <[email-masked]>; [email-masked]; Francois Clad (fclad) <[email-masked]>
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi John,

Daniel,

​Am I reading your comment correctly that draft-ietf-bess-service-chaining-04 is unscalable and hard to configure and draft ​draft-farrel-mpls-sfc is superior ?

[JD]  The authors of that draft provided much input and guidance to the authors of ​draft-farrel-mpls-sfc.

Please observe that your own Juniper products are based already for a long time on the former and as you admited no one has any product based on the latter.

[JD]  I am not sure of your point.

Doesn't this makes it a bit of an odd argument ? Also please do notice that  draft-ietf-bess-service-chaining-04 vastly reuses 20 years of experience of L3VPNs service so your claim may be IMHO a little weak :)

[JD  They both draw upon the same heritage.

Cheers,
R.

 Yours Irrespectively,
John

From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bernier, Daniel
Sent: Wednesday, March 14, 2018 10:54 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: mpls <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Francois Clad (fclad) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi John,

Thanks,​

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 14 Mar 2018 17:38:06 +0100

*> [JD  They both draw upon the same heritage.*

I respectfully disagree John with that. One should not equate control plane
solution with data plane embedded solution. Those are completely different
spaces and different heritages.

I would further claim that we do have much more heritage in control plane
path steering rather then in data plane embedding of the same.

Cheers,
R.

On Wed, Mar 14, 2018 at 5:30 PM, John E Drake <[email-masked]> wrote:

> *Sent:* Wednesday, March 14, 2018 12:00 PM
> *Cc:* EXT - [email-masked] <[email-masked]>; mpls <
> [email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; James N
> Guichard <[email-masked]>; [email-masked]; Francois
> Clad (fclad) <[email-masked]>
> ​Am I reading your comment correctly that draft-ietf-bess-service-chaining-04
> is unscalable and hard to configure and draft ​draft-farrel-mpls-sfc is
> superior ?
>
>
>
>
>
> *[JD]  The authors of that draft provided much input and guidance to the
> authors of ​draft-farrel-mpls-sfc. *
>
>
>
>
>
> *[JD]  I am not sure of your point.*
>
>
>
>
>
> *[JD  They both draw upon the same heritage. *
>
>
>
>
>
> Cheers,
> R.
>
>
>
>
>
>  Yours Irrespectively,
>
> John
>
>
>

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Mar 2018 16:52:29 +0000

Robert,

My apologies,  I thought you were talking about this draft:  https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02, which is the draft to which I was referring in my reply to you.

Yours Irrespectively,

John

Sent: Wednesday, March 14, 2018 12:38 PM

> [JD  They both draw upon the same heritage.

I respectfully disagree John with that. One should not equate control plane solution with data plane embedded solution. Those are completely different spaces and different heritages.

I would further claim that we do have much more heritage in control plane path steering rather then in data plane embedding of the same.

Cheers,
R.

On Wed, Mar 14, 2018 at 5:30 PM, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Comments inline

Yours Irrespectively,

John

Cc: EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; mpls <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; James N Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Francois Clad (fclad) <[email-masked]<mailto:[email-masked]>>

Hi John,

Daniel,

Cheers,
R.

 Yours Irrespectively,
John

Hi John,

Thanks,​

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 14 Mar 2018 17:32:24 +0000

The implementations based on draft-ietf-bess-service-chaining-04 are absolutely in production use.
Can it be explained what is meant by: “It has a multiplicity of issues, primarily wrt scalability and ease of configuration”?

Maria

From: sfc [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, March 14, 2018 12:00 PM
To: John E Drake <[email-masked]>
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]; EXT - [email-masked] <[email-masked]>; James N Guichard <[email-masked]>; [email-masked]; Francois Clad (fclad) <[email-masked]>
Subject: Re: [sfc] [spring] [mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Hi John,

Daniel,

Cheers,
R.

 Yours Irrespectively,
John

Hi John,

Thanks,​

---

From: Lizhenbin <[email-masked]>
Date: Thu, 15 Mar 2018 07:47:20 +0000

I have read draft-xuclad-spring-sr-service-chaining and draft-farrel-mpls-sfc. In essence the SR-MPLS SFC solutions proposed in the two drafts are similar. I think the easiest way to solve the confliction is to remove the section 6 of draft-farrel-mpls-sfc, then the updated draft goes on for MPLS WG adoption.

发件人: mpls [mailto:[email-masked]] 代表 徐小虎(义先)
发送时间: 2018年3月14日 9:35
收件人: spring <[email-masked]>; Francois Clad (fclad) <[email-masked]>; [email-masked]
抄送: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
主题: Re: [mpls] [spring] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

Jim,

Hi Francois,

One comment below ..

Hi Adrian,

Xiaohu

Jim

Thanks,
Francois

He said...

And I responded...

In the SFC WG I said...

If you want my opinion:

Adrian

Summary:

Details:

Thanks

Regards ... Zafar

Hi Xiaohu, all,

Hi all,

Best regards,
Xiaohu

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 15 Mar 2018 18:02:28 +0800

Hi Robin,
It sounds reasonable and fair. 
Best regards,Xiaohu
------------------------------------------------------------------Lizhenbin <[email-masked]>2018年3月15日(星期四) 15:48徐小虎(义先) <[email-masked]>; spring <[email-masked]>; Francois Clad (fclad) <[email-masked]>; [email-masked] <[email-masked]>mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked] <[email-masked]>[spring] 答复: [mpls]    [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
I have read draft-xuclad-spring-sr-service-chaining and draft-farrel-mpls-sfc. In essence the SR-MPLS SFC solutions proposed in the two drafts are
 similar. I think the easiest way to solve the confliction is to remove the section 6 of draft-farrel-mpls-sfc, then the updated draft goes on for MPLS WG adoption.     发件人: mpls [mailto:[email-masked]]
代表 徐小虎(义先)
发送时间: 2018年3月14日 9:35
收件人: spring <[email-masked]>; Francois Clad (fclad) <[email-masked]>; [email-masked]
抄送: mpls <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
主题: Re: [mpls] [spring] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"  Jim, ------------------------------------------------------------------James N Guichard <[email-masked]>2018年3月14日(星期三)
 03:00Francois Clad (fclad) <[email-masked]>;
[email-masked] <[email-masked]>mpls <[email-masked]>; SPRING WG List <[email-masked]>;
[email-masked] <[email-masked]>Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi Francois, One comment below .. From: mpls [mailto:[email-masked]]
On Behalf Of Francois Clad (fclad)
Sent: Tuesday, March 13, 2018 2:27 PM
To: [email-masked]
Cc: mpls <[email-masked]>; SPRING WG List <[email-masked]>;
[email-masked]
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi Adrian, On 9 Mar 2018, at 10:17, Adrian Farrel <[email-masked]> wrote: I, too, hope we can move to a technical discussion of the differences between the proposals
 The issue is that, from a technical point of view, there is no difference between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the solution that was originally documented in draft-xu-mpls-service-chaining, as
 Xiaohu pointed out several times. Jim> as far as I can tell this is not exactly true.. draft-xu-mpls-service-chaining-00 talks about using an MPLS label to identify a service segment. Draft-farrel-mpls-sfc talks about using 2 labels, an SFC context label and an SF label, to essentially mimic NSH behavior. The authors of that draft even go as far as to say (about the context label) “.. using the semantics of the SPI is exactly as defined in [RFC8300]”  which is exactly what you state you don’t want to do in draft-xuclad-spring-sr-service-chaining. Therefore I am not sure how you can come to the conclusion that there is no difference between the two solutions. <Xiaohu>  draft-xu* talks about using 2 labels as well, see Section 3.1 of  https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03#page-7. The only difference that I can find is draft-farrel* interpretes  "node segment label" as "context label".  BTW, this reminds me of almost the same thing just happened between https://tools.ietf.org/html/draft-xu-mpls-unified-source-routing-instruction-04 and https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-03#page-5 where the latter interpretes "label stack" as "instruction stack".  Xiaohu Jim

Thanks,

Francois  and not spend time thrashing around in IETF politics. I'm sure the ADs will help us understand what is written in the various WG charters, so our
 best next step would be to read (you know, like all the words :-) what is in the drafts. However, since Zafar ascribes to me something that I did not say and that is not recorded in the minutes, perhaps I can set that straight. He said... > From IETF process viewpoint, this call for adaption is like putting the "cart ahead of the horse."> MPLS WG comes last in the process after there is an agreement from Spring and SFC groups> on the need for MPLS data plane changes proposed by the draft. I raised this point at the mic> at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at the last stage> in the process; expert to review this work does not sit in the MPLS WG. According to the minutes, Zafar said... | Zafar Ali: before defining the solution, is this the right approach in SFC? Starting| in MPLS WG is wrong thing to do. And I responded... | Adrian: This was already presented in SFC WG today. In the SFC WG I said... | - The draft discusses how MPLS can be used for SFC. It is being discussed in the|    MPLS working group.| - We are looking at environments in which deployed MPLS routers can be used|    for creating an SFC, rather than using NSH. If you want my opinion:- The SFC WG is chartered to work on NSH only- The MPLS WG is chartered to work on MPLS- This draft asks for MPLS code points so can only be in MPLS- This draft must be reviewed in SFC and SPRING as it progresses and   certainly at WG last call Adrian From: mpls [mailto:[email-masked]] On
 Behalf Of Zafar Ali (zali)
Sent: 09 March 2018 00:02
To: Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; [email-masked]; draft-farrel-mpls-sfc; mpls-chairs; mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"
Importance: High Dear MPLS WG Chairs and the authors of draft-farrel-mpls-sfc,  I would like to draw your attention to the serious issue raised by Xiaohu and Francois.  Summary: Please note that this working group adaption against the IETF process and its spirit. Please recall the adaption call.  Details:  Just to reiterate the issue raised by Xiaohu and Francois. At last IETF we discussed 3 drafts (draft-xu-mpls-service-chaining-03, draft-farrel-mpls-sfc
 and draft-clad-spring-segment-routing-service-chaining) in SFC, Spring and MPLS WG. There was the specific conversation on which WG the work belongs, and the assumed follow-up was for the chairs and ADs to have the discussion on home for these drafts.  From IETF process viewpoint, this call for adaption is like putting the "cart ahead of the horse." MPLS WG comes last in the process after there is
 an agreement from Spring and SFC groups on the need for MPLS data plane changes proposed by the draft. I raised this point at the mic at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at the last stage in the process; expert to review
 this work does not sit in the MPLS WG. The drafts also did not stay dormant after IETF100. There were email conversations among the authors of the concerned drafts (https://mailarchive.ietf.org/arch/msg/mpls/bmH5QH65b2Non2Y7qNEBBI_kSOA).  Authors of draft-xu- and draft-clad- followed the proper IETF process, discussed and merged the contents. They published draft-xuclad-spring-sr-service-chaining-01
 and asked WG for a "presentation slot" at IETF100. Only to find that draft-farrel-mpls-sfc used a backdoor to force this "WG adaption call"!  One also has to question the timing of this adaption call when the WGs are meeting face-to-face in a couple of weeks. Is it no longer IETF spirit to
 make use of the face-to-face to do the right thing, especially when we are meeting in two weeks?   In the light of the above, my request to the authors of draft-farrel and MPLS WG chairs to please do the right thing and recall this WG adaptation
 call.  Thanks Regards ... Zafar  From: mpls <[email-masked]>
 on behalf of "Francois Clad (fclad)" <[email-masked]>
Date: Thursday, March 8, 2018 at 5:21 AM
To: "徐小虎(义先)"
 <[email-masked]>
Cc: draft-farrel-mpls-sfc <[email-masked]>, "[email-masked]"
 <[email-masked]>, SPRING WG List <[email-masked]>, mpls-chairs <[email-masked]>,
 mpls <[email-masked]>
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi Xiaohu, all,

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

mpls mailing list
[email-masked]

spring mailing list
[email-masked]

sfc mailing list
[email-masked]