[bess] 3107bis LC discussion on MPLS list

Eric C Rosen <erosen@juniper.net> Tue, 09 May 2017 15:09 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48050129487; Tue, 9 May 2017 08:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 Gs5--VjpKsUk; Tue, 9 May 2017 08:09:02 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0091.outbound.protection.outlook.com [104.47.36.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC53127867; Tue, 9 May 2017 08:09:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=If955CjyrQZFenHU99Q4uUiALxoGy5+OssNVOCH0WjQ=; b=C85ZLLVSd7CYBpjWIji7ER0x9zJv6L9NVpLWme5DGgZNcg4dAsntnDkvYb55rlYJvbs3ILJigEZi/0TGQE+CAj6369/Bxyllgs6YWzjIrlyU6EiphPEGuv07jldACo/r+4iD3nmABEDBpQncwiKgfgh/UU5DPA+0f0cg18D+f78=
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
Received: from [172.29.37.32] (66.129.241.10) by BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Tue, 9 May 2017 15:09:00 +0000
To: BESS WG <bess@ietf.org>, IDR WG <idr@ietf.org>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <c1894094-a4d9-f714-9c26-63aa146ae743@juniper.net>
Date: Tue, 09 May 2017 11:08:56 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------E246575E0BB9CB288EDF6331"
X-Originating-IP: [66.129.241.10]
X-ClientProxiedBy: BN6PR11CA0048.namprd11.prod.outlook.com (10.173.25.34) To BL2PR05MB2180.namprd05.prod.outlook.com (10.167.98.140)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c39f2b15-0a52-4b4c-874a-08d496ed52f6
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BL2PR05MB2180;
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 3:sg40FE2j64B1nYPoRydCTEIjtOfowc3jotKN5vu5kpy2xP6J0mFswgsBj8vk9py7EiJz0IEATtjVJUshhtddP/R2x4qkrUpn9BjuEOrnRT6IlPv1QolYsqt0Rjhglhz8BG/fBn3Qaert8DoOja8giFtydbwunA19mCeRXYiwK2Dcre4rAhrEltTYA5nnbtG8n2lnZMxjJE8m0NGhc9gQ/eDy6c98xKLwROCME7gzicTufKqIdMTmNbqLDu9/ae8ucco7l6+sRziMwAOuYINedFWe4Jb4Pj1++C9QsDZbGZF66BlT8ua8jpmVhI4/ZLnNgNMXwOciHAuAoWdtmoIfBvOeDe9SoEI3q72qesRkk00=
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 25:fGpYUXqv0z9mu8dho36+bewPS+HF+Q1CEVRXNZUpKg3K7JbLtEdbqpigXcmNsYTqVJRPKHMRSyGrkW1fgyTEzsnTEtbyMXok1VClau0HJ3245rrgp6GViF+FJKVqFJHDrzMYfQs6rtT38tIzw7adegAlJxsclUyYjvue0VDPFH2s1YSdD98U7TX2EY8lfXDw3L6yj0ipAXH8BkbANenI6Wsz7wWyyVUgMc3rAmQVGG2pSUok6Vts0gqvkM4/CLVEO29z/Ea/1Cn4qUKmatvQVBUtdr10xQ7NJR3OvpWRO49WVd2iWfMPgaBteUvoY5yQImMQaEbRUH27ZaBleUXUlLsAESd6nrLIx/tRhAflQfNLqWoW2HOsk4rWathfjliV71eIaQKA8HCNbRpd/mDkuNnNj16P1zHNk9beTc8dlCioU0TGqtkCWEVEt/phyP9lCOED4h6rB5NZTyY4msCCK6qvySZqtMMbvNi6w2WZDjVNbNTr74/uX7jE7aYzzDK0v+8l5dscX2FMI1EoJ8cLbYS+LRPtjBHHY+9cr/eX8nIb2yp3dfscbX+y4r0JQiJcc4r1oQdT4o2b4xD3m4Id9WXY+5ao0NZhMq/wmOQ+zVbhp7Dny2EqYayY+EoXxfuHkXN7l1d8GCLzwPEiPzWSRQ==
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 31:kD/pwZoVf6fFAYY3N2EXzt4rPcCEkMPfQZ0KVHLGDA0nNI5jTnQNNmMhhRMJeWxZnGAHE/CpFP8LDT5DBDx9g9A2Y/x4TKxIN4LhA/NSlTwiQm97hMdy4syaH7/Z6u2jE79rGHqA4lKe6J6iP+O4DUpDdGPug8Od9JGcFHqx3NuV1gPrvt5VpdYjCJwpKAJBPHDxCnn1pKkSsWIDFdZl3ipgkiXtRemi2FNrOpBvOGeCOWxJHnJ1aHmUzjeAPU4uEnlBOpaKax6bG45hQsENg0oMTmpLzeTnTAV11v8Ah1k=; 20:2Y8JW2L8uEtgLfK9PP3avAc11AhEeD1ah5oqvhXerz0GhZltH81vJigc+OAqOQcaUcZo83FjMBwTnUUSwAO4JpdKKYaOgWYqWRD9R0KcQ5rxPlbN2M/AWwzLVLIVKl5iQizgTKzt5xK+yskOF1eGbo9ZXGONfGEm6JD7REBbgumx+YKP+t78Xa5pq8q7JSjHkOSz0TQo7Sf4ilyTUB75HzwU4cugjjovXS4jsPd6c0cfiQDN9LMiRCPEkkrnFjeeoSY8LEtDFMlg0hms/mSV9k96tBNMQ4TyuWYFQKcefxDBvufNlc8dobbN5tOALCWsq+CBO45vEmSurO0n7X8GRF8FSS3YuDdhfyP/OgVesYhvvJurPOn/97hPi0Yw83qDA7k1SKk8ZAm9AbQuLs4YYO3hyJ3exkyVODiiHof4OEvunJ/9eY88uG8JdwehfRoA1DEGRAx9a/Gzw2s9yPpq+bPeFwuI2AMf1yMLzk0kBsRweNt9EOo17DVwDbYnRwjYKLmgMzw9YQCU+Ey4j7q7L+N0vtGTMUNxnJuRhXAf500d2KPaqxeHOMNajzWHJ85XHJ103GUBH2G0oTfEYmompa2QPf7spiMYhxVDQ/gTUN0=
X-Microsoft-Antispam-PRVS: <BL2PR05MB21807BE86B378C5FD5BC48C2D4EF0@BL2PR05MB2180.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148); SRVR:BL2PR05MB2180; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB2180;
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 4:MjSSv82YrQ7oFfAjIxEDXNBrWpwm5/neyPT7LRk7yfHAanqDJ7JViV18GgEGran1dTJTh3L4BqgooP271x/+TvG2XXl4usSbqzKUuAABc6o9czxBOxNWPAxaJf3qMgQNYGkBUV25s/rDlhGrXxFd4CwOFyIo+gU2XiSynQ1xoGHo3+ZUFN2VJde9Y3XrxxwAFR+KopnwmsfuiKpHrT7yfU218774Bt+ainmbLIvQk4XIAv2/gsyGzWxTuo6XsL4vKBzDPsaTQ2xs2wc0IpbWNyjN0BdkzJXIDx9QzXkObtAZGPKa1kOuro0WgqfkNb+5uA547mUeJ11gDiZ0MWPGiMoF/QPPL0WCN5xyqWXdA7s/Gx/OP6Tkd0uc3/n5EILeJpANDo9zeXa7Hd0Y6V+53f/XStKrWnesCumrE2JdbFyVqBXiSduhDPuX1sHJhONokd388nUjty5dmLS47eMezY6D2ADkIvGg38rCdKCcHqZg9djEeY8GzM6k2G5O8gfN5foWp685O0ZGsIwMGOYE/+qsYJT9+n6B6OlWYSlrOwe4C4L3hT4/m/Tsdzb+cbrnXweBPGnT0SxUcOgZVRNpdN7gLsj1flt3FOtpCzV2pAzn/KBWS9bxFe7O3WSNH8knGDO9/drp3aQoWL4GKzwQBc6BVXEfKK6MT9jAaOqHO/5brzOn+T14hY/GiCqF6zu4u/cQzW47XBfAV9FgG5DShnFEa2wekObXVt6jpWirIK++Oe4wXYqJBr2yNypY9WaNHS7fVS8NCyqL7nxF4qYTP6cs1zqsZnPCnik0iN9ATHA7P6BFvnCiCDXzyX3EfxTpCBdqHko1QeVlehgOSQEXdA==
X-Forefront-PRVS: 0302D4F392
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39450400003)(39400400002)(39850400002)(39860400002)(39840400002)(39410400002)(77096006)(31686004)(5660300001)(86362001)(450100002)(2476003)(4001350100001)(50986999)(568964002)(512874002)(54356999)(53936002)(6666003)(31696002)(270700001)(3260700006)(25786009)(65826007)(5890100001)(3846002)(83506001)(478600001)(66066001)(2906002)(6116002)(38730400002)(42186005)(6486002)(564344004)(305945005)(84326002)(189998001)(36756003)(4810100001)(8676002)(4610100001)(33646002)(64126003)(81166006)(5000100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB2180; H:[172.29.37.32]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 23:fBPB0RkotOrjRJO0jxOJa0uza6yphDLpmvQS1U0gEWX0nyOP6dcR2ldbYu61w71hiIm3O/cCjC3v8Pga0odv23E8hOYE7i96oU1YbQ2LKhJk95b0JdRAJv5+BDWWepMaE012vM1P4auYUPKF4UphtVOi5fTJdtFwpjNbZIqGJ71wqZBSkczcfdsZ4pXpiMNn+brZnh2UTNnqn8hMprkfBQMk87JDE3NweAmnKXVJqqKymUKDXVw58h8mP5zHLvoY5UpyrEHfuRH66v6r8RmRamXsVZv2oX6NvO4ccO7sECNbRH7otMyVqoELjPe/57mjiECKxnxydOcrVNZC4oXxUwlh/VwvqRnI4EYB7N+NOudLyxCozmH2FlRfjvxc/dvfAL6uavD10/MvJGlAl40b/PL+wSeI/flNTyJ4biAlvRQYzHpfCB2ULFg9FX/4ZYg/7rv4eQdV5Ww4NlcVZAA1iz4Lzso/Any8OJorUn/dZCOgzijiaN4+ZnfqEI71aalw74S0qvo8FoQtIzW/7fQXz9/wqmL6el8Z3oPhWSe92Wi6yCNRp6BCvK6WlkQluxsjCFUQbM5yA8zwD3Wqd/0a0vWbipbkatFJMo9/pq7xuvtpRpiC2UnNFCSsoJhwKIZs/bwxUps95rNYuV+4jgVUt8sYZPdnFp5L3MTpjD3u3ldkWREqlm3qgHgwJiJRcE1Vs98dVE88xw9lCpTdToUIDDwYA1p/wYl3/7CcS4q9w/moZr8bMEYQ1NHWgwHuoXefPTZ3jtXslkKoTzZ7i9PAFEpPQk0C50kAsDwtEzF2lJmjjkbl9+jUYCBFyUnEdxs8B6Ap/5rpbJaieJMcxa6FmfTsEqrhGxVmTydon3tIHYGeLTj4ZJu17qPvNWI/P0g8d8nOllaRw9nr6jb0udarZEZCzVJfizXbzc5oCObEag/6r5FK3UmZUydbG5YugqmilPKYx4Kok+k6GcqsgwGWTXq/+Ert48P0CtQtbY+aiSyoPJByXkK2rFoeE6V+ddCII9cRviluNYafCsPRkJ+IBWNam1szliqcUvS7tCqbuVcxdIqF/rkhmTDFzuCE2da1fq1Tkrz8cbr/pqPYVNqUxlHTzR2hVZACWZDgDkpNlZMtSsxafd3Z7F4tZdRBHQhAHh19GGAMSOo/k+XcY2QNSZFEKpS+QWMAaVrB+Iwryk2Nzont3WieLGjlnvkXvGmTjQ0cBElSibs98sMmmrMOFv6XdobjTzfDVWUFMvzVWSs=
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 6:6tHG8s0nX2c2BVDTUnLLvY6YYqSADmZ/V7CwHVM+FBnLIfBWFIw1ecYiXt37W8S+J1XSryhEyPAFR/OQav1nBrNnsyxrD4Cjj0G1vtCmkiRAUBBoTKK+6A5MkSt+p/A51/hX0OOkFmc7DfUXAp4jwQX2j4zu9uTrkxU0s5BULRggJqvletg2dL12FGgG3SI9e8V44qBmgKlL2qsIf3wtslt1vVzXfWp+jbzCyR5daH63sNv1cBQF3bW9Ydeog8dZpTpDVsvNdxQzMDAPjLKw2ODcnY8ysDRSrOKjHIYrfNZX+rM6zf7QiXSOnY407WVWb8rmvLPOZhzxW4pmc+Nb1rJ5TfGt2xvqaUbfCOzHlFuIo2QvDAY5N9/Uij06XLNgKyzTRgfARoX8Lycw81xHaSn1RTrbUhyoVM/AMX9+jfpdoGgZ3sRJuspU6g7M372KKVqskXm8gm5MvHadOrJqHlZPzYVDAFQ/wL037wdWOOPlw3rGR5x1I1+QM3lptiUDtj3VMOqu6dGBZZAZlUqtFTF++gXwYW6FV5axbhJXmTQ=; 5:WQxFTffZ+edFJVa2SGW2PtnG3/yrS7cq3LNMyjmQ5SGrKPQMyYAgvwcG3HjeFAlDWl3Y3cwjkpYfzgtqA1Hs7ETTlI8FIvhqhEme0NnL6qMKITlyNUzu5umPClSRrUDefvOOeesmUBVh2ivVmp+olg==; 24:taziGIbHIq07gNbLJ/J9Q6Axe0JfZCZZ7cUxH+X4GrXa/gNu+8W6ZCsc1p8CaZKqAG+wjRS9i801xoK8RdFMHoxbTtcGVEygjt1Ib3RCuSg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB2180; 7:OXPFWjCwZE71cXDR+jLE+xkkMLanEeCLhPe0KU55f2dtvY95TlURja5DNsEMg/66BjNqPdW9Z7Dc8U/LVkHEM4bY1bRw/eHJgP6PTaILylbidg+egl8KnPBshFGh8Zq8n9x/d/tewMq0rUP8p+6i7OXf0rrRnu7DyVdurj9Bbc+wnbYX5VacmrVXJ9M5bLLXQA4N5A1kK8WIGTPnthHTLpHP/1yum4/d7C1MeYCmXLuNSwN9utAW7cCDHsIYIwLM9tYRG+rMvkECKC+aXyCIQSC4VOzXErllt2c9rQSO8zqnwMqs74IHFBEjtBqce8twBPlXkn50R+uW2SqAxI5IMQ==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2017 15:09:00.5162 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB2180
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/gJX08JwDyQMrV81bPrSsYEaVTaE>
Subject: [bess] 3107bis LC discussion on MPLS list
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 May 2017 15:09:06 -0000

This discussion (see the attached messages) really should have been 
cc'ed to BESS and IDR.

--- Begin Message ---
Hello


I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc3107bis/


The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG.  The early review can be performed at any time during the draft’s lifetime as a working group document.  The purpose of the early review depends on the stage that the document has reached.  As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published.  Please consider my comments along with the other working group last call comments.



For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Best regards

Jon



Document: draft-ietf-mpls-rfc3107-01

Reviewer: Jonathan Hardwick

Review Date: 27 April 2017

Intended Status: Standards Track



Summary
Thank you for writing this document.  It provides much-needed clarity to the original RFC 3107.
This document is very well written.  I think that it is ready to be published, but there are a few points below that I would like to discuss for clarification.
I also spotted a few nits that should be fixed at some point before publication.

Comments and Questions

1) In section 2.1 it says:
“   If the Multiple Labels Capability for a given AFI/SAFI had been
   exchanged on the failed session, but is not exchanged on the
   restarted session, then any prefixes advertised in that AFI/SAFI with
   multiple labels MUST be explicitly withdrawn.”

If I have understood this correctly, it requires a speaker to withdraw NLRI that it sent on the previous session but that it has not sent on the restarted session (because the negotiated session capabilities changed).
(a) Why does it need to do that – isn’t the NLRI implicitly withdrawn when the EOR marker is sent?
(b) This seems to contradict section 2.4 which says “Note that label/prefix bindings that were not advertised on the given session cannot be withdrawn by this method.”


2) In section 2.1 it says:
“A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a given prefix than its peer is capable of receiving” – why isn’t that MUST NOT?


3) In section 2.4 it says:
“To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute.”
Should that be “it MUST send”?


4) In section 5: although some implementations treat SAFI 1 and SAFI 4 routes as comparable, I believe that they should always be treated as independent, in the following sense:
Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to the same prefix P.  The SAFI 4 route MUST NOT be treated by the receiving speaker as an implicit withdraw of the SAFI 1 route.  If S1 subsequently sends an explicit withdraw of the SAFI 4 route, this MUST NOT implicitly withdraw the SAFI 1 route, and vice versa.
Am I correct?  I have seen implementations that violate this so I think it is worth spelling out somewhere in this section.


5) In section 7 it says:
“ If a BGP implementation, not conformant with the current document,
encodes multiple labels in the NLRI but has not sent and received the
"Multiple Labels" Capability, a BGP implementation that does conform
with the current document will likely reset the BGP session.”

Wouldn’t that prevent incremental deployment of this RFC into a network that is initially composed of such implementations?  Because it seems to require that both ends of each BGP session must be upgraded simultaneously, or else the BGP sessions will all reset.


Nits

Section 2: Missing close-parenthesis on “([RFC4760]” – this occurs twice in this section
Section 2.1: s/ an prefixes advertised/ any prefixes advertised/
Section 2.1: Figure 1 appears quite a long way distant from the text that references it.  I suggest moving it to immediately after the paragraph it is referenced from.
Section 2.1: s/MUST BE/MUST be/
Section 3.1: s/different path identifiers../different path identifiers./  (i.e. remove stray extra period)
Section 3.2.1: “using the procedure of Figure 4” should be “using the procedure of Section 2.4”.
Ditto in section 3.2.2.
Section 4: s/S a layer 2 encapsulation/a layer 2 encapsulation/ (i.e. delete stray ‘S’)

--- End Message ---
--- Begin Message ---
Thanks for your review!


On 4/27/2017 9:03 AM, Jonathan Hardwick wrote:
>
> I also spotted a few nits that should be fixed at some point before 
> publication.
>

I have fixed the nits.

> Comments and Questions
>
> 1) In section 2.1 it says:
>
> “   If the Multiple Labels Capability for a given AFI/SAFI had been
>
>    exchanged on the failed session, but is not exchanged on the
>
>    restarted session, then any prefixes advertised in that AFI/SAFI with
>
>    multiple labels MUST be explicitly withdrawn.”
>
> If I have understood this correctly, it requires a speaker to withdraw 
> NLRI that it sent on the previous session but that it has not sent on 
> the restarted session (because the negotiated session capabilities 
> changed).
>
> (a) Why does it need to do that – isn’t the NLRI implicitly withdrawn 
> when the EOR marker is sent?
>

The theory here is that the label stack in the stale routes is known to 
be invalid, so you really don't want your peer to hold on to them until 
EOR is received.

> (b) This seems to contradict section 2.4 which says “Note that 
> label/prefix bindings that were not advertised on the given session 
> cannot be withdrawn by this method.”
>

I added the following text to section 2.4 right after the quoted sentence:

      (However, if the bindings were advertised on a previous session
    with the same peer, and the current session is the result of a
    "graceful restart" ([RFC4724]) of the previous session, then this
    withdrawal method may be used.)

>
> 2) In section 2.1 it says:
>
> “A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a 
> given prefix than its peer is capable of receiving” – why isn’t that 
> MUST NOT?
>

Section 2.1 also requires the receiving speaker to apply 
"treat-as-withdraw" to such updates, which does imply that the sending 
speaker must not send them.  So I've changed "SHOULD NOT" to "MUST NOT".

> 3) In section 2.4 it says:
>
> “To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI 
> attribute.”
>
> Should that be “it MUST send”?
>

I think the non-normative (non-RFC2119) language is fine here.

> 4) In section 5: although some implementations treat SAFI 1 and SAFI 4 
> routes as comparable, I believe that they should always be treated as 
> independent, in the following sense:
>
> Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to 
> the same prefix P.  The SAFI 4 route MUST NOT be treated by the 
> receiving speaker as an implicit withdraw of the SAFI 1 route.  If S1 
> subsequently sends an explicit withdraw of the SAFI 4 route, this MUST 
> NOT implicitly withdraw the SAFI 1 route, and vice versa.
>
> Am I correct?  I have seen implementations that violate this so I 
> think it is worth spelling out somewhere in this section.
>

 From Section 1:

    This document also addresses the issue of the how UPDATEs that bind
    labels to a given prefix interact with UPDATEs that advertise paths
    to that prefix but do not bind labels to it. However, for backwards
    compatibility, it declares most of these interactions to be matters
    of local policy.

Different deployed implementations have different behavior, and I think 
it is better to advance the document as is rather than derail it with 
the inevitable food fight that would occur if we wanted to try to get 
the IETF to say which implementation is better than which other 
implementation.  The deployed implementations have been around for many 
years, and people seem to have adapted to the differences.

> 5) In section 7 it says:
>
> “ If a BGP implementation, not conformant with the current document,
>
> encodes multiple labels in the NLRI but has not sent and received the
>
> "Multiple Labels" Capability, a BGP implementation that does conform
>
> with the current document will likely reset the BGP session.”
>
> Wouldn’t that prevent incremental deployment of this RFC into a 
> network that is initially composed of such implementations?  Because 
> it seems to require that both ends of each BGP session must be 
> upgraded simultaneously, or else the BGP sessions will all reset.
>

This issue was discussed at great length when the draft was first 
submitted.  The vast majority of deployments do not check the S bit.  
That is, the de facto standard is to assume that a received update has 
only one label.   If any existing deployment were transmitting updates 
with multiple labels encoded into the NLRI, it would already be causing 
BGP session resets.

(Even iff this were a real problem, it wouldn't require both ends of a 
session to be upgraded simultaneously.  It would just require one end to 
have a knob allowing it to accept both old and new behavior from its 
peer, and a knob telling it whether to use old or new behavior when 
sending to its peer.  But since the defacto standard doesn't use 
multiple labels, I don't think we have to worry much about this.)

--- End Message ---
--- Begin Message ---
Hi Eric

Thanks for the replies – please see [Jon] inline.

Cheers
Jon

From: Eric C Rosen [mailto:erosen@juniper.net]
Sent: 03 May 2017 19:23
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>; draft-ietf-mpls-rfc3107bis@ietf.org; mpls-chairs@ietf.org; mpls@ietf.org
Cc: rtg-dir@ietf.org
Subject: Re: Routing directorate review of draft-ietf-mpls-rfc3107-bis


Thanks for your review!

On 4/27/2017 9:03 AM, Jonathan Hardwick wrote:
I also spotted a few nits that should be fixed at some point before publication.

I have fixed the nits.



Comments and Questions

1) In section 2.1 it says:
“   If the Multiple Labels Capability for a given AFI/SAFI had been
   exchanged on the failed session, but is not exchanged on the
   restarted session, then any prefixes advertised in that AFI/SAFI with
   multiple labels MUST be explicitly withdrawn.”

If I have understood this correctly, it requires a speaker to withdraw NLRI that it sent on the previous session but that it has not sent on the restarted session (because the negotiated session capabilities changed).
(a) Why does it need to do that – isn’t the NLRI implicitly withdrawn when the EOR marker is sent?

The theory here is that the label stack in the stale routes is known to be invalid, so you really don't want your peer to hold on to them until EOR is received.

[Jon] OK, that’s fine.

(b) This seems to contradict section 2.4 which says “Note that label/prefix bindings that were not advertised on the given session cannot be withdrawn by this method.”

I added the following text to section 2.4 right after the quoted sentence:
 (However, if the bindings were advertised on a previous session with the same peer, and the current session is the result of a "graceful restart" ([RFC4724]) of the previous session, then this withdrawal method may be used.)


2) In section 2.1 it says:
“A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a given prefix than its peer is capable of receiving” – why isn’t that MUST NOT?

Section 2.1 also requires the receiving speaker to apply "treat-as-withdraw" to such updates, which does imply that the sending speaker must not send them.  So I've changed "SHOULD NOT" to "MUST NOT".

[Jon] Thanks.  Note that the same change also applies in section 3.2.1

   “Similarly, a given route SHOULD NOT be
   propagated to a given peer if the route's NLRI has more labels than
   the peer has announced”

…and also in section 3.2.2

“A BGP speaker MUST NOT send multiple

   labels to a peer with which it has not exchanged the "Multiple

   Labels" Capability, and SHOULD NOT send more labels to a given peer

   than the peer has announced”


3) In section 2.4 it says:
“To do so, it may send a BGP UPDATE message with an MP_UNREACH_NLRI attribute.”
Should that be “it MUST send”?

I think the non-normative (non-RFC2119) language is fine here.

[Jon] It just jarred with me a little.  I’m not going to dig in on this point, but let me explain where I was coming from.  When you say “it may send” the word “may” makes it sound like it is not obliged to do it this way.  I don’t think there is any other way to withdraw the route (short of closing the session) so I think that what you are describing is the obligatory way to withdraw the route.  For that reason I’d prefer either “it sends” or “it MUST send”.


4) In section 5: although some implementations treat SAFI 1 and SAFI 4 routes as comparable, I believe that they should always be treated as independent, in the following sense:
Suppose a speaker S1 sends a SAFI 1 route and then a SAFI 4 route to the same prefix P.  The SAFI 4 route MUST NOT be treated by the receiving speaker as an implicit withdraw of the SAFI 1 route.  If S1 subsequently sends an explicit withdraw of the SAFI 4 route, this MUST NOT implicitly withdraw the SAFI 1 route, and vice versa.
Am I correct?  I have seen implementations that violate this so I think it is worth spelling out somewhere in this section.

From Section 1:
This document also addresses the issue of the how UPDATEs that bind labels to a given prefix interact with UPDATEs that advertise paths to that prefix but do not bind labels to it.  However, for backwards compatibility, it declares most of these interactions to be matters of local policy.
Different deployed implementations have different behavior, and I think it is better to advance the document as is rather than derail it with the inevitable food fight that would occur if we wanted to try to get the IETF to say which implementation is better than which other implementation.  The deployed implementations have been around for many years, and people seem to have adapted to the differences.

[Jon] I agree that this document can’t retrospectively deprecate existing, widely deployed behaviours.  In section 5 you say


“Other implementations may treat the SAFI-1 and SAFI-4 routes for a given prefix as comparable”



Imagine that the SAFI 1 and SAFI 4 routes were received from the same peer on the same session.  What do you mean by “comparable” in this context?  It has been interpreted in incompatible ways by different implementations.

-        Either: the routes are independent in the Adj-RIB-In but comparable in the LOC-RIB (a single best one is selected, the other is retained in memory)

-        Or: The routes are comparable in the Adj-RIB-In i.e. one implicitly withdraws the other.



Both of these behaviours are implemented and deployed.  The issue is that they do not interoperate if SAFI 1 and SAFI 4 are enabled on the same session.  For instance, if an implementation of the first type withdraws its SAFI 4 route then an implementation of the second type is left with no SAFI 1 route with which to forward traffic.  You describe this as a matter of policy, which I can live with, but without further discussion it gives no clue to the lack of interoperability.



I understand that it is too late to say that one of these is wrong and one is right, but the lack of interoperability is an important deployment consideration and I don’t think this document should be silent on it.  IMO this is an important detail for implementers, who need to be aware that both interpretations of “comparable” exist.  New implementations may wish to have a “compatibility setting” that emulates one or the other behaviour on a particular session, so that they can interoperate.



My suggestion: can we expand section 5 slightly to clarify that there are two ways in which implementations can consider SAFI 1 and SAFI 4 routes comparable on a given session, as above, and that the resulting interoperability issue can be avoided either by emulating the appropriate behaviour on that session or by not running SAFI 1 and SAFI 4 on the same session?

5) In section 7 it says:
“ If a BGP implementation, not conformant with the current document,
encodes multiple labels in the NLRI but has not sent and received the
"Multiple Labels" Capability, a BGP implementation that does conform
with the current document will likely reset the BGP session.”

Wouldn’t that prevent incremental deployment of this RFC into a network that is initially composed of such implementations?  Because it seems to require that both ends of each BGP session must be upgraded simultaneously, or else the BGP sessions will all reset.


This issue was discussed at great length when the draft was first submitted.  The vast majority of deployments do not check the S bit.  That is, the de facto standard is to assume that a received update has only one label.   If any existing deployment were transmitting updates with multiple labels encoded into the NLRI, it would already be causing BGP session resets.
[Jon] OK.

(Even iff this were a real problem, it wouldn't require both ends of a session to be upgraded simultaneously.  It would just require one end to have a knob allowing it to accept both old and new behavior from its peer, and a knob telling it whether to use old or new behavior when sending to its peer.  But since the defacto standard doesn't use multiple labels, I don't think we have to worry much about this.)
--- End Message ---
--- Begin Message ---
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.

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

    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.


--- End Message ---