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

["Zafar Ali (zali)" <[e-mail]>]

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 <[e-mail]> on behalf of Brian E Carpenter <[e-mail]>
Organization: University of Auckland
Date: Thursday, April 5, 2018 at 1:05 AM
To: "徐小虎(义先)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, SPRING WG List <[e-mail]>, "[e-mail]" <[e-mail]>
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"
<[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> 写入:
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:[e-mail]] On Behalf Of internet-
[e-mail]<mailto:[e-mail]>
Sent: 04 April 2018 10:28
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls

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

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