Andy,
The chairs of the SPRING and MPLS wg has discussed the proposal to
adopt draft-xuclad-spring-sr-service-chaining in the MPLS wg.
Our agreement is that draft-xuclad-spring-sr-service-chaining
belongs in the SPRING wg.
/Loa
for the SPRING and MPLS wg co-chairs
On 2018-04-15 16:55, Andrew G. Malis wrote:
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) <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> on behalf of "徐小虎(义先)"
<[email protected] <mailto:[email protected]>>
*Date: *Thursday, April 5, 2018 at 12:34 AM
*To: *"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, SPRING WG List <[email protected]
<mailto:[email protected]>>
*Cc: *"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
*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
<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
<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 <[email protected] <mailto:[email protected]>>
on behalf of Stewart Bryant <[email protected]
<mailto:[email protected]>>
*Date: *Friday, April 13, 2018 at 3:10 AM
*To: *"徐小虎(义先)" <[email protected]
<mailto:[email protected]>>
*Cc: *"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, mpls <[email protected]
<mailto:[email protected]>>, Robert Raszuk <[email protected]
<mailto:[email protected]>>, "[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>
*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
<[email protected]><mailto:[email protected]>____
2018年4月13日(星期五) 13:27____
徐小虎(义先)
<[email protected]><mailto:[email protected]>____
mpls <[email protected]><mailto:[email protected]>;
"Bernier, Daniel"
<[email protected]><mailto:[email protected]>;
Robert Raszuk <[email protected]><mailto:[email protected]>;
[email protected]<mailto:[email protected]><[email protected]><mailto:[email protected]>;
[email protected]<mailto:[email protected]><[email protected]><mailto:[email protected]>____
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, 徐小虎(义先)
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>>____
2018年4月12日(星期四) 23:04____
"Bernier, Daniel"
<[email protected]<mailto:[email protected]>>;
Robert Raszuk <[email protected]<mailto:[email protected]>>____
[email protected]<mailto:[email protected]><[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]><[email protected]<mailto:[email protected]>>____
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>____
__ __
_______________________________________________
mpls mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>____
__ __
____
_______________________________________________
mpls mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/mpls
<https://www.ietf.org/mailman/listinfo/mpls>
_______________________________________________
mpls mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mpls
--
Loa Andersson email: [email protected]
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
