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

[<[e-mail]>]

Lizhong, Andy,

<Speaking as a SPRING co-chair>
I case you missed it, please find below the current status:
- The SPRING chairs and WG received a request for adoption of draft-xuclad-spring-sr-service-chaining-01 in the SPRING WG.
- This is being considered and there has been a related discussion in London in the SPRING WG, during the discussion on the next SPRING work items.

<Speaking as a MPLS individual contributor>
If you believe that there are similarities between draft-farrel section6 and draft-xuclad, up to the point that they need to be discussed in the same WG, this may need to be discussed with the authors of draft-farrel-mpls-sfc. My understanding of their plan was “Our plan is to remove all discussion of SR (specifically MPLS-SR) from this document.”

Thanks,
Regards,
--Bruno

From: mpls [mailto:[e-mail]] On Behalf Of Lizhong Jin
Sent: Thursday, April 19, 2018 10:29 AM
To: mpls
Cc: [e-mail]; sfc
Subject: Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc

+1 to adopt both.
Although the label stack is similar between draft-farrel section6 and draft-xuclad, but other points are different, e..g., meta data. If we consider a solution with several separate technical points, the two drafts do collapse in some points. But if you consider a solution as an integral one, the two drafts are different.
BR
Lizhong

----------------------------------------------------------------------

Message: 1
Date: Sun, 15 Apr 2018 10:55:55 -0400
From: "Andrew G. Malis" <[e-mail]<mailto:[e-mail]>>
To: "Zafar Ali (zali)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, SPRING WG List <[e-mail]<mailto:[e-mail]>>,
        "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] [sfc] Working Group adoption of
        draft-farrel-mpls-sfc
Message-ID:
        <CAA=[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset="utf-8"

Zafar, et al,

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

Cheers,
Andy


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

> Dear Stewart, WG Chairs and the WG,
>
>
>
> I do not agree with Stewart?s points and will response in a separate
> email. But all that is just noise and that cannot resolve the issue at
> hand.
>
>
>
> A countless time, Xiaohu has raised the issue that the intellectual
> property for the contents in section 6 of draft-farrel-mpls-sfc belongs to
> draft-xu-mpls-service-chaining. Please see one of Xiaohu's recent emails
> with the subject *"[spring] For the fairness and justice of the IETF
> culture"* dated Thursday, April 5, 2018 at 12:34 AM, copied in the
> following.
>
>
>
> This issue was also raised by many during the WG adoption poll of the
> document. The chairs adopted the work with the promise of fixing the issue.
> Specifically, in the email to announce the adoption of the ID to the WG,
> the chair(s) mentioned the following:
>
>
>
> "That decision is taken, the issues that has been pointed out are
>
> noted. These issues need to be resolved on the mailing list and
>
> rough consensus need to be reached for text changes in the document.
>
> Actually the members of the working group have much more influence on
>
> a working group document, than on an individual draft.
>
> It would be far better if we now focused on proposing text changes,
>
> rather than discussing processes."
>
>
>
> This is a serious issue; we need to remove section 6 from draft-
> farrel-mpls-sfc to move forward. These contents will proceed in draft-xu*,
> where the contents started initially. Everyone will have a fair chance to
> contribute to the contents as part of collaborations on draft-xu*.
>
>
>
> Thanks
>
>
>
> Regards ? Zafar
>
>
>
> *From: *spring <[e-mail]<mailto:[e-mail]>> on behalf of "???(??)" <
> [e-mail]<mailto:[e-mail]>>
> *Date: *Thursday, April 5, 2018 at 12:34 AM
> *To: *"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, SPRING WG List <[e-mail]<mailto:[e-mail]>>
> *Cc: *"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
> *Subject: *[spring] For the fairness and justice of the IETF culture//Re:
> [mpls] What to do with draft-ietf-mpls-sfc-00.txt
>
>
>
> Hi all,
>
>
>
> As I had pointed out before, this draft describes two MPLS-based SFC
>
> approaches: one is how to encode the NSH info, more specifically, the SPI
>
> and SI info by two MPLS labels, which is still a stateful SFC mechanism
>
> just like NSH; another is how to leverage the MPLS-SR to realize a
>
> stateless SFC (see section 6).
>
>
>
> It has been pointed out by many people that section 6 of the draft copies
>
> the
>
> idea of (https://tools.ietf.org/html/draft-xu-mpls-service-chaining)
>
> without any technology contribution except replacing ?MPLS Segment
>
> Routing? by ?Label Stack?. Funnily, one author of draft-ietf-mpls-sfc
>
> had inadvertently admitted
>
> "using a different name for the same thing is not so clever" (see
>
> https://mailarchive.ietf.org/arch/msg/mpls/y7FTc38ysVf6PyJlA04MEFSN9nc) in
>
> another thread.
>
>
>
> IMHO, the indulgence towards such behavior of copying
>
> ideas of existing drafts with word tricks would seriously trample
>
> underfoot the fairness and justice of the IETF culture. At least, it would
>
> badly damage the interest and enthusiasm of IETF participants, especially
>
> newcomers and non-native speakers of English.
>
>
>
> Best regards,
>
> Xiaohu
>
>
>
>
>
>
>
>
>
> *From: *mpls <[e-mail]<mailto:[e-mail]>> on behalf of Stewart Bryant <
> [e-mail]<mailto:[e-mail]>>
> *Date: *Friday, April 13, 2018 at 3:10 AM
> *To: *"???(??)" <[e-mail]<mailto:xiaohu.xxh@alibaba-inc..com>>
> *Cc: *"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, mpls <[e-mail]<mailto:[e-mail]>>,
> Robert Raszuk <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
> *Subject: *Re: [mpls] [sfc] Working Group adoption of
> draft-farrel-mpls-sfc
>
>
>
>
>
>
>
> On 13/04/2018 08:23, ???(??) wrote:
>
> Hi Stewart,
>
>
>
> Thanks for your response. For the SR-based SFC mechanism that has been
> described in draft-xuclad*, it's not helpful to describe it again in
> another draft. The most simple and efficient way to address the
> overlapping issue is to reference draft-xuclad* rather than
> "using a different name for the same thing". I'm looking forward to
> seeing the revision of draft-farrel* that would address the overlapping
> issue concretely.
>
>
> Please read what I said.
>
> There are subtle but important technical differences between the two
> approaches.
>
> - Stewart
>
>
>
>
> If co-authors of draft-farrel* believed the current text as described in
> draft-xuclad* is not good enough or misses something important, any
> comments and suggestions are more than welcome.
>
>
> I will send you some text to include in draft-xuclad that points to the
> important differences in the approach taken in draft-farrel. This will
> clarify the issue to the reader.
>
> I hope that this is an acceptable resolution of this issue.
>
> - Stewart
>
>
>
>
>
> Best regards,
>
> Xiaohu
>
> ------------------------------------------------------------------
>
> Stewart Bryant <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>
>
> 2018?4?13?(???) 13:27
>
> ???(??) <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>
>
> mpls <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>; "Bernier, Daniel"
> <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>; Robert Raszuk
> <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>
>
> Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc
>
>
>
> Hi Xiaohu
>
>
>
> What an earlier version of the draft said is of no importance. What it
> says going forward is what counts.
>
>
>
> Perhaps the way to address your concern is to include some text of the
> form that I used in my email of yesterday to describe to the reader the
> difference in approach. This is consistent with earlier advice in this
> discussion to reference the work from which this forked.
>
>
>
> - Stewart
>
>
>
>
>
> Sent from my iPad
>
>
> On 13 Apr 2018, at 03:35, ???(??) <[e-mail]<mailto:[e-mail]>> wrote:
>
> Hi Stewart,
>
>
>
> If draft-farrel* was just describing an MPLS-based SFC technology that is
> different from the MPLS-SR-based SFC technology that has been described in
> draft-xuclad*, that would be fine. However, draft-farrel* also described
> the technology that has been described in draft-xuclad* (see section 6) by
> "using a different name for the same thing". Note that the title of
> section 6 in those pervious versions of draft-farrel* is
>
> "MPLS Segment Routing". One co-author of draft-farrel* said they worked very hard to change the "Segment Routing" term to "label stack" term in the new version of draft-farrel* in order to deal with the overlapping issue. However, such change is just "using a different name for the same thing", and it doesn't solve the overlapping issue at all, as had been pointed out by many people. As said by one co-author of draft-farrel*, in a thread which is irrelavant to this overlapping issue, "using a different name for the same thing is not so clever:)". In fact, it would cause unneccessary confusions to implementors by describing the same technology within different drafts. More badly, it would set a bad precedant in the IETF of copying the idea of the existing draft by "using a different name for the same thing".
>
>
>
> Best regards,
>
> Xiaohu
>
> ------------------------------------------------------------------
>
> Stewart Bryant <[e-mail]<mailto:[e-mail]>>
>
> 2018?4?12?(???) 23:04
>
> "Bernier, Daniel" <[e-mail]<mailto:[e-mail]>>; Robert Raszuk <
> [e-mail]<mailto:[e-mail]>>
>
> [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
>
> Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc
>
>
>
>
> Rather than have a process discussion, I think we should go up a level
> and better understand the technical differences between the two drafts..
>
> draft-farrel-mpls-sfc describes the actions at a hop in terms of a tuple
> that mirrors the SFC approach that allows a short indication of
> potentially re-entrant chains. In its simplest form it uses a compact
> MPLS stack to describe an arbitarily complex path that is compatile with
> simple edge routers which are often challenged in terms of the number of
> labels that they can push.
>
> draft-xu-clad-spring-sr-service-chaining unrolls the path and explicitly
> calls out each hop and each function into the label stack. This results
> in a much larger MPLS label stack that will challenge some edge routers.
> The way that we generally deal with imposition limits is through the use
> of binding-SIDs, which in the limiting case resolves to the approach in
> draft-farrel with the limitation that the position on the path is
> implicit in the label stack size rather than explicitly
> specified by the SI.
>
> Mid-flight path changes (if such things are needed) is clearly simpler
> with draft-farrel.
>
> The short stack in draft-farrel comes at the cost of greater network
> forwarding stack, and the long stack is the price that draft-xu-clad
> pays for the reduction in forwarding state.
>
> The optimal design point between forwarding and control plane state is
> something that is dependent on many parameters, and is dependent on many
> network and operational factors, so much so, that don't think it is wise
> to rule either out of scope at this stage.
>
> The hybrid mode in section 6 of draft-farrel supports the mixed mode in
> section 7 of the draft. This allows the construction of SFCs that are
> the concatination of two or more compacted sub-chains. This allows the
> operator to deploy a solution with the advantages of draft-farrel
> together with some of the flexibility of draft-xu-clad.
>
> At this stage the two drafts are sufficienly different that I think we
> need to proceed with both at least to the point where we fully
> understand the detailed consequences of the two approachs and the
> scenarios where each finds it's niche.
>
> After developing a better understanding the detail of each design, their
> control plane, and operational contexts and how each maps to customer
> network requirements, we can move the drafts to the appropriate IETF
> track. Such tracks may be anything from abandonment to IETF standard for
> one or both of these approaches.
>
> Meanwhile I think that we need to focus our efforts on a deeper
> understanding of the technology and how each might make the Internet
> work better,  rather than spending effort on arguing about IETF process.
>
> - Stewart
>
> _______________________________________________
> mpls mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/mpls/attachments/20180415/9a47c611/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls


------------------------------

End of mpls Digest, Vol 168, Issue 18
*************************************


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.