Re: [bess] Comments on draft-ietf-bess-ir
Eric C Rosen <erosen@juniper.net> Mon, 28 September 2015 13:53 UTC
Return-Path: <erosen@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2117D1A9109; Mon, 28 Sep 2015 06:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level:
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 mWoUjHd3FnZM; Mon, 28 Sep 2015 06:53:15 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE4F1A9108; Mon, 28 Sep 2015 06:53:14 -0700 (PDT)
Received: from DM2PR0501MB1104.namprd05.prod.outlook.com (10.160.245.140) by DM2PR0501MB1646.namprd05.prod.outlook.com (10.160.136.22) with Microsoft SMTP Server (TLS) id 15.1.274.16; Mon, 28 Sep 2015 13:52:55 +0000
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net;
Received: from [172.29.32.165] (66.129.241.13) by DM2PR0501MB1104.namprd05.prod.outlook.com (10.160.245.140) with Microsoft SMTP Server (TLS) id 15.1.274.16; Mon, 28 Sep 2015 13:52:53 +0000
To: thomas.morin@orange.com, draft-ietf-bess-ir@ietf.org, BESS <bess@ietf.org>
References: <20534_1443086368_5603C020_20534_2608_3_5603C01F.70607@orange.com>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <56094630.40606@juniper.net>
Date: Mon, 28 Sep 2015 09:52:48 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20534_1443086368_5603C020_20534_2608_3_5603C01F.70607@orange.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.241.13]
X-ClientProxiedBy: DM2PR11CA0018.namprd11.prod.outlook.com (25.160.91.28) To DM2PR0501MB1104.namprd05.prod.outlook.com (25.160.245.140)
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1104; 2:E5XWXntoURILL2bfPNaHPqu6pFsH2iSJc11nHzKBSp1iSuO5r3PYbRhUbUh823lJPrWGp36WcSTpnTf2gmGcndqyQgaSVutWHghsMO1XMoONv5sxCwakogEsaAr0Crq78p+frq4UdTTeiDqnNfaE6dpVJuf0QfHXh78f0vYSJzk=; 3:DykuYtcOzwk1n2pz40Bv9IN785UsC5HVMS4wME+IPsp4GZcbgDzm/uGYx9J4pAI2WLZo0qbe28dxo+DQuCQFUt7BYX6C+2zmWm8lQ/gfaef/dwplPEE4Q+kSm+JvGr4k0BNo78fN/J/8GnHBdWlKMw==; 25:1/YlU8lf9XevxqEf7aUxdJWMn5G7BASncOaMEwjutEw177GbxeAITbaJmSGPhS4tU6wBR/si9iMcKjns4LgT3CNzi5+BZcr6AAonqjVb4BGZrK6+i3xfO7O87cgXuhWWXvSmdf1HqWvaY7Z1+eV9LVz5AfuwlDNqdWF9jcnhBXbK3QugLuenzKzakCxm5lzDGGkY6+bXrJp2YCfiH/1zsU70URfscIfNNibHE4r9jeOAKdPkDpGb9xrG4FpNENXD7iFArKjcbU3ub2ivk+rWcQ==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1104;
X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr,ExtAddr
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1104; 20:SKar5bly13QxPKOdg6W70rhsuLHjX5Qne+J6mnIoAzpKCZ9mz7O5ZCT9mMDl8Gn2gGrRC+eOL+IlQOrNj37CEjgOQdmKd7ESNmB6nVZJNKTnuvmmq42M9j7rlROfovEkSS7YtXMto9Wl93tcC3Gtdz9P4XnZIB9T7V1pvqTvSNHAL9zz4UVrOJId34oxyr+jA82kB2gmJ7oEGKTCj4djqlTpdNKOuYeh3uU3G8MHnotHz27HJ3uPhWTHNwNiTHBI9KqGP5O6pNap3oZ6RYQ/sxrKVEQGveHLzhTaSDyTd7fCH+1HSNl+y7gzuRKpm4cFGF4o/eUcmYlGTHQc54f/zFLBDvFXngT/iRD58G3IjJN2yK8F7sBovAPE30mZzZ2A0bJKzvGRZXyPPPYCwf4+hkUUHf5SUPCcYj2+/YlWJ6gXDRjTRFL8IWu4X0xRsXQnJKp1Y2W5BOO2aBkDWltWuK/ZO9hKsNiFss89VfqcyLzdVLoNQHQWwIyRn7BXRcGE; 4:GyrPrTeaZMRbJGe+4vyVvUjC5lMEm7MgupPfKvZLQK3flccgesJyXw7S+KE7frCnI8GfonhE4qwRxKyLgMP37oG5FYScDUYXGnOEC9gY1Gcnj0+w6mgZ09IyS/pX+TXL+AZJv7M3ZiHmlHMBIvPhZDQSpKRIGn+OjiNIpjQyXPSGyXSyrfhuQCKRGWWA2TB4GyGRWjvJrvqdl3ILWEagudIOblFHx612DucTYwBGEyI4gEDOu6g1rE1XVQlXi8GOvCQ++3KfYiaIuj7tczj74ufgMmuaJxZasE7dpRh1ltEnX4RU3nKucR2r3dCvODhO4aFerxlQxcX8f8YiNgKwdpjAudgWFsxBL2FiAiLdEz4=
X-Microsoft-Antispam-PRVS: <DM2PR0501MB1104FA390D17174AD90C1DCFD44F0@DM2PR0501MB1104.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:DM2PR0501MB1104; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1104;
X-Forefront-PRVS: 0713BC207F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(199003)(2950100001)(65956001)(117636001)(87976001)(68736005)(230783001)(5007970100001)(64706001)(47776003)(66066001)(65806001)(42186005)(105586002)(77156002)(50466002)(62966003)(106356001)(86362001)(76176999)(23676002)(77096005)(83506001)(54356999)(46102003)(36756003)(65816999)(40100003)(5004730100002)(50986999)(122386002)(4001350100001)(5890100001)(81156007)(4001540100001)(5001920100001)(64126003)(5001960100002)(107886002)(189998001)(5001770100001)(92566002)(5001860100001)(97736004)(5001830100001)(101416001)(4001430100001)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1104; H:[172.29.32.165]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1104;23:psylrXy1MPdr3zcocyqjVec4fBQQCKHDszg+9mf/Ra2Ev/WnL5Sydu81exg5MmyxfnKitkogtqT9nZo2Itx7Yk7pB/LJBNo5yLmoGZwRycR2GlgPjNUhjZm/XzHCU3NAJcmnKOMW3VcFgoU2uTof9Ksh0FlbmzJdCCZA7bhLZJ9hjwZTjo4faRpgNUYawGCDXfA4ZUSlep1gwCmHR4WsQ4Ajw5ZuFtc6NpK5AtQJL/dgFF0HNbI20YN11FXnIcA7rrG48a2u0CGVkNpC8cjvzcd1uKoEY5vRhM5ZfpqgS0PFMBFC++BC+yBfpLgSxzGxKj8kY6d6LY+Lanb+9/WaRE4iCITztLJCh6vG/Rl2B5TO8prPHrU7o20X6L5un5TPNmu0a9yGpWnFwN5x81SfaeG63+DvYprJpWEiFvo1OO5RlaDvX8zblXVJe0/J1+CGepb0khFEs51dfnr2QZyiFLYqyOMRsK9F/u9b8WxI2EKNEBquj7Bwkd7d72MfTJISQ1bfKxHNOPoE/b69hnLe0bHXGafPLK7Le5sVezSGmtU2rYkAWb2HU/0hSaywRhS+5CMslF+yNTXIPFeur6v9t0ajBb1z1khi6K0bcAILR42FubX+PZfsNJow8YRSxzPI7LtMoLnlrwexYwXhaNuUW7DPIAzkOPpHV5rPBhpvMl9lus/7Q9Juriqy2mqVa1JNmYBlj695qRBpza7js3X47wyexPl8NuX7siZTsEKYuYho51vrZMkUO1JkOGAP9lFVBmImzZsBTVaNf1RAqp3ZgxR4aMCInjzTSdBoUKV0C3MOGCLnC408aIs72NpUAi/Z1VUtxBvBIHRx9zBL/DwhYOhjQeqpEYlxyCvRcyNmuld1H1J+gachWtbI/Ltsg690UodAHs09ARKpcGgr2/wLcBbIB8pab+jnrVA0kE2pyqsAtbjPu1i0gXo/MyvjjJ7Q9z0e4+RHXerv6n6LLQG0zu2JJ5hDlXIs/t/aV56/nh1ylaSiPWVRQZgnOzCi1ywEnSoJzLNAcf6pTqszhB0lZwlZ6u5WF2IM9WjyOyUG+cD99kM6+6/K5vaDoqtyZpacvu2l/TJAF1SylCeR3Y/Vx3j5QjHyWinydhcbiC2DPYQZy85laXyH6o1lfdZJly6xCoaLwcjWkVLH14uwCEChUm5MdBK4COoDRxvbcBNkRj5Duz9v+9B6yuNjOvciX9cdFoOGp/uc1C/W+BcfiuNA91HLEtY4iopOmJUP9uqWKhajG8SohlcDc/REomylogbzJkEZSMngsazXEMsn2UHUuuZHWdCroKtTv8lQYZW8Wy9JTyx2Z956E8XEhoUoVBz83DAZBaYAkG/L2iRxymxQyp0povfrNHf2S3LoVMVxPEU=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1104; 5:FR3BGbMnHgZVIMpXnAVUd/GuVRdit0Sb9IF88EKYC2merwxuAqG2Jz3ASwobDUefohQAO8Afiq4uuaqJCtEXu2D4MF3CLNtZq7sQzQ+nbPu7+WsO+Q28t2Yz9Hm0c/f5faSCrrSwMRvYN3GMUJmmVA==; 24:vVF4HZi1fLsdPrph4A8NItdiryHTI4VUdOTQypUt7Rgv+hvxtkRnXdquvXqzuhF2wzEEUuKfB7l6142GIL3WrhyemL3sSy9zFF/P0HBCztI=; 20:yq1S+ZeQZKhn//8sZpPjeX2u9nVUt2G2FgZssZRTZvQ6T93IfgGUgrT5CuiaEC3Yo/0Jj94fynotpdR7MObJwg==
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2015 13:52:53.7533 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1104
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1646; 2:nAewNHLDF6soRNyoZLShWl680VjJRpZyoTaDYNi1xgt5zWa68v/GihRp4vN8XrRfk8cv0JU6yvg7VhJ7EXQJfUcK8RCBoFFtoFMHnlmWt8ypJTts/GZ/Avrvti0n9Bb9KAFX81fTJU+wzAFBJ1BqeJQH4TykMqD6RMhNrjvebBk=; 23:GJhwRHLvvH8afXaazHMqSGtR0Kx3bM1mHSI2IzgkJDRito2jnXW4LQvSir2k/JKNdqBPAAOmbkeKozSfpu2cnWcNeVClaCcInzUyi1uAQBuO3u56ngNrNPnWmF5OihFh6a8jq09iriz2C/93Jajz4n3wL32zjGzZfccD40nVKfd0fL3uyyuKZKcEpWrQY+o+
X-OriginatorOrg: juniper.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/AydZrp0Lf9fUohKrgVHG9kzbycY>
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Karthik Subramanian <kartsubr@cisco.com>
Subject: Re: [bess] Comments on draft-ietf-bess-ir
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 28 Sep 2015 13:53:18 -0000
Hi Thomas, Thanks for your review and comments! From the draft: "This document does not provide any new protocol elements or procedures" I think we can agree that it does not specify any new protocol elements. > [Thomas] Sections 3, 4.1.1 and 9, at least, introduce what I think can fairly be considered new procedures. I don't see anything in section 3 or 4.1.1 that I would call "new procedures". However, your point is well-taken about section 9, as RFC6514 does not really address the use of timers to achieve "make before break" functionality. On the other hand, RFC 6513 section 7 does specify the use of timers when switching a flow from one P-tunnel to another, so the use of timers is not a new addition. When we started implementing ingress replication, we found that it wasn't always very clear how to apply the procedures of RFC6514 when ingress replication is being used. The purpose of this draft is to pull together into one place all the procedures relevant to ingress replication, and to explain clearly how ingress replication is done using the procedures of RFC6514. The focus is on getting it clear enough to increase the likelihood of multi-vendor interoperability. We really tried hard to avoid creating any new IR-specific procedures, though section 9 may be an exception. From the draft: "4.1. Advertised P-tunnels The procedures in this section apply when the P-tunnel to be joined has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D route, or an Intra-AS I-PMSI A-D route." > For sake of clarity and avoid any misinterpretation, can you please add ", and the PMSI Tunnel Attribute is of type Ingress Replication" Well, section 4 is called "How to Join an IR P-tunnel", and the entire draft is exclusively about IR P-tunnels. If you think that is not clear, perhaps the sentence above should just say "when the IR P-tunnel to be joined has been ..." From the draft: "Note that if a set of IR P-tunnels is joined in this manner, the "discard from the wrong PE" procedures of [RFC6513] section 9.1.1 cannot be applied to that P-tunnel. Thus duplicate prevention on such IR P-tunnels requires the use of either Single Forwarder Selection ([RFC6513] section 9.1.2) or native PIM procedures ([RFC6513] section 9.1.3). [Thomas] I would suggest rewording with "Note that, in the general case, ..." and "...unless the tunneling technique relies on an IP transport, which may allow the identification of the PE sourcing the traffic". It is certainly true in theory that one could use an IP encapsulation in this way, but in practice it creates a couple of complications: - I think it presupposes that the IP source address field of the tunneled packets contains the same IP address that the ingress PE puts in the Global Administrator field of the VRF Route Import EC that it attaches to the unicast routes that it distributes. - All the egress PEs need to implement this IP address check in the data plane forwarding path. While using the IP encapsulation in this way is a possible option, it has never seemed like a very attractive option, and as far as I know, no one has implemented it. To avoid the need for an option like this, I always recommend that if one wants to use IR by default, one should advertise the IR P-tunnels in a (C-*,C-*) S-PMSI A-D route rather than in an Intra-AS I-PMSI A-D route. One can still use IP tunnels if one wants, but the "discard from the wrong PE" procedures would be based on the MPLS label that is carried by the IP payload. Another problem with using the IP header to apply the "discard from the wrong PE" procedure is that it will not easily generalize to the case of extranet. (Still another problem would be that it is just one more unnecessary option.) I could add some text explaining this, and explaining why it is not recommended to use the IP header to apply the "discard from the wrong PE" procedure. Now, regarding the use of timers when switching UMH ... [Thomas] I understand -- even if that is a bit implicit -- that the NLRI for the Leaf A-D route to the old UMH is the same as the NLRI for the Leaf A-D route to the new UMH. Correct. [Thomas] But I don't in fact understand why this has to be the case... Leaf A-D routes are originated in response to I/S-PMSI A-D routes, and the rules for creating the NLRI of a Leaf A-D route, as specified in RFC6514, are independent of the tunnel type. [Thomas] One has to ignore the procedures to build a Leaf A-D route of RFC6514 since this document specifies new ones for IR in section 4.1.1 I don't understand why you say that. The 4.1.1 rules for generating the NLRI of a Leaf A-D route follow the RFC6514 procedures. [Thomas] section 4.1.1 says that the Key field of the Leaf A-D route contains the "tunnel identifier" defined in section 3 Yes; the tunnel identifier defined in section 3 is the NLRI of the corresponding I/S-PMSI A-D route, which is exactly that RFC6514 specifies for the route key. [Thomas] section 3 says that (when the "Leaf info required" bit is set, which is the case for section 4.1.1) the tunnel identifier is RECOMMENDED to be a routable address of the router that built the PTA No; section 3 says that the "tunnel identifier" field of the PTA is recommended to be a routable address of the router that built the PTA. But section 3 also tries to make it clear that the identifier of the IR P-tunnel does not appear in the tunnel identifier field of the PTA. [Thomas] Anyhow, it seems to me that ensuring that the Key changes when the UMH changes, would simplify the make before break procedure: everything is at the hand of the downstream PE which can advertise both routes for as long as it wishes, That does not seem to me to be a simplification. The specified procedure is pretty simple: - To change parents, only a single control plane operation is needed: a change in the RT of the Leaf A-D route. - In both the upstream and the downstream node, the to-be-deleted data plane state is timed out. - There are no data-driven state changes. (Note that to avoid data-driven state changes, the downstream node really needs to run a timer in order to decide when to modify its data plane state.) - The timers do not need to be very precisely tuned, and certainly do not need to be tuned on a per-peer basis. - We retain the RFC6514 principle of keeping the NLRI independent of the tunnel type. Thus we minimize the chances of creating unintended side-effects or new corner cases that need to be thought out. That is, we minimize the chances of breaking existing MVPN implementations in unanticipated ways. Eric
- [bess] Comments on draft-ietf-bess-ir thomas.morin
- Re: [bess] Comments on draft-ietf-bess-ir Eric C Rosen
- Re: [bess] Comments on draft-ietf-bess-ir thomas.morin