Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 14 August 2017 10:59 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E9C132196 for <spring@ietfa.amsl.com>; Mon, 14 Aug 2017 03:59:24 -0700 (PDT)
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 z0yf7zfkl1Tc for <spring@ietfa.amsl.com>; Mon, 14 Aug 2017 03:59:23 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45571320D8 for <spring@ietf.org>; Mon, 14 Aug 2017 03:59:21 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7EAxJhB018976; Mon, 14 Aug 2017 11:59:19 +0100
Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7EAxILC018957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Aug 2017 11:59:19 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Henderickx, Wim (Nokia - BE/Antwerp)'" <wim.henderickx@nokia.com>, spring@ietf.org
References: <150247679913.24555.11731619545096839826.idtracker@ietfa.amsl.com> <e757ba5b317644d589fa4b536c724cc2@CO2PR05MB971.namprd05.prod.outlook.com> <053c01d312d2$3c44cb90$b4ce62b0$@olddog.co.uk> <89088D86-6FD5-4008-BD3D-CB7D3258C1C3@nokia.com>
In-Reply-To: <89088D86-6FD5-4008-BD3D-CB7D3258C1C3@nokia.com>
Date: Mon, 14 Aug 2017 11:59:19 +0100
Message-ID: <009b01d314ec$6156eb40$2404c1c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDAUp9c4QBwpGvJKIwgGtw
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23256.006
X-TM-AS-Result: No--9.218-10.0-31-10
X-imss-scan-details: No--9.218-10.0-31-10
X-TMASE-MatchedRID: HXSqh3WYKfs4HKI/yaqRm6hfOb9ZVXujV7oOVXNbrO27qpOHKudqc3fE ZMKlnNGA+7WepgqHngeUb4B0xTyAdTa9BTI9OTwhDB+ErBr0bANAwbB39AVwlh1u7K8HqaNcb4w S3DNipbw1h4k5lhc/pcuuAuqFdHuH/pS/akpdRW8D2WXLXdz+ASseSAhqf1rRULzpjrEhojrGN8 n6L6dsdAVJt0rD30YalwoWmxp8GUD9z9LbkfiOG7ybDkcAszYRvhf/zJ92tsMgcyGevtftJ6PFj JEFr+olSXhbxZVQ5H+OhzOa6g8KrfLbDGZLBS1CsTecJq/FhALqlWRvYwzuZJSBViV84gr/1YA1 z04vV4VDDKa3G4nrLQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/JpvmsuG7rpKOFkCwSgInH8TKipE>
Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Aug 2017 10:59:25 -0000

Hi Wim,

> The draft only defines procedures for SRoIP E2E, why don’t we envision SRoIP to
> Interwork with native MPLS-SR.
:
> You could envision certain segments to do SRoIP and other segments to have
> native MPLS-SR capability.

Yes, the "mixed mode" is both interesting and useful.

In fact, this comes "for free". Consider the example in Figure 3 where UDP is used to connect two SR domains. Now consider that the domains could be any size, the tunnel could be any length, and the picture could be repeated concatenating multiple instance.

Furthermore, the picture need not be fully symmetrical. That is, one end of the flow could be a "domain" and the other could be a single (ingress or egress) router.

> So my question is this in scope of this draft?

So, yes, definitely in scope.

If you feel this could be usefully described we'll add text, but I suspect it just follows and we only need to add a short note.

But...

> What I mean is when using the SRoIP procedures the draft uses SRoIP at every
> hop which is SR capable.

Not the case. As shown in Figure 4 and discussed in sections 5.3 and 5.4, there may be transit routers on the path. These may be native IP (i.e.) legacy routers, or SR-capable routers that are simply not explicitly part of the SR path. Only the nodes explicitly mentioned in the SR path become UDP end points and do the SRoIP procedures.

Cheers,
Adrian