[Idr] Open issues with Comments on draft-vandevelde-idr-remote-next-hop-08

["Susan Hares" <[e-mail]>]

 

Many of you have read of my concern regarding the proliferation of nexthop
setting in the L2VPN and L3VPN.  I personally am interested to find out if
there is a clean way to distribute tunnel-endpoints/remote next-hops.  This
arises from my reading of several next-hop related drafts, and specifically
draft-sajassi-l2vpn-evpn-inter-subnet-forwarding which stuff next-hops
information into a series of communities. While I credit the Ali and his
co-authors with a delightful hack, it brings up that IDR has not really
provided a good general mechanism for tunnels/remote next hops. 

 

As we have discussed the next-hop issue over the last 10 years, we have
found the more general solution for next-hops is hard.  We have ended up
adopting more and more point solutions.  Our current potential solutions
such as RFC 5512 and draft-vandevelde-idr-remote-next-hop-08. Are there
other solutions? 

 

These solutions must at least consider how this will interact with SIDR
origin validation and bgp-sec. Please let me know if you have interesting
work we should discuss.  If we run out of time at IETF 91, we will hold
these discussions in interim meetings after IETF 91. 

 

In this light, I offer 11 summary discussion points on the
draft-vandevelde-idr-remote-08 draft. I appreciate the hard work that the
authors of this draft have done in originating and refining the draft.  If
you wish to discuss one of these points, I recommend you repost the point
and begin the discussion. 

 

Sue Hares

 

------------

 

 

Open issues from my reading: 

1) RFC 5512 related issues

Comment: Section 3.1 indicates that SAFI includes tunnel, but the
remote-next-hop attribute allows this to be separated from the SAFI.

Question to WG:  Are there any RFC5512 implementations deployed? 

Question to Rosen: Does this section 3.1 in version -08 address your
comments on:  SAFI with different NLRI, multiple tunnel endpoints , RFC5512
avoidance of per NLRI encapsulation. 

 

2. IPv6 multi-homing use case and other use cases 

Concern: Bruno and Yakov have suggested IPv6 multi-homing use case is not
proved.  I agree with their assessment. 

 

Proposal: Pull Use Case 11.1, 11.2, 11.3, and 11.4 out of the draft to
another draft.  We will use this draft to determine the use cases that
remote can handle. Put one use case (11.2 or 11.3) that is fully fleshed out
with: a) why this attribute is needed, b) how this mechanism is better than
existing mechanisms (RFC5512 at least), c) why it is better than other
alternatives, and d) how extensible the alternative is. 

 

One use cases is the 5+ nexthops in various places. The following are
examples:

•                    draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-05 –
puts it in a series of communities,

•                    RFC5512 put it in SAFI

•                    RFC6514 – provides it as part of MPLS for L3VPN

 

•             The use case draft should survey existing uses and then
propose a set of requirements. 

 

3. Discuss why it is necessary to have both a next-hop and remote next hop? 

        The following things need to be improved in this draft:

•                    Clarify that  many nlris to 1 remote nexthop attribute
in a update packet (Example: 30 NLRIs to one Remote Nexthop attribute).
Expanding section 3 might help. 

•                    Why both a next hop (mandatory) and a remote nexthop
(optional transitive)?  This could expand section 10. 

•                    What underlay routes are, and how they are used to do
recursive lookup validation. This is mentioned in the security section, but
it clearly needs to also be in the operational section.

•                    How next-hop and the remote nexthop operate in bestpath
selection. Keyur indicated it followed this logic:

 

o   policy validates the use of remote next hop 

o   If the remote next-hop valid to policy, the remote next hop is used in
preference to nexthop. 

o   If the remote next-hop is valid but does not have a valid recursive
nexthop, then the next hop is selected.

 

•                    Tie breaking needs to be defined within the above logic
for:

o   tie-breaking between two valid remote-nexthops for the cases:

§   two routes have the same nexthop hop and different valid
remote-nexthops,

§  two routes have different nexthops and the same valid remote nexthop. 

 

o   Check that the validation of this work solves the following situations
mentioned by Eric Rosen: 

§  Situation 1:  “Can we get into a situation where two routes have the same
next hop but different remote next hops?  If we reach the decision process
tie-breaker step that chooses the route with the closest next hop, we might
end up  choosing the route that does not have the closest remote next hop.
Since the remote next hop is where we want to send the  data, does this make
sense?

§  Situation 2: “Suppose a given route does not have a remote next hop, but
when we do recursive resolution of the next hop we encounter a route that
does have a remote next hop.  Are we supposed to use that remote next hop?

§  Situation 3:  When a remote next hop attribute is attached to a labeled
address,  do we  assume that the label has been assigned by the remote next
hop, or by the  next hop?  If a BGP speaker changes the next hop but not
the remote next  hop, does it have to assign a new label?

 

o   Changing of next hops and remote next-hops:

§  Is it even valid to change the next hop without changing or removing the
remote next hop attribute?

4. Discuss impact of leakage of this attribute:

Concern: Since the remote next hop attribute is a transitive attribute, it
can easily be leaked outside of the administrative domain to which it
applies.  This could result in all kinds of strange effects on the routing
upstream.  

 

Discuss: One might point out that in the RFC 5512 model it is less likely
that information leaks out, since the encapsulation-SAFI would have to be
explicitly enabled. Is this true or false? 

 

5. Discuss impact of the remote next hop attribute to different address
families

 

Proposal: A summary of this impact to address families should be included in
the use case drafts, and a specific consideration should be given for the 1
or 2 use cases in the document. 

What to discuss: Walk through all NLRI families passed through BGP and
discuss how next hop impacts this work. 

 

 

7.  AS linkage

Concern: The attribute as defined contains an AS number, but there are no
procedures specified that make use of the AS number.

 

Question for WG: does section 7.1 and 7.2 provide enough procedures? 

 

8.  Tunnel endpoint 

Concern: Address length implies AFI  Is it better to specific tis directly
in section 4.0  

•Discussion:  It is better and extensible to specify the TLV (afi, length,
value).  Currently, the address family of the tunnel endpoint needs to be
inferred from  its length; it might be better to explicitly encode the
address family.

 

9. Bestpath considerations:

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

 

Discussion:  Please indicate how you will prevent fluctuation in the path
selection. 

 

10. Multiple remote nexthops:

 

Concern: This was Jeff’s 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.

 

11. Origination/modification:

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

 

Counter-point: Keyur indicated that intermediaries may add this feature if
they become the new originator of this attribute.  

 

What needs to be discussed:   A add/remove scenario should be examined with
four AS scenario (AS-1—AS2—AS3—AS4)