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

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

Hi John,

Sorry for the late reply, was on PTO.

Please see my comments below.

Best Regards,

Daniel 

On 2018-03-09, 2:14 PM, "John E Drake" <[email-masked]> wrote:

    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.

DB> I think a few people have already expressed their opinion on different e-mail threads in the mailing list and I will let progress through them. My main concern was with WG adoption poll starting when the outcome of last IETF was to review with chairs where to position each individual draft.
     
    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.

DB> Where I differ is that although there is long living idea of using SR to perform service chaining, there is value in formally documenting ways of doing so. I referred to it before in the mailing list, but the expired draft-homma-sfc-forwarding-methods-analysis referenced potential challenges with stacked headers so I believe it makes sense to have SPRING provide an answer. 

DB> I also do not see draft-xuclad-spring-sr-service-chaining as an informational document since it introduces proxy behaviors to address SR unaware functions without having to perform repetitive reclassification which should be standardized to ensure interop and migration paths for the current VNF ecosystem. At least, from my operator viewpoint. 
 
    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.

DB> I would say “it depends”. Based on the rechartered SFC WG “7. Transport Considerations RFC to cover the expectations SFC and NSH place on transport, and the operational constraints transports used by NSH need to meet.” So, I would agree that, SFC might have an opinion on transport in scenarios where NSH is only used as a metadata container. However, there is no prescription that SR should follow the SFC architecture, and in that case, the SFC working group may be interested and informed but not impacted.

DB> As you can see, draft-xuclad-spring-sr-service-chaining is evolving and future revisions will document these capabilities. It is also currently possible to perform branching either “in flight” or at the source through SRTE policies and steering reconfiguration. Again, with my operator cap on, I also do not necessarily see the requirement to support all possible path scenarios ... just introducing/maintaining sequential chains over existing Telco architecture is a daring task.

    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.

DB> This is the heart of the discussion. In draft-farrel-mpls-sfc, the intent is to leverage MPLS labels to replace NSH and still align with RFC7665 and as such, uses 2 labels to represent SPI/SI. In draft-xuclad-spring-sr-service-chaining the reference architecture is truly in SRTE draft-filsfils-spring-segment-routing-policy, where a service insertion is just another representation, and can coexist with underlay SRTE policies. It can use constructs out of SR-MPLS for an MPLS data plane or behaviors defined in draft-filsfils-spring-srv6-network-programming when using SRH. I would assume some of the problem statements will be similar to SFC but the solutions might differ.
     
    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.

DB> Agreed on the WG placement and parallel progress if the community sees interest in pursuing multiple approaches to RFC7665 SPI/SI encoding (https://mailarchive.ietf.org/arch/msg/spring/7DjGQpbTeRZj1gLtxOcjbF4Rybc) . I just do not see the need to detail section 6 other than to reference draft-filsfils-spring-segment-routing-mpls if you want to use MPLS-SR instead of label swapping for the transport tunnels since the meat of draft-farrel-mpls-sfc is in the use of 2 labels (+entropy) to represent the SPI/SI. 

DB> I personally thing draft-xuclad-spring-sr-service-chaining should progress since it is defining ways to define a chain not as a transport agnostic overlay but integrated within the forwarding plane described as a TE policy.

    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,
     
    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"

    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"

    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 <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=>).

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

    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"

    
    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/ <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=>
    
    _______________________________________________
    mpls mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/mpls

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