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

[Jeffrey Haas <[e-mail]>]

[Echoing some of the comments from the IDR session at IETF-123]

It's been a number of years since I've seen a suggested feature I've disliked this much.

The first part is trying to upend the protocol machinery to turn a withdraw into an add.  I'd suggest this is an outright non-starter.

The second is more general distaste to the UPA scenario in general.  Shooting holes in your reachability rather than deaggregating?  This is messy enough when you're in an IGP domain that has agreed on this as a consistent set of rules.

In BGP?  There's at least precedent for positive state with some desired anti-forwarding behaviors - effectively a strange form of nexthop:
https://www.rfc-editor.org/rfc/rfc5635

However, similar to the behaviors of RTBH, if you thought the consequences of attribute escape for normal BGP state was bad, now make this poison state safe for general interaction with every router that doesn't support it.  Possible to do using capabilities, but that's the start.

I would strongly suggest to the authors that if you have interest in pursuing this, focus on normal BGP advertising machinery and give deep consideration to scope (blast) containment. 

-- Jeff


> On Sep 2, 2025, at 3:30 PM, Jeff Tantsura <[e-mail]> wrote:
> 
> Hi,
> 
> I support the work, it has quite useful applicability that is going beyond currently described use cases.
> 
> I believe that MP_UNREACH + new SAFI + new capability is the best way to proceed:
> -common way of introducing new feature in BGP in a backward compatible manner
> -enforces route propagation boundaries
> -doesn't’ cause unintended consequences when deployed in brownfield 
> 
> 
> Cheers,
> Jeff
> 
>> 
>> From: Robert Raszuk <[e-mail] <mailto:[e-mail]>>
>> Date: Tuesday, July 8, 2025 at 7:55 PM
>> To: Jakub Horn (jakuhorn) <[e-mail] <mailto:[e-mail]>>
>> Cc: idr@ietf. org <[e-mail] <mailto:[e-mail]>>, Serge Krier (sekrier) <[e-mail] <mailto:[e-mail]>>, Ciurea Mihai, INI-NET-VNC-TIP <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: I-D Action: draft-krierhorn-idr-upa-00.txt
>> 
>> 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. 
>> [JH] correct but we believe what we are proposing is big improvement to the distance vector concept and industry will benefit it greatly
>>  
>> You can't think of propagating BGP withdrawals for the prefixes which were not advertised to the peer before. 
>> [JH] very correct
>>  
>> 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. 
>>  
>> [JH] we spent lot of time discussing this, and we believe that MP_UNREACH is proper way to do that because of backward compatibility and limited reach, but we are very open to discuss other option
>>  
>> 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 :) 
>>  
>> [JH] Certainly! But never applied in BGP (or any distance vector protocol) so this statement is actually prove it is necessary, and need the solution in BGP
>>  
>> 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). 
>>  
>> [JH] this is actually why we picked MP_UNREACH which naturally limits reach of the message to the devices “UPA aware” and will never spread across the boundary! Still open for discussion here
>>  
>> 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). 
>>  
>> [JH] again lot of discussions in that area, and currently we do not believe that new SAFI would be valuable here. Again happy to discuss details here
>>  
>> Kind regards,
>> Robert
>>  
>>  
>> On Tue, Jul 8, 2025 at 2:12 AM Jakub Horn (jakuhorn) <[e-mail] <mailto:[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] <mailto:[e-mail]>>
>> Date: Tuesday, July 8, 2025 at 6:59 AM
>> To: Serge Krier (sekrier) <[e-mail] <mailto:[e-mail]>>, Jakub Horn (jakuhorn) <[e-mail] <mailto:[e-mail]>>, Ciurea Mihai, INI-NET-VNC-TIP <[e-mail] <mailto:[e-mail]>>
>> Cc: idr@ietf. org <[e-mail] <mailto:[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 <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] <mailto:[e-mail]>>
>> Date: Mon, Jul 7, 2025 at 7:41 PM
>> Subject: I-D Action: draft-krierhorn-idr-upa-00.txt
>> To: <[e-mail] <mailto:[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/ <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 <https://www.ietf.org/archive/id/draft-krierhorn-idr-upa-00.html>
>> 
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts
>> 
>> 
>> _______________________________________________
>> I-D-Announce mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>_______________________________________________
>> Idr mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> _______________________________________________
> Idr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]