Re: [mpls] Routing directorate review of draft-ietf-mpls-rfc3107-bis

Jonathan Hardwick <> Fri, 12 May 2017 09:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA72012E04A; Fri, 12 May 2017 02:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nB4UmjYfs9VT; Fri, 12 May 2017 02:02:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0D46127419; Fri, 12 May 2017 01:57:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O0xTkorGDT/8MLYPzb8DxdPyD3/xUkrNcOtD4lpVXb0=; b=j5WeQRZdlmncSD4P0MwWcmXdBnIkVVugU6UDYpgQXjjF9mQDAANYD0QwY7ZCJFNteWlT67DPF4CXVeZKeDW1CeYZLj4yWP2ozIbR+YBLj98eEweNKnQAAhtEuM60Q5ZcHnU4Ih52m+ORrnnkl6/bRi4Fsbo1uCq5SRimqB5+EPg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Fri, 12 May 2017 08:57:32 +0000
Received: from ([]) by ([]) with mapi id 15.01.1084.021; Fri, 12 May 2017 08:57:32 +0000
From: Jonathan Hardwick <>
To: Eric C Rosen <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Routing directorate review of draft-ietf-mpls-rfc3107-bis
Date: Fri, 12 May 2017 08:57:31 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1909; 7:d5iqkdVui3Agoeyj35pSaakpluAv18cNRXX1C+6QLqrG/6AcwFfWZskI+D4bETPgHWjdlCTA9UlormmlswKKBO7Nq1Y2eRlFi8AGE6OwvDasuEr1O1DUbxEcW9OMIGOYiLkt8xeN4nT74Etc9bFNPrvU4FNqI0I2VzmUEDkzbz0una2szpPDgphcWQ5SYz7xrtl0aIQK3TubMD1cRcCiAezUDzQ8fNopIG5G2igyxEvZhnyu5l1EY+R+yprvTeaIzgSMXJ8tNkuRQnMpU4OOUF99g3d1lHXnxRlx5WFk87yM4ugWpZXgVQnqEg+5XX3Nef8NDw76N6XbY6VEd4QI9Q==
x-ms-office365-filtering-correlation-id: e7590ac5-e37a-421b-ddd1-08d49914ed07
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR0201MB1909;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:BY2PR0201MB1909; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1909;
x-forefront-prvs: 0305463112
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39410400002)(39450400003)(39840400002)(39400400002)(13464003)(74316002)(38730400002)(110136004)(122556002)(6246003)(3660700001)(2900100001)(33656002)(86362001)(3280700002)(9686003)(55016002)(6506006)(8666007)(54906002)(99286003)(77096006)(1941001)(305945005)(6116002)(189998001)(6436002)(229853002)(102836003)(3846002)(7736002)(53936002)(6916009)(2906002)(8676002)(8936002)(7696004)(81166006)(5660300001)(478600001)(2950100002)(230783001)(25786009)(53546009)(54356999)(4326008)(66066001)(50986999)(93886004)(76176999)(72206003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1909;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2017 08:57:31.9943 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909
Archived-At: <>
Subject: Re: [mpls] Routing directorate review of draft-ietf-mpls-rfc3107-bis
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 May 2017 09:02:27 -0000

Hi Eric

Thanks for making these changes.  This resolves my concern.

Best regards

-----Original Message-----
From: Eric C Rosen [] 
Sent: 09 May 2017 16:04
To: Jonathan Hardwick <>om>;;;
Subject: Re: Routing directorate review of draft-ietf-mpls-rfc3107-bis

Hi Jon,

I've made some modifications to section 5 in response to your comments.  
While I don't want to get into a lot of details about the implementation differences, I do think it is fair to ask that section 5 point out more clearly that there can be interoperability problems, and that it might not be possible to achieve a desired set of local policies with some implementations or some combinations of implementation.  See below for the proposed new contents of Section 5.

5.  Relationship Between SAFI-4 and SAFI-1 Routes

    It is possible that a BGP speaker will receive both a SAFI-1 route 
for prefix P and a SAFI-4 route for prefix P.  Different implementations 
treat this situation in different ways.

    For example, some implementations may regard SAFI-1 routes and 
SAFI-4 routes as completely independent, and may treat them in a "ships 
in the night" fashion.  In this case, bestpath selection for the two 
SAFIs is independent, and there will be a best SAFI-1 route to P as well 
as a best SAFI-4 route to P.  Which packets get forwarded according to 
the routes of which SAFI is then a matter of local policy.

    Other implementations may treat the SAFI-1 and SAFI-4 routes for a 
given prefix as comparable, such that the best route to prefix P is 
either a SAFI-1 route or a SAFI-4 route, but not both.  In such 
implementations, if load-balancing is done among a set of equal cost 
routes, some of the equal cost routes may be SAFI-1 routes and some may 
be SAFI-4 routes.  Whether this is allowed is again a matter of local 

    Some implementations may allow a single BGP session to carry UPDATES 
of both SAFI-1 and SAFI-4; other implementations may disallow this.  
Some implementations that allow both SAFIs on the same session may treat 
the receipt of a SAFI-1 route for prefix P on a given session as an 
implicit withdrawal of a previous SAFI-4 route for prefix P on that 
session, and vice versa.  Other implementations may have different behavior.

    A BGP speaker may receive a SAFI-4 route over a given BGP session, 
but may have other BGP sessions for which SAFI-4 is not enabled.  In 
this case, the BGP speaker MAY convert the SAFI-4 route to a SAFI-1 
route and then propagate the result over the session on which SAFI-4 is 
not enabled.  Whether this is done is a matter of local policy.

    These differences in the behavior of different implementations may 
result in unexpected behavior or lack of interoperability.  In some 
cases, it may be difficult or impossible to achieve the desired policies 
with certain implementations or combinations of implementations.