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

["Zafar Ali (zali)" <[e-mail]>]

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]> on behalf of "徐小虎(义先)" <[e-mail]>
Date: Thursday, April 5, 2018 at 12:34 AM
To: "[e-mail]" <[e-mail]>, SPRING WG List <[e-mail]>
Cc: "[e-mail]" <[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]> on behalf of Stewart Bryant <[e-mail]>
Date: Friday, April 13, 2018 at 3:10 AM
To: "徐小虎(义先)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, mpls <[e-mail]>, Robert Raszuk <[e-mail]>, "[e-mail]" <[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]>
2018年4月13日(星期五) 13:27
徐小虎(义先) <[e-mail]><mailto:[e-mail]>
mpls <[e-mail]><mailto:[e-mail]>; "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

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