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

["Keyur Patel (keyupate)" <[e-mail]>]

Hi Jeff,

Thanks for the comments on 08 version. :) My comments inlined #Keyur

On 10/15/14, 10:00 AM, "Jeffrey Haas" <[e-mail]> wrote:

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

#Keyur: No worries Jeff. Thanks again for the review.
>
>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. :-)

#Keyur: We can clarify it in next revision.

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

#Keyur: Sure. It doesn¹t break the network or induce loops. This allows
compatibility 
within the network with routers that are not Enabled with this feature.

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

#Keyur: Section 7.1 and 7.2 talks originating of RNH attribute and its
announcement procedures. Section 7.1 also refers to policy usage that can
be applied by a receiving speaker. Section 13 suggest use of Origin
validation procedures that a receiving speaker can also apply. These
procedures help identify whether the source AS owns tunnel endpoints or
not (MIM). The receiving speaker can choose to filter the attribute based
on the information provided.

If you like, we will make it explicit in the next revision.

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

#Keyur: Ack. That is the case. Section 7.1, 7.2 and section 9 spells it
out. 
>
>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.

#Keyur: I will work offline with you on the edits.

>
>In short: looking better, looking less scary, still needs some work.

#Keyur: Thanks. Good to know. :)

Regards,
Keyur
>
>-- Jeff
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr