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

"Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com> Mon, 14 August 2017 06:27 UTC

Return-Path: <wim.henderickx@nokia.com>
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 00613126B6E for <spring@ietfa.amsl.com>; Sun, 13 Aug 2017 23:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 dBlPc_ugwWja for <spring@ietfa.amsl.com>; Sun, 13 Aug 2017 23:27:21 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0113.outbound.protection.outlook.com [104.47.1.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4E21200B9 for <spring@ietf.org>; Sun, 13 Aug 2017 23:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vPC9/U1Intm4f1O99dTdr4zukmCmYmgoxMMbsWbYAlE=; b=qGB0jucCONzZKuWdW1Ffyf8D+fbSvQBJn42eXjeQ7t9BqOami0pQRp85t1hLbqh7ZLF0OTh4ktiOICiQ9U3sAMOlM85owvMuS1syeNiQMiQynPkYctGYRFFJ4RbYYQKF8tifzgmE5HID78hD4pFw/bRgbWORhBxu9WHOrx3N7CU=
Received: from AM2PR07MB0961.eurprd07.prod.outlook.com (10.162.37.144) by AM2PR07MB0786.eurprd07.prod.outlook.com (10.161.70.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Mon, 14 Aug 2017 06:27:17 +0000
Received: from AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651]) by AM2PR07MB0961.eurprd07.prod.outlook.com ([fe80::15ca:8d21:d29b:7651%14]) with mapi id 15.01.1362.012; Mon, 14 Aug 2017 06:27:17 +0000
From: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
To: Uma Chunduri <uma.chunduri@huawei.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
Thread-Index: AQHn/qs4BvcCTQFwrnhrRd9ZEGKw2AIdtmzDokS32NCAA79GAP//7/ZwgABcJoA=
Date: Mon, 14 Aug 2017 06:27:17 +0000
Message-ID: <F9197259-81BB-4FDD-9FC9-74479B16F968@nokia.com>
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> <25B4902B1192E84696414485F572685401A3ABA2@SJCEML703-CHM.china.huawei.com>
In-Reply-To: <25B4902B1192E84696414485F572685401A3ABA2@SJCEML703-CHM.china.huawei.com>
Accept-Language: nl-BE, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.25.0.170725
authentication-results: spf=none (sender IP is ) smtp.mailfrom=wim.henderickx@nokia.com;
x-originating-ip: [88.128.80.101]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0786; 6:5iyAp57i9xk4srvnZULRZWys9/T2JdOi//zuotGEqurz93nhzw7/EmR2mTVCL8DE83Q5J8X398u8VnLDykCGonskZUxubHiPtGqRAVqm8gupznwASDFyfeGvyxBDHsCBXWVdEUSmNwpFlOEwJOiigJ6/++mY7LWBZcXcSx8drEldc7TDcuAJdefVg7cknPqK7IcdOzUfUDtO6xfZF/+85+6FbXT+lOhlop8iNdiAns7BL7qp/R6XVIsnlV6RbIoYlSeInhycDsh51lQ2FFq9KuCAHeLAkQ8nRg3xloea4hpt1+bTBJCC2iqVBuu5Q2n6si1Sj8XeSTyKLu65CuOIuQ==; 5:2YU9Y7++nFQFWp7+ZhSfhdfvym9JIior3fJcVApUg4z1an+ZbG95ufKwE+uoi2fMThespsQUwFv1upHoGnfwDjG7oCy4MfjrJP+2w3ItlMQTeTq0Y+Zo3yH1OJXxk8wQheA7sSnlhtm7MEeIMTI1dA==; 24:kMlhhMHvlpGR/IVATJ5DS0GUDcJ4PJm49brskmvr7AnqMv2KmgEMTHdkgEcaNtz9bO26r/7xKaYXNesNgggbpfNDzCUiXeoH3LjvA20NPiA=; 7:Fy9YcG11y0I5pfxggW442Wf+Y5VypdIxTU+ekzW3Rimp9YZiSadFV+/96BaVEAXnqsvsPnQRCoHLutvA5Yn5LQM5zyq75ZYmpFGOgk4HEdJ+u56AaCK8t/I7mUs023THOJGwH1F9M3qIWzW8a20CDgDY2xUB6b3sED5L28Ln9PnmBYofZXa+RREoq9JY8V7n8EEoUMdiAjpdCfpR2tF0szcdBqU8x+OT7il3hbBGJWI=
x-ms-office365-filtering-correlation-id: 65e6fa2c-15c4-4bc5-4ac4-08d4e2dd82c0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0786;
x-ms-traffictypediagnostic: AM2PR07MB0786:
x-exchange-antispam-report-test: UriScan:(120809045254105)(50582790962513);
x-microsoft-antispam-prvs: <AM2PR07MB0786863F11951D9F3FB90D18838C0@AM2PR07MB0786.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0786;
x-forefront-prvs: 039975700A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(377424004)(377454003)(53754006)(199003)(13464003)(24454002)(189002)(106356001)(53546010)(101416001)(2906002)(97736004)(4001350100001)(7736002)(3280700002)(305945005)(76176999)(54356999)(50986999)(33656002)(3660700001)(36756003)(6306002)(53936002)(99286003)(66066001)(6116002)(102836003)(3846002)(86362001)(82746002)(5660300001)(6512007)(14454004)(189998001)(2900100001)(105586002)(966005)(6246003)(2501003)(8676002)(68736007)(83506001)(478600001)(83716003)(6506006)(93886004)(6436002)(81166006)(229853002)(8936002)(2950100002)(5250100002)(2201001)(81156014)(15650500001)(6486002)(25786009)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0786; H:AM2PR07MB0961.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <E4B9ADB09E79204FB309E1FDB8BB0195@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 06:27:17.4122 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0786
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/jcakkTYNrBmX49H1aVgmNS7pbyE>
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 06:27:24 -0000

Also this draft doesn’t describe this use case afais. What I am taking about is this:
Using MPLS-SR for the SID to G and SID to H iso using SR-UDP SID. Is this envisioned?


     +-----+       +-----+       +-----+        +-----+        +-----+
     |  A  +-------+  B  +-------+  C  +--------+  D  +--------+  H  |
     +-----+       +--+--+       +--+--+        +--+--+        +-----+
                      |             |              |
                      |             |              |
                   +--+--+       +--+--+        +--+--+
                   |  E  +-------+  F  +--------+  G  |
                   +-----+       +-----+        +-----+

          +--------+
          |IP(A->E)|
          +--------+                 +--------+
          |  L(G)  |                 |L(G)   |
          +--------+                 +--------+        +--------+
          |  L(H)  |                 |  L(H)  |        |L(H)|
          +--------+                 +--------+        +--------+
          | Packet |   --->    | Packet |  --->  | Packet |
          +--------+                 +--------+        +--------+

Also, it is a bit odd we have so many drafts on the same topic. 
Btw what about BGP extensions?

On 14/08/2017, 04:58, "Uma Chunduri" <uma.chunduri@huawei.com> wrote:

    Wim -
    
    That's been described  here:
    
    https://www.ietf.org/id/draft-xu-mpls-unified-source-routing-instruction-03.txt
    
    --
    Uma C.
    
    -----Original Message-----
    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
    Sent: Sunday, August 13, 2017 6:55 PM
    To: adrian@olddog.co.uk; spring@ietf.org
    Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
    
    The draft only defines procedures for SRoIP E2E, why don’t we envision SRoIP to Interwork with native MPLS-SR.
    What I mean is when using the SRoIP procedures the draft uses SRoIP at every hop which is SR capable.
    You could envision certain segments to do SRoIP and other segments to have native MPLS-SR capability.
    
    So my question is this in scope of this draft?
    
    On 11/08/2017, 20:47, "spring on behalf of Adrian Farrel" <spring-bounces@ietf.org on behalf of adrian@olddog.co.uk> wrote:
    
        Hi all,
        
        SPRING didn't meet in Prague so I presented this work in MPLS. Bruno suggested
        that maybe SPRING would be a better venue.
        
        I'm not sure about that, although I do think both WGs should chat about the
        ideas.
        
        The essence of this work is nothing more that MPLS-SR encapsulated in UDP per
        RFC 7510. What it achieves is a way to obtain the SR functionality that we all
        know and love in an IP network.
        
        The approach is, of course, compatible with MPLS-SR. As the draft says...
        
           This document makes no changes to the segment routing architecture
           and builds on existing protocol mechanisms such as the encapsulation
           of MPLS within UDP defined in RFC 7510.
        
           No new procedures are introduced, but existing mechanisms are
           combined to achieve the desired result.
        
        This is not intended to be a beauty contest with SRv6. As the draft says...
        
           The method defined is a complementary way of running SR in an IP
           network that can be used alongside or interchangeably with that
           defined in [I-D.ietf-6man-segment-routing-header].  Implementers and
           deployers should consider the benefits and drawbacks of each method
           and select the approach most suited to their needs.
        
        Thanks,
        Adrian
        
        > ________________________________________
        > From: internet-drafts@ietf.org
        > Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, London
        > To: Stewart Bryant; John E Drake; Adrian Farrel
        > Subject: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
        > 
        > A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt
        > has been successfully submitted by Adrian Farrel and posted to the
        > IETF repository.
        > 
        > Name:           draft-bryant-mpls-unified-ip-sr
        > Revision:       01
        > Title:          A Unified Approach to IP Segment Routing
        > Document date:  2017-08-11
        > Group:          Individual Submission
        > Pages:          16
        > URL:
        https://www.ietf.org/internet-drafts/draft-bryant-mpls-unified-ip-sr-
        > 01.txt
        > Status:
        https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/
        > Htmlized:       https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01
        > Htmlized:
        https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip-
        > sr-01
        > Diff:
        https://www.ietf.org/rfcdiff?url2=draft-bryant-mpls-unified-ip-sr-01
        > 
        > Abstract:
        >    Segment routing is a source routed forwarding method that allows
        >    packets to be steered through a network on paths other than the
        >    shortest path derived from the routing protocol.  The approach uses
        >    information encoded in the packet header to partially or completely
        >    specify the route the packet takes through the network, and does not
        >    make use of a signaling protocol to pre-install paths in the network.
        > 
        >    Two different encapsulations have been defined to enable segment
        >    routing in an MPLS network and in an IPv6 network.  While
        >    acknowledging that there is a strong need to support segment routing
        >    in both environments, this document defines a converged, unified
        >    approach to segment routing that enables a single mechanism to be
        >    applied in both types of network.  The resulting approach is also
        >    applicable to IPv4 networks without the need for any changes to the
        >    IPv4 specification.
        > 
        >    This document makes no changes to the segment routing architecture
        >    and builds on existing protocol mechanisms such as the encapsulation
        >    of MPLS within UDP defined in RFC 7510.
        > 
        >    No new procedures are introduced, but existing mechanisms are
        >    combined to achieve the desired result.
        > 
        > 
        > 
        > 
        > 
        > Please note that it may take a couple of minutes from the time of submission
        > until the htmlized version and diff are available at tools.ietf.org.
        > 
        > The IETF Secretariat
        
        _______________________________________________
        spring mailing list
        spring@ietf.org
        https://www.ietf.org/mailman/listinfo/spring
        
    
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring