Re: [Idr] Comments on draft-vandevelde-idr-remote-next-hop-08

Jeff:

Thank you for the comments.  I agree these need to be addressed.  See my
summary post.  Did I correctly summarize your concers? 

Sue 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Wednesday, October 15, 2014 1:01 PM
To: idr@ietf.org
Subject: [Idr] Comments on draft-vandevelde-idr-remote-next-hop-08

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 mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr