[Idr] Comments on draft-vandevelde-idr-remote-next-hop-08
Jeffrey Haas <jhaas@pfrc.org> Wed, 15 October 2014 17:00 UTC
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47921A89EF for <idr@ietfa.amsl.com>; Wed, 15 Oct 2014 10:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.321
X-Spam-Level:
X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 KeK5X1-w5ue2 for <idr@ietfa.amsl.com>; Wed, 15 Oct 2014 10:00:46 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F3CBF1A8945 for <idr@ietf.org>; Wed, 15 Oct 2014 10:00:45 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 7B161C22C; Wed, 15 Oct 2014 13:00:45 -0400 (EDT)
Date: Wed, 15 Oct 2014 13:00:45 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: idr@ietf.org
Message-ID: <20141015170045.GM18720@pfrc>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/j8FmaxN1Hjuzsh46A8H8fTOlnGY
Subject: [Idr] Comments on draft-vandevelde-idr-remote-next-hop-08
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Oct 2014 17:00:48 -0000
With my apologies to the authors of the draft after they gave ample time for pre-publication review, I just didn't have time before -08 was submitted. After some discussion with Keyur about the purpose of the draft, some of my concerns have been addressed as to the possible use cases for the feature. The new draft is somewhat better about describing those use cases, but still isn't really clear that this is meant to supplant the BGP (MP_)Nexthop fields for purposes of forwarding. Somewhere in the document it should say that. :-) My main remaining concerns are as follows: ----- Bestpath considerations: Basically, this says "use the worst tunnel endpoint cost". However, in a network that may contain a mix of speakers that understand this attribute and ones that do not and may use the BGP (MP_)Nexthop, route selection may be inconsistent. Multiple remote nexthops: This was my original concern when it wasn't apparent that this feature wasn't being used for chaining and instead is simply an odd form of "add-path for nexthops" by loose analogy. Section 8 seems to imply that the desire is that the RNH is effectively bound to the same device, but there's no guarantee of that. (Hence the man-in-the-middle concerns.) While there's a comment about bestpath calculation, there's no related commentary about which tunnel should be used or whether there are ECMP considerations if you can use more than one tunnel endpoint. Origination/modification: The sane behavior of this feature appears to be that the originator of the attribute is the only party that is adding to it. Intermediaries may remove remote nexthops for various reasons, including error handling. If this understanding is correct, it should be spelled out in the document. Nits: Too many typos and inconsistencies to comment on in this format. If the authors arrange for the XML source to be posted somewhere (e.g. github), I'll submit patches. In short: looking better, looking less scary, still needs some work. -- Jeff
- [Idr] Comments on draft-vandevelde-idr-remote-nex… Jeffrey Haas
- Re: [Idr] Comments on draft-vandevelde-idr-remote… Keyur Patel (keyupate)
- Re: [Idr] Comments on draft-vandevelde-idr-remote… Susan Hares