< speaking as a WG participant > Hi Aijun,
Perhaps you may have better experience in having a discussion on this document along with the related technologies, their implementation, and deployment design working with someone in a high bandwidth (perhaps face to face) setting. I get the impression that this discussion on email may not meet your expectations. At least I could not find anything more to add to explain how this thing works, but perhaps there is some IETF participant who can explain this to you in a better way. Best wishes, Ketan On Wed, May 28, 2025 at 2:28 PM Aijun Wang <[email protected]> wrote: > Your previous responses at here > https://mailarchive.ietf.org/arch/msg/lsr/EFb71fc-hc-_oMCnksOZfSPt0-o/ is > also for Case 2. > Where your responses for Case 1? > Please give the link. > > Or else, it will be registered for further clarification. > > -----邮件原件----- > 发件人: Peter Psenak [mailto:[email protected]] > 发送时间: 2025年5月28日 16:48 > 收件人: Aijun Wang <[email protected]>; 'Gunter van de Velde > (Nokia)' <[email protected]> > 抄送: [email protected] > 主题: Re: 答复: 答复: 答复: [Lsr] Re: 答复: I-D Action: > draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > > On 28/05/2025 10:46, Aijun Wang wrote: > > OK, you say Gunter talk about the Case 2. It's no problem. > > > > Then, what's your considerations of Case 1? > > I have already responded to that. I'm done with this thread. > > Peter > > > > > -----邮件原件----- > > 发件人: Peter Psenak [mailto:[email protected]] > > 发送时间: 2025年5月28日 16:40 > > 收件人: Aijun Wang <[email protected]>; 'Gunter van de Velde > > (Nokia)' <[email protected]> > > 抄送: [email protected] > > 主题: Re: 答复: 答复: [Lsr] Re: 答复: I-D Action: > > draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > > > > On 28/05/2025 10:24, Aijun Wang wrote: > >> Hi, Peter: > >> > >> We are talking about when to switch back to the remote failure PE, not > switch from it. > >> > >> In Case 1, when UPA advertise for a configured time to "allows BGP to > converge after the remote PE failure ", then ABR stop advertising UPA, > right? > >> At this moment, should the receiver switch back BGP PIC to the previous > failure PE? > > it can not switch back to failed PE, because BGP on remote nodes know > that such PE does not exist anymore - e.g. BGP has converged. > > > >> According to Gunter's logic, it should switch back to the previous > failure PE, because the summary address indicates the specific failure PE > is reachable again. > > Gunter was talking about the case, where the remote PE loopback prefix > reachability was recovered shortly after the UPA was generated, so there > would still be a valid BGP path via such PE. > > > > Peter > > > > > >> What's your thought? > >> > >> > >> Best Regards > >> > >> Aijun Wang > >> China Telecom > >> > >> -----邮件原件----- > >> 发件人: Peter Psenak [mailto:[email protected]] > >> 发送时间: 2025年5月28日 16:10 > >> 收件人: Aijun Wang <[email protected]>; 'Gunter van de Velde > >> (Nokia)' <[email protected]> > >> 抄送: [email protected] > >> 主题: Re: 答复: [Lsr] Re: 答复: I-D Action: > >> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >> > >> On 28/05/2025 09:35, Aijun Wang wrote: > >>> Hi, Gunter: > >>> > >>> I don’t recommend to design one " brand-new control plane signal " to > signal the prefix reachability. > >>> > >>> What I argue with you until now, is the following statements: > >>> "when a UPA stops being advertised, that unreachability signal goes > away, and at that point, the summary route takes over and signals > reachability." > >>> > >>> From the UPA document, we can know there at least two reasons can > lead the "UPA stops being advertised": > >>> Case 1: "UPA advertisements SHOULD therefore be withdrawn after some > amount of time, that would provide sufficient time for UPA to be flooded > network-wide and acted upon by receiving nodes, but limits the presence of > UPA in the network." > >>> Case 2: " ABR or ASBR MUST withdraw the previously advertised UPA when > the reason for which the UPA was generated was lost " > >>> > >>> Then, if the reason that lead " UPA stops being advertised " is Case > 1, then your logic that " at that point, the summary route takes over and > signals reachability." is wrong. > >>> When the BGP PIC FRR switch back at this moment, the traffic will be > lost. > >> no. > >> > >> The draft also says: > >> > >> "The time the UPA is kept in the network SHOULD also reflect the > intended use-case for which the UPA was advertised." > >> > >> For BGP PIC, you need to keep it for a time that allows BGP to converge > after the remote PE failure. > >> > >> Peter > >> > >> > >>> Best Regards > >>> > >>> Aijun Wang > >>> China Telecom > >>> > >>> -----邮件原件----- > >>> 发件人: [email protected] > >>> [mailto:[email protected]] 代表 Gunter van de Velde (Nokia) > >>> 发送时间: 2025年5月28日 15:04 > >>> 收件人: Aijun Wang <[email protected]> > >>> 抄送: [email protected]; 'Peter Psenak' <[email protected]> > >>> 主题: [Lsr] Re: 答复: I-D Action: > >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> > >>> [speaking as work group participant] > >>> > >>> Hi Aijun, > >>> > >>> Let’s wrap up this thread. I feel we’ve explored this topic quite > thoroughly from different angles, and I’d prefer not to keep circling back > and repeating the same points. > >>> (this is my last email on this thread) > >>> > >>> Regarding your comment: > >>> " > >>> 1) The data-plane OAM tools(BFD, ICMP, STAMP, and TWAMP) should be > used to test and verify the prefix reachability. > >>> Along the evolution of PUAM/UPA drafts, there are lots of > discussions among the efficiency of these OAM tools, versus the PUAM/UPA > mechanism. > >>> I think you may miss these previous discussions. > >>> Here I want just to say, if the WG agree with you, the PUAM/UPA > draft shouldn't be existed. > >>> " > >>> > >>> Let me try to explain my point again, one last time, just in a > different way for clarity. > >>> > >>> A router forwards packets based on the unicast forwarding table, which > is typically populated by routing protocols like OSPF or IS-IS. Once a > route is selected, the router uses that information to forward packets, > plain and simple. But here’s the thing: the router doesn’t really “know” if > the packet will make it all the way to its final destination. It just > follows the best path it has available, based on its local view. What > happens downstream, packet drops, blackholing, filtering, or misrouting. > can’t be predicted by the control plane alone. That’s just the reality of > distributed routing. > >>> > >>> At the end of the day, if we really want to be sure something is > reachable and working as expected, the best way to confirm that is to > actually test it. > >>> Tools like BFD, ICMP, STAMP, and TWAMP are exactly what we use to > validate that, since they measure actual behavior in the data plane. > >>> > >>> From your comments, it sounds like you're proposing a new control > plane signal that says, “Hey, trust me, I’m really reachable.” But I’m not > convinced such a signal would be any more reliable than the routes we > already learn through established routing protocols like OSPF or IS-IS. > That kind of new control plane signal could still be based on outdated, > incorrect, or incomplete information, and wouldn’t really help when it > comes to truly assessing data plane reachability. > >>> > >>> Coming back to UPA. When using UPA the procedure as described in [1], > [2], and [3] is predictable and behaves in an operationally efficient way. > That way, in most cases, we don’t even need to rely on OAM data plane > testing tools. From my point of view, adding a new control plane message to > somehow validate reachability on top of an already installed unicast route > doesn’t really add much value. Instead, it risks introducing more > complexity without solving a real problem. > >>> > >>> Regarding your comment: > >>> " > >>> 2) In BGP PIC FRR scenario, when the router stops receiving the UPA > signal, and "switching back to the primary egress router" is wrong. > >>> As stated in your reply, stop receiving the UPA signal " > ...doesn’t imply anything about whether the prefix is reachable ", then, > when the prefix is still unreachable, switch back to the primary egress > router > >>> will result in the traffic black hole. > >>> " > >>> > >>> GV> If the UPA disappears then the assumption is that the prefix is > indeed reachable, assuming the prefix would be a member prefix covered by > the summary route. See [1],[2] and [3] for the procedure. This is basic > network behavior when using aggregate routes on ABRs. If this is not the > behavior desired, then an alternative is to not summarize prefixes into > aggregate prefixes (but this has other operational implications). > >>> > >>> " > >>> In summary, current UPA proposal try to signal the unreachability on > demand, but lack of the signaling mechanism to revoke such announcement on > demand. > >>> " > >>> > >>> GV> What I’m saying is pretty straightforward: when a UPA stops being > advertised, that unreachability signal goes away, and at that point, the > summary route takes over and signals reachability. Summary routes have been > used in networks for years and has worked reliably. That’s why I’m having a > hard time understanding how introducing a brand-new control plane message > to signal destination reachability would actually help. It doesn’t really > add anything new when it comes to confirming data plane reachability, and > we already have mechanisms that work well in practice. > >>> > >>> Note that this was my last email on this subject as I think we now > discussed this enough. > >>> > >>> Brgds, > >>> G/ > >>> [speaking as work group participant] > >>> > >>> [1] > >>> https://mailarchive.ietf.org/arch/msg/lsr/EFb71fc-hc-_oMCnksOZfSPt0- > >>> o > >>> / > >>> {2] > >>> https://mailarchive.ietf.org/arch/msg/lsr/aAyfU1ziWTuTltmZoCGO1vht7Q > >>> k > >>> / > >>> {3] > >>> https://mailarchive.ietf.org/arch/msg/lsr/hg_v2ZAOkz5bhxE4979viIowkI > >>> U > >>> / > >>> > >>> -----Original Message----- > >>> From: Aijun Wang <[email protected]> > >>> Sent: Wednesday, May 28, 2025 3:06 AM > >>> To: Gunter van de Velde (Nokia) <[email protected]> > >>> Cc: [email protected]; 'Peter Psenak' <[email protected]> > >>> Subject: 答复: [Lsr] Re: 答复: I-D Action: > >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> > >>> > >>> CAUTION: This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > >>> > >>> > >>> > >>> Hi, Gunter: > >>> > >>> There are two misunderstanding in your arguments: > >>> 1) The data-plane OAM tools(BFD, ICMP, STAMP, and TWAMP) should be > used to test and verify the prefix reachability. > >>> Along the evolution of PUAM/UPA drafts, there are lots of > discussions among the efficiency of these OAM tools, versus the PUAM/UPA > mechanism. > >>> I think you may miss these previous discussions. > >>> Here I want just to say, if the WG agree with you, the PUAM/UPA > draft shouldn't be existed. > >>> > >>> 2) In BGP PIC FRR scenario, when the router stops receiving the UPA > signal, and "switching back to the primary egress router" is wrong. > >>> As stated in your reply, stop receiving the UPA signal " > ...doesn’t imply anything about whether the prefix is reachable ", then, > when the prefix is still unreachable, switch back to the primary egress > router > >>> will result in the traffic black hole. > >>> > >>> In summary, current UPA proposal try to signal the unreachability on > demand, but lack of the signaling mechanism to revoke such announcement on > demand. > >>> > >>> > >>> Best Regards > >>> > >>> Aijun Wang > >>> China Telecom > >>> > >>> -----邮件原件----- > >>> 发件人: Gunter van de Velde (Nokia) > >>> [mailto:[email protected]] > >>> 发送时间: 2025年5月27日 17:39 > >>> 收件人: Aijun Wang <[email protected]> > >>> 抄送: [email protected]; 'Peter Psenak' <[email protected]> > >>> 主题: RE: [Lsr] Re: 答复: I-D Action: > >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> > >>> [speaking as work group participant] > >>> > >>> A router makes its forwarding decisions based on the routes it has in > the unicast forwarding table, which are populated by the control plane. > When a packet comes in, the router looks up the destination, and if there’s > a match, it uses the forwarding info tied to the best route it has at that > moment to send the packet on its way. > >>> > >>> It is worth pointing out that the router doesn’t actually know whether > the packet will make it all the way to the final destination. It simply > follows the best available path based on local routing information. Along > the way, anything from packet filtering, DDoS mitigation, or buffer drops > could affect delivery, that’s just the nature of network behavior. > >>> > >>> If there are concerns about whether a specific destination is actually > reachable, that’s where data-plane OAM tools come in. Things like BFD, > ICMP, STAMP, and TWAMP are built specifically to test and verify > reachability beyond what the control plane can determine. > >>> > >>> To clarify something mentioned earlier when I said “when the UPA is no > longer advertised and only the summary prefix remains, the system quickly > and gracefully reverts back to the original state without any issues,” I > meant exactly that. It doesn’t imply anything about whether the prefix is > reachable, it just means the system sees the UPA is gone, and so it reverts > to whatever route is considered best in the routing table. > >>> > >>> In the case of BGP PIC FRR, that usually means switching back to the > primary egress router, depending on how the feature is configured. Whether > it actually switches back or sticks with the alternate path depends on the > specific BGP PIC settings and current network state. > >>> > >>> G/ > >>> (speaking as WG participant) > >>> > >>> > >>> -----Original Message----- > >>> From: Aijun Wang <[email protected]> > >>> Sent: Tuesday, May 27, 2025 10:47 AM > >>> To: Gunter van de Velde (Nokia) <[email protected]> > >>> Cc: [email protected]; 'Peter Psenak' <[email protected]> > >>> Subject: 答复: [Lsr] Re: 答复: I-D Action: > >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> > >>> > >>> CAUTION: This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > >>> > >>> > >>> > >>> Hi, Gunter: > >>> > >>> Here is the tricky issue: > >>> "when the UPA is no longer advertised and only the summary prefix > remains, the system quickly and gracefully reverts back to the original > state without any issues." > >>> > >>> Then, you assumes that: when no UPA is advertised, the specific > prefix is reachable again? > >>> > >>> > >>> Best Regards > >>> > >>> Aijun Wang > >>> China Telecom > >>> > >>> -----邮件原件----- > >>> 发件人: Gunter van de Velde (Nokia) > >>> [mailto:[email protected]] > >>> 发送时间: 2025年5月27日 16:17 > >>> 收件人: Aijun Wang <[email protected]> > >>> 抄送: [email protected]; Peter Psenak <[email protected]> > >>> 主题: RE: [Lsr] Re: 答复: I-D Action: > >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> > >>> [speaking as work group participant] > >>> > >>> Hi Aijun, > >>> > >>> I just wanted to share a couple of thoughts in response to your > message. > >>> > >>> First, I feel your note is revisiting the topic around the PUA draft > [2] in a way that runs counter to the earlier formal warning from Yingzhen > [1]. Reopening that discussion at this point doesn’t help strengthen the > UPA procedures and seems to be circling back on a topic that the working > group has already moved past. > >>> > >>> Second, based on the procedures outlined in the UPA draft [3], my > development team has successfully implemented UPA and is using it as > foundational part of our BGP PIC FRR solution. We’re quite familiar with > how link-state protocols operate, and we’ve found the documented behavior > in [3] to be sufficient for developing an interoperable and reliable > implementation. In our solution, the UPA is used to trigger BGP PIC fast > reroute exactly as Peter described [4]. When a UPA is received, the BGP PIC > FRR process kicks in, and when the UPA is no longer advertised and only the > summary prefix remains, the system quickly and gracefully reverts back to > the original state without any issues. This solution is now used by network > operators who understand the procedures of link-state routing protocols, > UPA and BGP PIC FRR well. > >>> > >>> [1] > >>> https://mailarchive.ietf.org/arch/msg/lsr/S7Mqk2JljYgG8kjEPmH6KlLtbf > >>> w > >>> / > >>> [2] > >>> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-a > >>> n > >>> n > >>> oucement/ [3] > >>> https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-an > >>> n > >>> o > >>> unce/ [4] > >>> https://mailarchive.ietf.org/arch/msg/lsr/EFb71fc-hc-_oMCnksOZfSPt0- > >>> o > >>> / > >>> > >>> Hope this helps clarify our experience and perspective. > >>> > >>> Gunter Van de Velde > >>> (speaking as WG participant) > >>> > >>> > >>> > >>> From: Aijun Wang <[email protected]> > >>> Sent: Tuesday, May 27, 2025 1:05 AM > >>> To: Peter Psenak <[email protected]> > >>> Cc: [email protected] > >>> Subject: [Lsr] Re: 答复: I-D Action: > >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> > >>> > >>> CAUTION: This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > >>> > >>> Hi, Peter: > >>> > >>> Please refrain your comments. > >>> As the initiators of such mechanism, we describe the whole process 3 > years earlier than the first version of your draft. > >>> > >>> Respect the creator of any idea is the basic behavior of IETF > community. > >>> > >>> Back to your example: > >>> You forgot the important part of the puzzle—-the application that the > UPA triggered. > >>> > >>> How and when the application being triggered back to its original > state? > >>> > >>> Image one scenario, some nodes advertised accidentally the wrong UPA > signals within the network, how can you revoke it quickly and eliminate the > wrong triggered actions? > >>> > >>> > >>> Aijun Wang > >>> China Telecom > >>> > >>> > >>> On May 26, 2025, at 17:52, Peter Psenak <mailto:[email protected]> > wrote: > >>> > >>> On 26/05/2025 10:26, Aijun Wang wrote: > >>> No, summary can’t achieve the same aim of the “Explicit Withdrawn > Signal”, for example, switch back to the application’s original state. > >>> you don't understand the basic operation of the protocol. > >>> 1. prefix p1/32 is summarized with p2/16. P1 is reachable via > >>> summary 2. router that generated p1 went down 3. UPA for p1/32 was > >>> generated 4. router that generated p1 came back 5. UPA was removed > >>> and we are back to state (1) Peter > >>> > >>> 发件人: Peter Psenak [mailto:[email protected]] > >>> 发送时间: 2025年5月26日 15:41 > >>> 收件人: Aijun Wang mailto:[email protected] > >>> 抄送: mailto:[email protected] > >>> 主题: Re: 答复: [Lsr] Re: 答复: I-D Action: > >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> > >>> On 26/05/2025 03:29, Aijun Wang wrote: > >>> Then one new deficiency for the mechanism is emerging: > >>> > >>> The lack of the Explicit Withdrawn Signal(EWS) when the prefix is > reachable again. > >>> Please note, stop sending the UPA message doesn’t mean the prefix is > reachable again. > >>> If there is no EWS, then the network can’t back to its original state > before the UPA signaling when the reachable of prefix recover. > >>> there is still a summary that covers the prefix reachability. > >>> Peter > >>> > >>> > >>> Best Regards > >>> > >>> Aijun Wang > >>> China Telecom > >>> > >>> > >>> > >>> 发件人: Peter Psenak [mailto:[email protected]] > >>> 发送时间: 2025年5月23日 19:11 > >>> 收件人: Aijun Wang mailto:[email protected] > >>> 抄送: mailto:[email protected] > >>> 主题: Re: [Lsr] Re: 答复: I-D Action: > >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> > >>> On 23/05/2025 12:48, Aijun Wang wrote: > >>> Then nothing needs to be standardized when the prefix becomes > reachable again. > >>> > >>> 1) In some critical scenarios, when the ABR sends one UPA message out > and the prefix becomes reachable immediately, what the ABR can do is to > stop advertising UPA. > >>> and that is exactly what the text says. > >>> Peter > >>> > >>> > >>> The sent UPA message will eventually trigger the action on the > receiver, even the prefix is reachable immediately. > >>> > >>> 2) In normal situations, the ABR sends the UPA message for some time > and stop sending it further. At this time, when the prefix becomes > reachable, nothing needs to be done at ABR. > >>> > >>> The receiver will also act on the UPA signaling. > >>> > >>> It’s irrelevant then whether the prefix is reachable or not after the > UPA signaling is sent out. > >>> > >>> > >>> Aijun Wang > >>> China Telecom > >>> > >>> > >>> > >>> > >>> On May 23, 2025, at 17:18, Peter Psenak mailto:[email protected] > wrote: > >>> On 23/05/2025 10:10, Aijun Wang wrote: > >>> Then, what’s the differences between the two statements: > >>> first is for case when the prefix reachability is not regained after > UPA was generated. > >>> Second is when the prefix reachability was regained before the UPA was > withdrawn. It basically says UPA must be withdrawn at the time the prefix > becomes reachable. > >>> > >>> > >>> “UPA advertisements SHOULD therefore be withdrawn after some amount of > time, that would provides sufficient time for UPA to be flooded > network-wide and acted upon by receiving nodes, but limits the presence of > UPA in the network.” > >>> > >>> And: > >>> > >>> “ABR or ASBR MUST withdraw the previously advertised UPA when the > reason for which the UPA was generated was lost - e.g. prefix reachability > was restored or its metric has changed such that it does not represent the > protocol specific maximum prefix metric.” > >>> > >>> Here, does “withdraw” just mean to “stop advertisement”? > >>> yes. > >>> Peter > >>> > >>> If no, what’s the mechanism of second “withdraw”? > >>> > >>> > >>> Best Regards > >>> > >>> Aijun Wang > >>> China Telecom > >>> > >>> 发件人: mailto:[email protected] > >>> [mailto:[email protected]] 代表 Peter Psenak > >>> 发送时间: 2025年5月23日 14:55 > >>> 收件人: Aijun Wang mailto:[email protected]; > >>> mailto:[email protected] > >>> 主题: [Lsr] Re: 答复: I-D Action: > >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> > >>> On 23/05/2025 03:32, Aijun Wang wrote: > >>> Hi, All: > >>> > >>> I must point out that the updated draft doesn't address previous > issues that described in [1]. > >>> Especially, the activation of flawed LSInfinity feature(there is > detail analysis for this flawed feature that is defined in OSPF 2328). > >>> > >>> And, some updated contents will deteriorate the traffic pattern within > the network. > >>> For example, It says: “ABR or ASBR MUST withdraw the previously > advertised UPA when the reason for which the UPA was generated was lost”. > >>> The above requirement will advertise the specific prefixes within the > network, which will weaken the original summary effect, and attract the > traffic via one or some of ABRs. > >>> no, above is not true, the new text does not say to advertise > reachablity for a summarized prefix, it only talks about removing the > previously advertised UPA. > >>> Please read carefully before commenting. > >>> Peter > >>> > >>> > >>> [1]: Reasons of abandoning UPA: > >>> https://datatracker.ietf.org/doc/draft-wang-lsr-reasons-of-abandon-u > >>> p > >>> a > >>> -proposal/ > >>> > >>> > >>> Best Regards > >>> > >>> Aijun Wang > >>> China Telecom > >>> > >>> > >>> > >>> > >>> > >>> -----邮件原件----- > >>> 发件人: mailto:[email protected] > >>> [mailto:[email protected]] 代表 > >>> mailto:[email protected] > >>> 发送时间: 2025年5月22日 21:20 > >>> 收件人: mailto:[email protected] > >>> 抄送: mailto:[email protected] > >>> 主题: [Lsr] I-D Action: > >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> > >>> Internet-Draft draft-ietf-lsr-igp-ureach-prefix-announce-06.txt is now > available. It is a work item of the Link State Routing (LSR) WG of the IETF. > >>> > >>> Title: IGP Unreachable Prefix Announcement > >>> Authors: Peter Psenak > >>> Clarence Filsfils > >>> Daniel Voyer > >>> Shraddha Hegde > >>> Gyan Mishra > >>> Name: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > >>> Pages: 14 > >>> Dates: 2025-05-22 > >>> > >>> Abstract: > >>> > >>> In the presence of summarization, 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 document describes how to use the existing protocol > mechanisms > >>> in IS-IS and OSPF, together with the two new flags, to advertise > such > >>> prefix reachability loss. > >>> > >>> The IETF datatracker status page for this Internet-Draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-an > >>> n > >>> o > >>> unce/ > >>> > >>> There is also an HTMLized version available at: > >>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-pref > >>> i > >>> x > >>> -announce-06 > >>> > >>> A diff from the previous version is available at: > >>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-ureach- > >>> p > >>> r > >>> efix-announce-06 > >>> > >>> Internet-Drafts are also available by rsync at: > >>> rsync.ietf.org::internet-drafts > >>> > >>> > >>> _______________________________________________ > >>> Lsr mailing list -- mailto:[email protected] To unsubscribe send an email > >>> to mailto:[email protected] > >>> > >>> > >>> _______________________________________________ > >>> Lsr mailing list -- mailto:[email protected] To unsubscribe send an email > >>> to mailto:[email protected] > >>> > >>> > >>> > >>> _______________________________________________ > >>> Lsr mailing list -- mailto:[email protected] To unsubscribe send an email > >>> to mailto:[email protected] > >>> > >>> > >>> _______________________________________________ > >>> Lsr mailing list -- [email protected] > >>> To unsubscribe send an email to [email protected] > >>> > >>> > >> > > > > > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
