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

RFC 7911 section 2

   The assignment of the Path Identifier for a path by a BGP speaker is
   purely a local matter.  However, the Path Identifier MUST be assigned
   in such a way that the BGP speaker is able to use the (Prefix, Path
   Identifier) to uniquely identify a path advertised to a neighbor.  A
   BGP speaker that re-advertises a route MUST generate its own Path
   Identifier to be associated with the re-advertised route.  A BGP
   speaker that receives a route should not assume that the identifier
   carries any particular semantics.

As the path-is is locally generated it should always be unique - 32
bit unsigned integer.

Gyan

On Thu, Jun 24, 2021 at 6:28 PM Jakob Heitz (jheitz) <jheitz=
40cisco.com@dmarc.ietf.org> wrote:

> And then when the attribute length is equal, you'll need another
> tie-breaker.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of * Jakob Heitz (jheitz)
> *Sent:* Thursday, June 24, 2021 3:20 PM
> *To:* Robert Raszuk <robert@raszuk.net>; John Scudder <jgs=
> 40juniper.net@dmarc.ietf.org>
> *Cc:* dwalton76@gmail.com; idr@ietf. org <idr@ietf.org>
> *Subject:* Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking
>
>
>
> Then the code would have to compute the attribute length for each path,
> carry it along and pass it to the bestpath compare function.
>
> For what? To increase convergence time?
>
> Because simple byte length will not be good enough and people will start
> arguing that
>
> an extended community is just as valuable as a regular community and count
> the number of communities
>
> rather than bytes and then the tunnel attribute is longer and on and on.
>
> I vote for path-id.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, June 24, 2021 1:40 PM
> *To:* John Scudder <jgs=40juniper.net@dmarc.ietf.org>
> *Cc:* dwalton76@gmail.com; idr@ietf. org <idr@ietf.org>
> *Subject:* Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking
>
>
>
> John,
>
>
>
> > because it’s technically possible to receive two routes for the same
> destination, from the same peer, with different path-id, and with all
> tie-break metrics the same
>
>
>
> While this is not about risk of loops, those paths may possibly contain
> different optional attributes otherwise they would be rather duplicates.
>
>
>
> More specifically one of them may contain additional optional attributes
> while the other may not.
>
>
>
> Perhaps with add-paths while we are at this discussion it may make sense
> to choose the path with a longer list of BGP path attributes as such
> path may be more useful to receivers.
>
>
>
> Only then when the number of such attributes  is the same fall to path_id
> as tie-break.
>
>
>
> Thx,
>
> Robert
>
>
>
>
>
> On Thu, Jun 24, 2021 at 8:15 PM John Scudder <jgs=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> Hi Folks,
>
> Claudio recently pointed out a bug in RFC 7911 to the authors, and we
> thought we should let the WG know. The gist of the bug is that the
> tie-breaking process is underspecified, because it’s technically possible
> to receive two routes for the same destination, from the same peer, with
> different path-id, and with all tie-break metrics the same (all the way
> down to peer address). My guess — but it’s only a guess, I haven’t checked
> — is that implementations may mostly have chosen to prefer the first path
> received.[*] But the only thing we can say with confidence is “it’s
> underspecified and therefore implementation-dependent.”
>
> When I worked through this, my conclusion was that whatever option an
> implementation chooses should be safe, since by definition the paths are
> equivalent all the way down. I don’t see a way to form a loop even if every
> router in the network makes arbitrary — and conflicting — choices in this
> situation, since by definition of IGP distance, if a given router A makes
> an arbitrary choice, none of its neighbors when presented with the same set
> of routes will make a conflicting arbitrary choice, since the options are:
>
> - The peer is closer to both destinations, in which case it can make any
> choice it wants, the traffic will not loop back to A,
> - The peer is further from both destinations, in which case it can make
> any choice it wants, the traffic will not loop back from A,
> - The peer is closer to one and further from the other destination, in
> which case it isn’t faced with a dilemma, it will choose the closer (and
> the traffic won’t go back towards A).
>
> I guess if you’re in a network that doesn’t have IGP distances at all
> (maybe everything is static routed?) or if IGP distances don’t follow the
> usual rules of IGP “physics”, then you could create a problem. But those
> are pathological cases where we’d expect BGP not to work very well anyway.
>
> Claudio suggested that path-id would be a good final tie-break; that makes
> sense to me. We could do a quick update to 7911 to standardize this new
> tie-break, we could do a bis of 7911 to include the new tie-break, or we
> could just leave things as they are, relying on my argument above that says
> there is no strong need to standardize a tie-break since any choice is OK.
>
> For the moment, this is just an FYI for the WG. Thanks very much to
> Claudio for pointing out the bug!
>
> —John
>
> [*] You may notice that it’s possible to have two such paths packed into
> the same update in some circumstances, which makes the choice even more
> arbitrary since it’s pretty notional to say one has arrived before the
> other.
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*