Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 22 February 2019 16:43 UTC

Return-Path: <jmh@joelhalpern.com>
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 C1305129284; Fri, 22 Feb 2019 08:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 Z4Wz0SBfK-2s; Fri, 22 Feb 2019 08:43:40 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B550130ECD; Fri, 22 Feb 2019 08:43:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 445cbv0LRgzZs6Z; Fri, 22 Feb 2019 08:43:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1550853819; bh=kjuMZqpGXP0kS5zroOd1LrNlFR4hd2ZlF5zx0BhRkvk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=a+4dfDy6CNo2jjbU7q3U85gqQcMRhq9j0dxqc7jGJEt54crocdZU/pXLdk8OCOLJN C7vatIqxJ+j7oMdQNavV7yUAEtQ39L6J9ClqhNbQBCXqg3kAoTokl4OStVwGljx208 Y9hXYLWGvZqWqpXsBjTqqk4gv+ZCOL4y2BwALlwA=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 445cbs5FDMzKnJL; Fri, 22 Feb 2019 08:43:37 -0800 (PST)
To: "Andrew G. Malis" <agmalis@gmail.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: mpls <mpls@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-ietf-mpls-sfc-encapsulation.all@ietf.org" <draft-ietf-mpls-sfc-encapsulation.all@ietf.org>, IETF Discussion <ietf@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
References: <155072147698.20210.381511429964485828@ietfa.amsl.com> <CAA=duU0sWgRERuqCBBt6cmWOETNz5vhzNDdiVB1nYSz_2YsLcg@mail.gmail.com> <6A97863A-DD90-4D62-9607-569386F5F850@cisco.com> <CAA=duU2zwNY5=AhqT915cJP2hTFwyO85O1vNR0HvUV6qz21HkA@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <03769b15-8375-a23a-a882-0a183056a8b5@joelhalpern.com>
Date: Fri, 22 Feb 2019 11:43:36 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CAA=duU2zwNY5=AhqT915cJP2hTFwyO85O1vNR0HvUV6qz21HkA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/pixcTJHNz92n1SBvTUttLA18zMU>
Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02
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: Fri, 22 Feb 2019 16:43:44 -0000

My comment on this may not have made it to everyone.  If you receive a 
duplicate, I apologize  (I received DMARC errors from something about 
translations from the draft.all address to gmail addresses.)

Speaking as a co-author...

It is not at all clear to me that GTSM applies or how it would apply. 
There is no requirement that successive SFF be one MPLS hop apart.

Yours,
Joel

On 2/22/19 9:27 AM, Andrew G. Malis wrote:
> Carlos,
> 
> Looks good on all but one point - I think I see why you're referencing 
> GTSM, since packets at the SFC layer would generally be one hop away 
> from each other at that layer. Is that correct? However, I really don't 
> have sufficient experience with GTSM to craft specific text. If you 
> think it's important enough to include, could you propose some text for 
> me to include?
> 
> Thanks again,
> Andy
> 
> 
> On Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata) 
> <cpignata@cisco.com <mailto:cpignata@cisco.com>> wrote:
> 
>     Hi, Andy,
> 
>>     On Feb 21, 2019, at 1:06 PM, Andrew G. Malis <agmalis@gmail.com
>>     <mailto:agmalis@gmail.com>> wrote:
>>
>>     Carlos,
>>
>>     Many thanks for your review! I'm also including the SFC WG on my
>>     reply.
> 
>     Thanks for the quick response, and for considering the comments!
> 
>     I enjoyed reading this document — please see below.
> 
>>
>>     Comments inline.
>>
>>     On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro
>>     <cpignata@cisco.com <mailto:cpignata@cisco.com>> wrote:
>>
>>         Reviewer: Carlos Pignataro
>>         Review result: Has Issues
>>
>>         Reviewer: Carlos Pignataro
>>         Review Result: Has Issues
>>
>>         I have reviewed this document as part of the Operational
>>         directorate's
>>         ongoing effort to review all IETF documents being processed by
>>         the IESG.  These
>>         comments were written with the intent of improving the
>>         operational aspects of
>>         the IETF drafts. Comments that are not addressed in last call
>>         may be included
>>         in AD reviews during the IESG review.  Document editors and WG
>>         chairs should
>>         treat these comments just like any other last call comments.
>>
>>         This document is highly readable, includes very clear textual
>>         descriptions, and
>>         is very well organized. Easy to read in its simplicity.
>>         However, it would
>>         benefit from a more explicit connection to the transport encap
>>         mechanics from
>>         RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding
>>         a Figure or an
>>         SFF NSH Mapping Table example, to depict and/or exemplify the
>>         SFF function.
>>
>>
>>     I'm trying to envision what would make a good figure here. We
>>     could add an additional line to Table 1 of RFC 8300 and reference
>>     that table:
>>
>>            +------+------+---------------------+-------------------------+
>>            | SPI  | SI   | Next Hop(s)         | Transport Encapsulation |
>>            +------+------+---------------------+-------------------------+
>>            | 25   | 220  | Label 5467          | MPLS                    |
>>            +------+------+---------------------+-------------------------+
>>
>>     Is that what you had in mind? If not, I'm open to other suggestions.
> 
>     If you think it helps, this would be a good addition.
> 
>>
>>         >From an Operational standpoint, the document seems largely
>>         appropriate in terms
>>         of dataplane considerations. Some key considerations are
>>         explicitly out of
>>         scope:
>>            The method used by the downstream receiving node to
>>         advertise SFF
>>            Labels to the upstream sending node is out of scope of this
>>         document.
>>
>>         This really seems to mean that, with the simple definition in this
>>         Informational document, interoperable implementations cannot
>>         yet exist. If
>>         there is no mechanism to advertise the SFF Label or to manage
>>         the semantics of
>>         this particular label, how will it know? Static configuration,
>>         which is not
>>         covered anyway, is not in my humble opinion a manageable
>>         scalable approach.
>>
>>
>>     Actually, while it is outside the scope of this document, it is
>>     within the scope of draft-ietf-bess-nsh-bgp-control-plane, and
>>     text is being added to the next revision of that draft to show how
>>     it can be used to signal the encapsulation defined here. This was
>>     worked out after this draft was forwarded to the IESG, but we can
>>     now add a reference to that draft seeing as we'll be doing a
>>     post-last-call update.
> 
>     I think that will help, as an Informative “one embodiment” type of link.
> 
>>
>>         Title: MPLS Encapsulation For The SFC NSH
>>
>>         RFC 8300 makes an explicit distinction between the terms
>>         'encapsulation' and
>>         'transport encapsulation' (see e.g., Figure 1, Section 1.5 5.,
>>         and Section 4 of
>>         RFC 8300).
>>
>>         It seems to me that this is the "MPLS Transport Encapsulation
>>         for the SFC NSH"
>>
>>
>>     Thanks, we'll fix that.
>>
>>
>>         2.  MPLS Encapsulation Using an SFF Label
>>
>>         Similarly, "2. MPLS Transport Encapsulation Using an SFF Label"
>>
>>            The encapsulation is a standard MPLS label stack [RFC3032]
>>         with an
>>            SFF Label at the bottom of the stack, followed by a NSH as
>>         defined by
>>            [RFC8300] and the NSH payload.
>>
>>         Insteadf of "NSH payload" I think "orignal packet" is meant.
>>
>>
>>     RFC 8300 uses both "payload" and "original packet/frame", but the
>>     latter more than the former. So we can change "payload" to
>>     "original packet/frame".
>>
>>
>>         Also, this encapsulation is Underdefined: What is the value of
>>         TTL? TC?
>>
>>
>>     I've been looking back at other related RFCs (such as PW and IP
>>     VPN label definitions) and they're also mostly silent on these
>>     values. I did find the following in RFC 6073:
>>
>>         The setting of the TTL of the PW MPLS
>>         label is a matter of local policy on the originating PE, but SHOULD
>>         be set to 255.
>>
>>     Regarding the TC, we can follow the example of RFC 6391:
>>
>>         This document does not define a use for the Traffic Class (TC) field
>>         [RFC5462  <https://tools.ietf.org/html/rfc5462>] (formerly known as the Experimental Use (EXP) bits
>>         [RFC3032  <https://tools.ietf.org/html/rfc3032>]) in the flow label.  Future documents may define a use for
>>         these bits; therefore, implementations conforming to this
>>         specification MUST set the TC field to zero at the ingress and MUST
>>         ignore them at the egress.
>>
>>     Do you have any alternative suggestions?
> 
>     These two approaches sounds good to me. And Ack to the other
>     previous responses.
> 
>>
>>            Much like a pseudowire label, an SFF Label is allocated by the
>>            downstream receiver of the NSH from its per-platform label
>>         space.
>>
>>         A PW Label is more restrictive. RFC 8077 says it MUST be
>>         allocated as
>>         per-platform:
>>
>>            egress LSR only.  Note that the PW label must always be at
>>         the bottom
>>            of the packet's label stack, and labels MUST be allocated
>>         from the
>>            per-platform label space.
>>
>>         Is this the case for the SFF Label as well? If so, what is the
>>         implication of
>>         the MUST? If not, why is it different than other equivalent
>>         similar labels?
>>
>>
>>     We can change the text to:
>>
>>      Much like a pseudowire label, an SFF Label MUST be allocated by
>>     the downstream receiver of the NSH from its per-platform label
>>     space, since the meaning of the label is identical independent of
>>     which incoming interface it is received [RFC3031].
>>
> 
>     That’s a great improvement.
> 
>>
>>            2.  Push the SFF Label to identify the desired SFF in the
>>         receiving
>>                MPLS node.
>>
>>         TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here.
>>
>>
>>     As I noted above, 255, although I used RFC 6073 as my source
>>     rather than 5082. We'll add that here as well.
>>
> 
>     Sounds good.
>     These protocols use 5082 in one form or another:
>     https://datatracker.ietf.org/doc/rfc5082/referencedby/
> 
>>
>>         4.  Operations, Administration, and Maintenance (OAM)
>>         Considerations
>>
>>            OAM at the SFC Layer is handled by SFC-defined mechanisms
>>         [RFC8300].
>>            However, OAM may be required at the MPLS transport layer. 
>>         If so,
>>            then standard MPLS-layer OAM mechanisms such as the Generic
>>            Associated Channel [RFC5586] label may be used.
>>
>>         RFC 5586 is _not_ an OAM mechanism. It is an associated
>>         channel creation
>>         mechanism, over which OAM could be carried.
>>
>>         Thus, what traditional MPLS OAM can be carried here? Things
>>         like RFC 4379 / RFC
>>         8029 would need the definition of an SFF Label FEC (which does
>>         not exist).
>>         Which other one? IP/ICMP seems of very limited value.
>>
>>
>>     That's a good point about RFC 5586. The intention is that the MPLS
>>     OAM would be at the transport label layer above the SFF label, so
>>     most any MPLS-layer OAM would be applicable. So how about
>>     rewording to make that more clear:
>>
>>     OAM at the SFC Layer is handled by SFC-defined mechanisms
>>     [RFC8300]. However, OAM may be required at the MPLS transport
>>     layer.  If so, then standard MPLS-layer OAM mechanisms may be used
>>     at the transport label layer (the labels above the SFF label).
> 
>     Looks good to me, thank you.
> 
>>
>>
>>         6.  Security Considerations
>>
>>         Have you considered the use of GTSM?
>>
>>
>>     No, we hadn't. Can you point me to any examples of GTSM being used
>>     in an MPLS or PW context?
> 
>     Yes, see above.
> 
>>
>>         8.  References
>>
>>            [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service
>>         Function
>>                       Chaining (SFC) Architecture", RFC 7665,
>>                       DOI 10.17487/RFC7665, October 2015,
>>                       <https://www.rfc-editor.org/info/rfc7665
>>         <https://www..rfc-editor.org/info/rfc7665>>.
>>
>>         SHould RFC 7665 be Normative? It defines the "SFF" which is
>>         quite central to
>>         understanding this document.
>>
>>
>>     Good point. It was there because 7665 is an Informational RFC, but
>>     RFC 8067 does allow normative references to informational RFCs, so
>>     I'll move it.
> 
>     Thank you.
> 
>>
>>         Other Nits and Editorials:
>>
>>            SFF Labels are similar to other service labels at the
>>         bottom of an
>>            MPLS label stack that denote the contents of the MPLS
>>         payload being
>>            other than IP, such as a layer 2 pseudowire, an IP packet
>>         that is
>>            routed in a VPN context with a private address, or an Ethernet
>>            virtual private wire service.
>>
>>         This says "being other than IP, such as IP", which seems to be
>>         self-contradictory :-)
>>
>>     :-)
>>
>>     How about we change "other than IP," to "other than a normally
>>     routed IP packet”,
> 
>     That would disambiguate it.
> 
>     Thanks again.
> 
>     To me, the control plane / advertisement was the most important
>     operationally-relevant comment.
> 
>     Thanks,
> 
>     Carlos.
> 
>>
>>     Thanks again,
>>     Andy
>