Re: [mpls] New version: draft-ietf-mpls-sfc-03.txt

Loa Andersson <loa@pi.nu> Wed, 17 October 2018 13:34 UTC

Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519A4130DC8 for <mpls@ietfa.amsl.com>; Wed, 17 Oct 2018 06:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGY7ZcygladL for <mpls@ietfa.amsl.com>; Wed, 17 Oct 2018 06:34:55 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77751277C8 for <mpls@ietf.org>; Wed, 17 Oct 2018 06:34:54 -0700 (PDT)
Received: from [192.168.1.20] (unknown [119.94.168.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BA8F8180121E; Wed, 17 Oct 2018 15:34:48 +0200 (CEST)
To: adrian@olddog.co.uk, mpls@ietf.org
References: <017501d4630f$15fa9530$41efbf90$@olddog.co.uk> <19b32d43-6404-918a-96ed-a2aabd9d0f5e@pi.nu> <069301d4660b$e99e3500$bcda9f00$@olddog.co.uk>
From: Loa Andersson <loa@pi.nu>
Message-ID: <1afa4cf8-118f-1fd9-d01f-a55c6835e787@pi.nu>
Date: Wed, 17 Oct 2018 21:34:36 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <069301d4660b$e99e3500$bcda9f00$@olddog.co.uk>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/AiW8AGyecQBaFJ4jiKwPuf0ARow>
Subject: Re: [mpls] New version: draft-ietf-mpls-sfc-03.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2018 13:34:58 -0000

Adrian, authors,

Yes I'd say you are OK to start the wglc process.

Normally that involves:
- sheperd review (updates as necessary)
- IPR poll
- wglc (updates as mecessary)

I normally start the IPR poll as soon as I'm convinced that we
will do the wglc on the current version (maybe +1)



/Loa

On 2018-10-17 19:24, Adrian Farrel wrote:
> Thanks Loa,
> 
> Not hearing any raised voices on this, we probably leave the text as it is (with an extended special purpose label).
> 
> What's next, chairs? Are we good for WG last call?
> 
> Thanks,
> Adrian
> 
>> -----Original Message-----
>> From: Loa Andersson [mailto:loa@pi.nu]
>> Sent: 14 October 2018 05:29
>> To: adrian@olddog.co.uk; mpls@ietf.org
>> Subject: Re: [mpls] New version: draft-ietf-mpls-sfc-03.txt
>>
>> Adrian, Authors, working group,
>>
>> Speaking as someone that has to manage the rather scarce pool of
>> "regular" special purpose labels.
>>
>> If there is no compelling reason to use the "regular" special purpose
>> labels, I'd say that we stay with the extended special purpose label.
>>
>> /Loa
>>
>> On 2018-10-14 00:09, Adrian Farrel wrote:
>>> Hi,
>>>
>>> The update here is just to fix an email address and a reference.
>>>
>>> >From my point of view this work is done with just one open question for the
>>> WG...
>>>
>>> Currently we use an extended special purpose label to identify that SFC labels
>>> follow. The question is: is this work sufficiently mainstream to use a regular
>>> special purpose label?
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Adrian
>>>> -----Original Message-----
>>>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>>>> internet-drafts@ietf.org
>>>> Sent: 13 October 2018 17:05
>>>> To: i-d-announce@ietf.org
>>>> Cc: mpls@ietf.org
>>>> Subject: I-D Action: draft-ietf-mpls-sfc-03.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-03.txt
>>>> 	Pages           : 28
>>>> 	Date            : 2018-10-13
>>>>
>>>> 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-03
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc-03
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sfc-03
>>>>
>>>>
>>>> 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/
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> I-D-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>
>> --
>>
>>
>> Loa Andersson                        email: loa@pi.nu
>> Senior MPLS Expert
>> Bronze Dragon Consulting             phone: +46 739 81 21 64
> 

-- 


Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64