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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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-bounces@xxxxxxxx> on behalf of Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
Organization: University of Auckland
Date: Thursday, April 5, 2018 at 1:05 AM
To: "徐小虎(义先)" <xiaohu.xxh@xxxxxxxxxxxxxxx>
Cc: "mpls@xxxxxxxx" <mpls@xxxxxxxx>, SPRING WG List <spring@xxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx>
Subject: Re: [mpls] For the fairness and justice of the IETF culture//Re: What to do with draft-ietf-mpls-sfc-00.txt

 

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

 

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

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

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"

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-

Sent: 04 April 2018 10:28

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:

 

There are also htmlized versions available at:

 

 

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:

 

_______________________________________________

mpls mailing list

 

_______________________________________________

mpls mailing list

 

_______________________________________________

mpls mailing list

 

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux