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

在 2018/4/5 上午1:05， "mpls on behalf of Adrian Farrel"
<mpls-bounces@ietf.org on behalf of adrian@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-bounces@ietf.org] On Behalf Of internet-
>> drafts@ietf.org
>> Sent: 04 April 2018 10:28
>> To: i-d-announce@ietf.org
>> Cc: mpls@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
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>
>_______________________________________________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls