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 <mpls-boun...@ietf.org> on behalf of Brian E Carpenter <brian.e.carpen...@gmail.com> Organization: University of Auckland Date: Thursday, April 5, 2018 at 1:05 AM To: "徐小虎(义先)" <xiaohu....@alibaba-inc.com> Cc: "m...@ietf.org" <m...@ietf.org>, SPRING WG List <email@example.com>, "i...@ietf.org" <i...@ietf.org> Subject: Re: [mpls] For the fairness and justice of the IETF culture//Re: What to do with draft-ietf-mpls-sfc-00.txt 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 On 05/04/2018 16:34, 徐小虎(义先) wrote: 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" <mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org> on behalf of adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> 写入: 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:mpls-boun...@ietf.org] On Behalf Of internet- dra...@ietf.org<mailto:dra...@ietf.org> Sent: 04 April 2018 10:28 To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> Cc: m...@ietf.org<mailto:m...@ietf.org> 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 m...@ietf.org<mailto:m...@ietf.org> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list m...@ietf.org<mailto:m...@ietf.org> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list m...@ietf.org<mailto:m...@ietf.org> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________ spring mailing list firstname.lastname@example.org https://www.ietf.org/mailman/listinfo/spring