Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking

[Robert Raszuk <[e-mail]>]

Hi Claudio,


> RFC7911 has no such requirement. At least Section 2 allows to assign
> different path-ids for the same path sent to different peers.
> It would be perfectly fine to use random path ids as long as all
> updates and the final withdraw of this path use the same id.
> Once the path has been withdrawn a new path_id could actually be selected
> again.  This is how I interpret Section 2 of RFC7911 especially this bit:
>

Right I was referring to some implementations then the spec.

> For the described case path_id will work. But in general case, surely
> > selecting path with different next hop as 2nd best will be a good option.
> > In fact some implementations already do that already :)
>
> In my opinon it would be great to have this documented somewhere so that
> all implementations are able to behave the same.
>

FWIW we did document it clearly in RF6774.

The "Nth best path" really
describes set of N paths with different BGP next hops.


But I realize this discussion is about RFC7911.

I recall the intention was to keep the spec short but provide guidelines in
separate document:

Namely in draft-ietf-idr-add-paths-guidelines-08.

There you can see section 4.3.1.1 is very clear on what paths should be
selected based on the three criteria:

     (a) not selected during a previous iteration

     (b)_diverse with respect to previously selected paths (see
section <https://datatracker.ietf.org/doc/html/draft-ietf-idr-add-paths-guidelines-08#section-2>
     2 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-add-paths-guidelines-08#section-2>
for the definition of a diverse path)
     (c) not rejected by route filters or split horizon advertisement
     rules


for us key is (b) and diverse path definition says:

   Diverse path: A BGP path associated with a different BGP next-hop and
   BGP router than some other set of paths. The BGP router associated
   with a path is inferred from the ORIGINATOR_ID attribute or, if there
   is none, the BGP Identifier of the peer that advertised the path.


making it clear that sending N paths should have different next hops.

I am not sure why this draft was not progressed though. At least it is WG
document.

Many thx,
R.



> Using the nexthop as a tie-breaker makes sense to me. I agree that path-id
> is not the best criteria but it is the only one that can actually
> distinguish two paths that are equal. RFC7911 does not specify that a
> peer MUST NOT send paths with equivalent attributes over add-path.
> So I guess one has to assume that a system may actually do that.
>
> --
> :wq Claudio
>