[Idr] Re: I-D Action: draft-krierhorn-idr-upa-00.txt

[Robert Raszuk <[e-mail]>]

Hi Jakub,

Due to personal reasons I am not planning to be in Madrid. However we could
always chat here on the list or directly say via zoom or webex.

As I mentioned in your draft I see fundamental issues which IMO are
blocking for even an adoption call.

Just to start with the most important issue:

You say:

" The specific prefix whose reachability is lost is encoded in the

   MP_UNREACH_NLRI attribute [RFC4760]."

+

"A new Transitive IPv4-Address-Specific Extended Community is defined

   for UPA."

+

"  The UPA state for the prefix SHOULD be retained for a time period to

   ensure it has been propagated to its neighbors and avoid generation
   of multiple UPA messages for the same prefix."

+

"10.  UPA Timer

   The UPA state needs to be retained in the BGP table for a
   configurable duration.  This is crucial to prevent unwanted flooding
   and to allow sufficient time for the UPA to be propagated to all
   relevant peers.

"


Well all of the above is not how BGP or for that matter any distance
vector protocol works.

You can't think of propagating BGP withdrawals for the prefixes which were
not advertised to the peer before.

If you really want to do that you need to use MP_REACH attribute not
MP_UNREACH_NLRI. But for
MP_REACH you would need to make sure that suddenly it propagates negative
routes.

The concept of negative routes is not new. If you search the CPOL database
you will likely find a few
entries there and methods on how to do that :)

Another major concern is leakage. As you may be reading the IDR list there
are reports of BGP attributes escaping and leaking. Here you are opening a
completely new chapter and as this is called to be supported in 2/1 global
IPv6 table may one day explode due to a bunch of negative routes generated
intentionally or not by someone or something (again assuming that you
switch from using MP_UNREACH_NLRI as this goes to your peer and no further
to MP_REACH).

Maybe if you really want to do that in BGP you need a new SAFI where you
can safely redefine the semantics of UPDATE message (just like we did it
for a bunch of new functionality).

Kind regards,
Robert


On Tue, Jul 8, 2025 at 2:12 AM Jakub Horn (jakuhorn) <[e-mail]>
wrote:

> Hi Robert,
>
>
>
> Thanks a lot for your initial comments and pointing us to your older
> draft. I think if I correctly understand your draft is addresses something
> slightly different than ours. Yours addresses mainly “mass withdrawal” our
> is trying to address “advertise unreachability of the specific component of
> aggregate”. But still happy to discuss your approach f2f in Madrid as there
> might be some useful synergies in both.
>
> Looking forward for more comments!
>
>
>
> Thanks
>
>
>
> -j
>
>
>
> *From: *Robert Raszuk <[e-mail]>
> *Date: *Tuesday, July 8, 2025 at 6:59 AM
> *To: *Serge Krier (sekrier) <[e-mail]>, Jakub Horn (jakuhorn) <
> [e-mail]>, Ciurea Mihai, INI-NET-VNC-TIP <
> [e-mail]>
> *Cc: *idr@ietf. org <[e-mail]>
> *Subject: *Fwd: I-D Action: draft-krierhorn-idr-upa-00.txt
>
> Hi,
>
>
>
> Allow me to observe before even further commenting on the draft that
> motivation for the IGP UPA work was based on the trigger of node down event
> (planned or unplanned) in one non backbone areas.
>
>
>
> With that the analogy in the BGP world is not to advertise all atomic
> prefixes which may have become unreachable, but instead quickly propagate
> information about the next hop down event which is by design shared across
> all such prefixes/locators.
>
>
>
> I along with few collegues in 2005 we wrote a draft -
> https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt
>
>
>
> At that time there was no sufficient interest in signalling such events in
> BGP.
>
>
>
> If you think that times have changed I recommend you take a look at this
> draft and possibly respin it or reuse it.
>
>
>
> Thx a lot,
>
> Robert
>
>
>
> PS. After a quick read I do have a number of comments on the text in the
> draft however before we go down that path let's consider the alternative
> approach.
>
>
>
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, Jul 7, 2025 at 7:41 PM
> Subject: I-D Action: draft-krierhorn-idr-upa-00.txt
> To: <[e-mail]>
>
>
>
> Internet-Draft draft-krierhorn-idr-upa-00.txt is now available.
>
>    Title:   SRv6 BGP Unreachable Prefix Announcement (UPA)
>    Authors: Serge Krier
>             Jakub Horn
>             Mihai Ciurea
>    Name:    draft-krierhorn-idr-upa-00.txt
>    Pages:   8
>    Dates:   2025-07-07
>
> Abstract:
>
>    Summarization is often used in multi-domain networks to improve
>    network efficiency and scalability.  With summarization in place,
>    there is a need to signal loss of reachability to an individual
>    prefix covered by the summary.  This enables fast convergence by
>    steering traffic away from the node which owns the prefix and is no
>    longer reachable.
>
>    This mechanism, referred to as Unreachable Prefix Announcement (UPA),
>    has been specified for IGPs.  This document specifies an and
>    equivalent BGP mechanism for multi-AS networks where BGP is used to
>    carry summary routes.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-krierhorn-idr-upa/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-krierhorn-idr-upa-00.html
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>