Subject: [spring] For the fairness and justice of the IETF culture//Re: [mpls] What to do with draft-ietf-mpls-sfc-00.txt

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 05 Apr 2018 12:34:19 +0800

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

在 2018/4/5 上午1:05， "mpls on behalf of Adrian Farrel"
<[email-masked] on behalf of [email-masked]> 写入:

>WG,
>
>Would it help if we added use cases to this document? Usually, the IESG
>frowns
>on use cases, but it sounds as though this document needs some further
>explanation.
>
>Of course, not everyone likes every proposed use case. Some will say, "I
>don't
>need that." Others will say, "I have another way, or I prefer a different
>way,
>of achieving that."
>
>Adding such a section would allow the inclusion of some text saying
>(something
>like) "A use case is to achieve SFC in an MPLS-SR network, but that is
>discussed
>in draft-xuclad-spring-sr-service-chaining."
>
>
>Additionally, I have been wondering how to handle the discussion of using
>this
>function in a brownfield network. Normally we don't tell people in our
>specs how
>to build their boxes - we make protocol specs not design documents.
>However, if
>in addition to how I would build this, I can see a (somewhat clunky)
>method to
>achieve this function in existing platforms, would it be worth adding
>that?
>
>Cheers,
>Adrian
>
>> -----Original Message-----
>> From: mpls [mailto:[email-masked]] On Behalf Of internet-
>> [email-masked]
>> Sent: 04 April 2018 10:28
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [mpls] I-D Action: draft-ietf-mpls-sfc-00.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>> This draft is a work item of the Multiprotocol Label Switching WG of
>>the IETF.
>> 
>>         Title           : An MPLS-Based Forwarding Plane for Service
>>Function
>Chaining
>>         Authors         : Adrian Farrel
>>                           Stewart Bryant
>>                           John Drake
>> 	Filename        : draft-ietf-mpls-sfc-00.txt
>> 	Pages           : 24
>> 	Date            : 2018-03-28
>> 
>> Abstract:
>>    Service Function Chaining (SFC) is the process of directing packets
>>    through a network so that they can be acted on by an ordered set of
>>    abstract service functions before being delivered to the intended
>>    destination.  An architecture for SFC is defined in RFC7665.
>> 
>>    The Network Service Header (NSH) can be inserted into packets to
>>    steer them along a specific path to realize a Service Function Chain.
>> 
>>    Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
>>    technology that uses labels placed in a packet in a label stack to
>>    identify the forwarding actions to be taken at each hop through a
>>    network.  Actions may include swapping or popping the labels as well,
>>    as using the labels to determine the next hop for forwarding the
>>    packet.  Labels may also be used to establish the context under which
>>    the packet is forwarded.
>> 
>>    This document describes how Service Function Chaining can be achieved
>>    in an MPLS network by means of a logical representation of the NSH in
>>    an MPLS label stack.  It does not deprecate or replace the NSH, but
>>    acknowledges that there may be a need for an interim deployment of
>>    SFC functionality in brownfield networks.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-mpls-sfc-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc-00
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>>submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Apr 2018 17:05:23 +1200

I absolutely cannot comment on this specific case, but the normal
and polite way to handle such a situation is a clear reference
to the older draft, and some text such as "A very similar proposal
was originally made by XXX in [reference]." That would apply both
to an earlier IETF contribution or to any external publication.

In a complicated case, a whole section of the document might be
appropriate, e.g. https://tools.ietf.org/html/rfc6740#section-1.2

Regards
   Brian Carpenter

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 5 Apr 2018 05:54:29 +0000

Hi Brian,

I agree with what you mentioned, and particularities of this case are similar.

In this particular case, the problem can easily be solved by removing section 6 (which is covered by draft-xu-mpls-service-chaining).

This issue was raised during the WG adoption of the document. In the email to announce the adoption of the document 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."

IMO, WG should take this proposed change to resolve the contention.

Thanks

Regards … Zafar

From: mpls <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Organization: University of Auckland
Date: Thursday, April 5, 2018 at 1:05 AM
To: "徐小虎(义先)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mpls] For the fairness and justice of the IETF culture//Re: What to do with draft-ietf-mpls-sfc-00.txt

Regards
   Brian Carpenter

在 2018/4/5 上午1:05， "mpls on behalf of Adrian Farrel"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 写入:
WG,

Cheers,
Adrian

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of internet-
[email-masked]<mailto:[email-masked]>
Sent: 04 April 2018 10:28
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [mpls] I-D Action: draft-ietf-mpls-sfc-00.txt

Abstract:

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

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

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