Subject: [Sidrops] draft-ietf-sidrops-8210bis

From: Randy Bush <[email-masked]>
Date: Sat, 29 Aug 2020 10:14:24 -0700

draft-ietf-sidrops-8210bis has

   1.2.  Changes from RFC 8210

   This section summarizes the significant changes between [RFC6810] and
   the protocol described in this document.

   o  New ASPA PDU type (Section 5.12) added to support
      [I-D.ietf-sidrops-aspa-profile].

   o  A small section, Section 11, has been added to handle two ROA PDU
      race conditions, Break Before Make and Shorter Prefix First.

it is not clear there is a rush on ASPA.  as ROA PDU Race Minimization
has serious effect on cache behavior,

   11.  ROA PDU Race Minimization

   When a cache is sending ROA PDUs to the router, especially during an
   initial full load, two undesirable race conditions are possible:

   Break Before Make:  For some prefix P, an AS may announce two (or
      more) ROAs because they are in the process of changing what
      provider AS is announcing P.  This is is a case of "make before
      break."  If a cache is feeding a router and sends the one not yet
      in service a significant time before sending the one currently in
      service, then BGP data could be marked invalid during the
      interval.  To minimize that interval, the cache SHOULD announce
      all ROAs for the same prefix as close to sequentially as possible.

   Shorter Prefix First:  If an AS has issued a ROA for P0, and another
      AS (likely their customer) has issued a ROA for P1 which is a sub-
      prefix of P0, a router which receives the ROA for P0 before that
      for P1 is likely to mark a BGP prefix P1 invalid.  Therefore, the
      cache SHOULD announce the sub-prefix P1 before the covering prefix
      P0.

this has overlap with a discussion Job was having.  i would like to
close on this and get it out the door.  but it would be good if folk,
reread, thought, and commented.

randy

---

From: Di Ma <[email-masked]>
Date: Mon, 31 Aug 2020 09:59:25 +0800

Randy,

As far as I observe, two measures can be taken to avoid ROA PDU race.

One could be done by RP software by sorting PDU as per prefix and its length, before sending to routers.

The other one could be done by routers by establishing a transaction of RTR session before effecting those in routing table.

I think the first one can only mitigate the issue but the second one can really resolve the problem which calls for router software update.

Di

> 2020年8月30日 01:14，Randy Bush <[email-masked]> 写道：
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Randy Bush <[email-masked]>
Date: Sun, 30 Aug 2020 20:18:38 -0700

> The other one could be done by routers by establishing a transaction
> of RTR session before effecting those in routing table.

you might have a small discussion with a router implementor about where
they would like to store the uncommited transaction.  consider two
things, many current routers still have a 32-bit memory model, and a
transaction could be a full dump cold start from a cache.

randy

---

From: Di Ma <[email-masked]>
Date: Mon, 31 Aug 2020 11:33:01 +0800

Exactly.

I am exchanging notes with friends working for vendors on the issue you raised.

It would be better to hear from router implementors in the list.

Di

> 2020年8月31日 11:18，Randy Bush <[email-masked]> 写道：
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 31 Aug 2020 04:34:42 +0000

I was going to suggest the same thing.
Since there can only be one transaction outstanding from any one
cache, the state can be stored as flags on the records.
You would need to add that any PDU following the data PDUs
other than an End Of Data will invalidate the previous data PDUs.
For example, a Serial Notify or a Cache Response.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Di Ma
Sent: Sunday, August 30, 2020 8:33 PM
To: Randy Bush <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>
Subject: Re: [Sidrops] draft-ietf-sidrops-8210bis

Exactly.

Di