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 15:34 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 C3FB91277D0; Thu, 7 Mar 2019 07:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 SzMHn8EByhzA; Thu, 7 Mar 2019 07:34:28 -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 488D0124B19; Thu, 7 Mar 2019 07:34:28 -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 x27FYLPd022056; Thu, 7 Mar 2019 15:34:21 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D89662204A; Thu, 7 Mar 2019 15:34:20 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id C292622048; Thu, 7 Mar 2019 15:34:20 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27FYFGR031673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 15:34:18 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Alissa Cooper' <alissa@cooperw.in>
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
References: <155193160518.13682.12438232337705583343.idtracker@ietfa.amsl.com> <012901d4d4d8$60ea0180$22be0480$@olddog.co.uk> <C0BF305D-46ED-45D7-B2C8-3AEC1495D63E@cooperw.in>
In-Reply-To: <C0BF305D-46ED-45D7-B2C8-3AEC1495D63E@cooperw.in>
Date: Thu, 07 Mar 2019 15:34:12 -0000
Organization: Old Dog Consulting
Message-ID: <017a01d4d4fb$3a7d7f90$af787eb0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_017B_01D4D4FB.3A7F0630"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQKlxTLn07BEOiTD/WT4iw2b8j2jOQIEjxYWAiQ4OU6kPSGQ0A==
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-24476.000
X-TM-AS-Result: No--18.822-10.0-31-10
X-imss-scan-details: No--18.822-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24476.000
X-TMASE-Result: 10--18.822200-10.000000
X-TMASE-MatchedRID: 1ZHks2aQIkjxIbpQ8BhdbOYAh37ZsBDCH181YDtIVarW9R0dU1eYdALy tDvV39h+Nk2/rvTUAYa2XNLappcQzB6Hacd6Ohq7xZQoGMRGhhNK770EEUlgD1c/CedjlcvklpS lktUUlXlVvFaQ0zblDqN2rmJdCO/8IoY4ZTE7vhyzI1v7J4hEChlgDfyCPcHEV9eB8vnmKe/8k0 Y8XCLqDQnQeJLz0Ec+ys1f2ZkRNCOMB40CblSQ4khEDfw/93BugsuHb8lxzt5BDVeC8J7uwcbXN mojOJiwkJxgP3/yNu16v97VXslRaRAjnndaQMfLM0pZiLPQITre/DVpWKI5K914Aqe8EzF89t3o qadNMdEQY+auDXyVWOkFggkz1/z6qmLWaEinQeFWgOVCl/hN1bw2HnQG+TrAKAzGd8VeOIiK61Q 63RemBPk4X/uR4lHPSaVfaxxV948Ct8gNWNANfsG0UNgaZpYq6r+5bPPauHf5N0o2THGRZKgFX2 xz5NjH4j4lr4Wn4RisEFKef8ZUxqf50/sZyNUdupDIC9422DrTMQ/93vE8XUbaqUVvLFsi01gtG 8vJ6ZBbn6tefwlpGeGQF+JPeVuuMuYLNWSVlUgLPVZHwod7gO0ywEoYSNupnp9KgXcu34xWFBL5 r3scrXb4Bm7FqQnLXHn0K2CbIexTovWuZWqWkT5bo3ZLMFMHyiBjGmb09Nuyy072phvASaPFjJE Fr+ol4E9s12Gvf51cLc3sLtjOt9xWF9NJ0ly4KzfM9B6IRt7+efAnnZBiL6SszSEYZXnDpPuFdB ZT1XgjuA4bOvnCbiw/uYykF6clxkyiN4Xhycl+3BndfXUhXQ==
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/QwmpNCKLpG6tuDkpZuWRiSp3ayE>
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:34:31 -0000
Great. I think we have converged. Thanks for the Discussion. Adrian 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. [AF] That's easily done. 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. [AF] Consider it done.
- [mpls] Alissa Cooper's Discuss on draft-ietf-mpls… Datatracker on behalf of Alissa Cooper
- Re: [mpls] Alissa Cooper's Discuss on draft-ietf-… Adrian Farrel
- Re: [mpls] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [mpls] Alissa Cooper's Discuss on draft-ietf-… Adrian Farrel