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-bounces@xxxxxxxx on behalf of adrian@xxxxxxxxxxxx> 写入: > >> 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-bounces@xxxxxxxx] On Behalf Of internet- >>> drafts@xxxxxxxx >>> Sent: 04 April 2018 10:28 >>> To: i-d-announce@xxxxxxxx >>> Cc: mpls@xxxxxxxx >>> 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 >>> mpls@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/mpls > > >
