Re: [mpls] Alissa Cooper's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Thu, 07 March 2019 15:05 UTC

Return-Path: <alissa@cooperw.in>
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 CDA00127967; Thu, 7 Mar 2019 07:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=RxFwIVmY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1hITybRd
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 bm32HjnnClhG; Thu, 7 Mar 2019 07:05:11 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10322128664; Thu, 7 Mar 2019 07:05:11 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 115A636A2; Thu, 7 Mar 2019 10:05:09 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 07 Mar 2019 10:05:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=JVPt0BS9+yxUb/hPydcwclS s+A0D9JnxI4ZP3wZQeAQ=; b=RxFwIVmYSUroqE1/jI0ZJyFrahMT1vQZUoXVlHI HJeTEhKhCJPfCg8/0Dt+5sb27GjmpxTHUBEidKhhYWRlEDW1XOSd6G6dcYlfTONF 4yz7eFbr1YXx2D7JsbJbeGGASX22eBe029J4m0fzN5kdnWsKy89wZv0OwQSVNIIb 7ZUu99h06as+0YMThn+Fh4Af7vEh0c/Wz2jPND5HRzz1yJvheEN5DDEoR28DOHuK gWAAgGN09LsU49+4v9S9jaSAQraBcBodBuFYizIiKr2AAsrV3Wsb0cfrS4yKVt9J /532E4MqYCQZ6E1snro/6s3LEbqm6wFSUufZPX9QTK6vrcA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=JVPt0B S9+yxUb/hPydcwclSs+A0D9JnxI4ZP3wZQeAQ=; b=1hITybRdcg1djaV91HWT+r /KOo6QGXCVl0+rAn4DZwjEG2IAkTluX8XIazcTpFgp3XILGpJMI2TEdIjcb5E933 VtJzXUzkjEPdhxaE1k1zHTewpAJnnv5SHFT4x8KjrQUsaSzyws4gdOi6EYSs7yZ5 b4Wf9isTuYzgctSmp7+OpBywNxqRa9krAea+/jnzXRv1/YoreskfgGcUiTaMwGbi qN8Unx3YO9t1ijB7d4kiiNbW37m0YELrAqI6i1AuKeh11fjhjOQMg9+tVYssN9Op nHQMzvyPW4agldHOVJymj54Eok0Blj69FyyxkkZVFBDC0C7WdQmxciUGIWNBpACA ==
X-ME-Sender: <xms:IzOBXBk5HnhDL_VtQBb8m8XXrN4r0UTvJeFEDv13S7Vnqmgtb5jciw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeekgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucfkphepudejfe drfeekrdduudejrdejgeenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegt ohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:IzOBXNgz5iuuQBMYU6XQLmKCh8LztJ0VSCrpE7XMH_-fKTVpa0Wf4Q> <xmx:IzOBXF33bOZ9n9xdnL1mBzDrzICu32kcD-Y4WJwxxDgJN8z62mCJ7g> <xmx:IzOBXGJArATs6HcprflqLnnl_F6PP2Lx7QpnNtxc8bnAFrCvHSfm-A> <xmx:JDOBXAmfl2vycuX4mg8Y8Z994thzPA2ACcM6U5R1H-XQZwZgOJ0mEw>
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.74]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C1C710310; Thu, 7 Mar 2019 10:05:06 -0500 (EST)
From: Alissa Cooper <alissa@cooperw.in>
Message-Id: <C0BF305D-46ED-45D7-B2C8-3AEC1495D63E@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_381C6ADD-C769-42E4-98EF-118FEE8AF092"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 7 Mar 2019 10:05:03 -0500
In-Reply-To: <012901d4d4d8$60ea0180$22be0480$@olddog.co.uk>
Cc: Datatracker on behalf of Alissa Cooper <noreply@ietf.org>, IESG <iesg@ietf.org>, IETF MPLS List <mpls@ietf.org>, mpls-chairs@ietf.org, draft-ietf-mpls-sfc@ietf.org, loa@pi.nu
To: Adrian Farrel <adrian@olddog.co.uk>
References: <155193160518.13682.12438232337705583343.idtracker@ietfa.amsl.com> <012901d4d4d8$60ea0180$22be0480$@olddog.co.uk>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/OkuaiI4jZIDKoZdDlnnbIgjgsTs>
Subject: Re: [mpls] Alissa Cooper's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT)
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: Thu, 07 Mar 2019 15:05:20 -0000

Hi Adrian,

> On Mar 7, 2019, at 6:24 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 
> Hey Alissa,
> 
> Thanks for reading.

Any time.

> 
>> DISCUSS:
>> 
>> Comparing the requirements in RFC 8300 Section 8.1 under "Single Domain
>> Boundary" and the text in Section 15 of this document, it seems that the
>> mechanism specified in this document is not subject to the same normative
>> requirements as specified for the administrative boundaries of a network where
>> MPLS is used as the transport encapsulation for NSH. What is the reasoning for
>> that? I would have expected to see similar normative requirements here as in
>> RFC 8300 Section 8.1.
> 
> RFC 8300 is concerned with the forwarding plane, so (obviously) includes normative language about packet handling.
> But it is worth noting that the term used in 8.1 is "NSH domain".
> However, the reference is back to the general SFC architecture in RFC 7665. That's a more appropriate place to look for the constraints on deploying SFC systems.
> 
> 7665 defines an SFC-Enabled Domain as "A network or region of a network that implements SFC.  An SFC-enabled domain is limited to a single network administrative domain." We should note that an "administrative domain" is (probably?) not the same as a single AS: an administrative domain is often partitioned into multiple ASes.
> 
> We do say that "Discussion of the security properties of SFC networks can be found in [RFC7665].  Further security discussion for the NSH and its use is present in [RFC8300]." So we intend to inherit all the security and deployment constraints.

That should be made explicit then, in particular that the normative security requirements from those documents apply to this specification.

> 
> We also have...
>   o  The MPLS network is often considered to be a closed network such
>      that insertion, modification, or inspection of packets by an
>      outside party is not possible.  This is particularly pertinent in
>      the SFC context because [RFC7665] notes that "The architecture
>      described herein is assumed to be applicable to a single network
>      administrative domain."
> 
> We could maybe tighten this by clarifying the concept of a closed network. For example,
>   o  The MPLS network is often considered to be a closed network such
>      that insertion, modification, or inspection of packets by an
>      outside party is not possible.  MPLS networks are operated with
>      closed boundaries so that MPLS encapsulated packets are not 
>      admitted to the network, and MPLS headers are stripped before 
>      packets are forwarded from the network.  This is particularly 
>      pertinent in the SFC context because [RFC7665] notes that "The
>      architecture described herein is assumed to be applicable to a
>      single network administrative domain."  Furthermore, [RFC8300]
>      states that packets originating outside the SFC-enabled domain
>      MUST be dropped if they contain an NSH and packets exiting the 
>      SFC-enabled domain MUST be dropped if they contain an NSH.  These
>      constraints apply equally to the use of MPLS to encode a logical
>      representation of the NSH.

That works for me.

> 
>> COMMENT:
>> 
>> = Section 4.5 =
>> 
>> OLD
>> The application of SR to SFC was considered in early versions of the
>>  SR architecture [RFC8402] and the MPLS-SR specification
>>  [I-D.ietf-spring-segment-routing-mpls], but has since been moved out
>>  of those documents.
>> 
>> NEW
>> The application of SR to SFC was considered in early versions of the
>>  SR architecture [RFC8402] and the MPLS-SR specification
>>  [I-D.ietf-spring-segment-routing-mpls], but was not ultimately adopted.
>> 
>> (I think this is about the ideas, not the organization of documents.)
> 
> Well, yes and no. There are, in fact, a number of drafts working their way through the system that discuss the use of SR for SFC. Most of these documents are not fully mature, but their proponents remain confident that they will be adopted and become RFCs in the fullness of time. I could list...
> - draft-filsfils-spring-srv6-network-programming
> - draft-guichard-spring-nsh-sr
> - draft-xuclad-spring-sr-service-programming
> There are probably others.

This is not the impression the reader is left with from reading Section 4.5.

> 
> So, SFC is clearly in scope for SR and the SPRING charter explicitly says:
>  o Source-routed stateless service chaining using SR-MPLS
>     and SRv6 dataplanes.
> 
> We included the reference to draft-xuclad-spring-sr-service-chaining (now replaced by draft-xuclad-spring-sr-service-programming - we need to make an update!) and believe that and the text cover the point.

I wonder about the archival value of the second paragraph altogether, given the multiple streams of work on this. Perhaps it would make more sense to just add a sentence to the end of the first paragraph noting that implementation work was ongoing at the time of this writing, and drop the second paragraph.

Thanks,
Alissa

> 
> Cheers,
> Adrian