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

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 07 March 2019 11:24 UTC

Return-Path: <adrian@olddog.co.uk>
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 C369713139D; Thu, 7 Mar 2019 03:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 rWOwpVkQiEhq; Thu, 7 Mar 2019 03:24:55 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 082B5131391; Thu, 7 Mar 2019 03:24:54 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27BOq3k027539; Thu, 7 Mar 2019 11:24:52 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6091B22048; Thu, 7 Mar 2019 11:24:52 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 539B422042; Thu, 7 Mar 2019 11:24:52 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27BOomX026264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 11:24:51 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Datatracker on behalf of Alissa Cooper'" <noreply@ietf.org>, "'The IESG'" <iesg@ietf.org>
Cc: <draft-ietf-mpls-sfc@ietf.org>, "'Loa Andersson'" <loa@pi.nu>, <mpls-chairs@ietf.org>, <loa@pi.nu>, <mpls@ietf.org>
References: <155193160518.13682.12438232337705583343.idtracker@ietfa.amsl.com>
In-Reply-To: <155193160518.13682.12438232337705583343.idtracker@ietfa.amsl.com>
Date: Thu, 7 Mar 2019 11:24:49 -0000
Organization: Old Dog Consulting
Message-ID: <012901d4d4d8$60ea0180$22be0480$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQKlxTLn07BEOiTD/WT4iw2b8j2jOaReDCZA
X-Originating-IP: 87.112.237.8
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24474.007
X-TM-AS-Result: No--11.482-10.0-31-10
X-imss-scan-details: No--11.482-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24474.007
X-TMASE-Result: 10--11.481800-10.000000
X-TMASE-MatchedRID: 0dFPYP4mu5TxIbpQ8BhdbOYAh37ZsBDCC/ExpXrHizzW9R0dU1eYdALy tDvV39h+Nk2/rvTUAYa2XNLappcQzB6Hacd6Ohq7xZQoGMRGhhNK770EEUlgD1c/CedjlcvklpS lktUUlXlVvFaQ0zblDqN2rmJdCO/8Ueg0+48uLr3XIwmz2YEJxSTbbsi+pqSF31GU/N5W5BAzwy 2/CE6qxkqIvR+8MbK8ur9ofzgGMq9Iaqdfjxt0yu/nrSnCkbauh8Ytn75ClDOInvV8Dy0ZaGYpV UZH+UourbX6OmZCX9lmfpHOo37dNpHy7oM4lvOnICsP4rpeGcel9VzHf0qr7oiUfQ1FpaXVkj94 Ct/jm/3zA4zwo/bfKbZ2aoc5SUMBL3m5ejCdaFESuhBXNJb1dPHumXHGbVI8nQqircTOm4dvAi4 DK4Hn3FUeZ3rAJGMQB+I75w7Uv8q/WXZS/HqJ2kY41YX/o/8Ki2QFaYS1v20qtq5d3cxkNQwWxr 7XDKH83t7PzxvLBCgIZSYc7nORg86PGyuGkDA99vlbFrSfofEmDOjbC9Svdg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/7VfLYuLhab1aCWs0HYNfseK5H9w>
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 11:24:58 -0000

Hey Alissa,

Thanks for reading.

> 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.

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.

> 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.

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.

Cheers,
Adrian