Hi Med,
please see inline (##PP4):
On 24/09/2025 07:20, [email protected] wrote:
Hi Peter,
I think that we are almost converging.
Please see inline.
Cheers,
Med
*De :*Peter Psenak <[email protected]>
*Envoyé :* mardi 23 septembre 2025 15:23
*À :* BOUCADAIR Mohamed INNOV/NET <[email protected]>;
Peter Psenak <[email protected]>; The IESG
<[email protected]>
*Cc :* [email protected];
[email protected]; [email protected]; [email protected]
*Objet :* Re: [Lsr] Re: Mohamed Boucadair's Discuss on
draft-ietf-lsr-igp-ureach-prefix-announce-09: (with DISCUSS and COMMENT)
Hi Med,
please see inline (##PP3):
On 23/09/2025 14:33, [email protected] wrote:
Re-,
Please see inline.
Cheers,
Med
*De :*Peter Psenak <[email protected]>
<mailto:[email protected]>
*Envoyé :* mardi 23 septembre 2025 13:59
*À :* BOUCADAIR Mohamed INNOV/NET <[email protected]>
<mailto:[email protected]>; The IESG <[email protected]>
<mailto:[email protected]>
*Cc :* [email protected];
[email protected]; [email protected]; [email protected]
*Objet :* Re: Mohamed Boucadair's Discuss on
draft-ietf-lsr-igp-ureach-prefix-announce-09: (with DISCUSS and
COMMENT)
Hi Med,
please see inline (##PP2):
On 23/09/2025 11:07, [email protected] wrote:
Hi Peter,
Thanks for the follow-up.
Please see inline.
Cheers,
Med
*De :*Peter Psenak <[email protected]> <mailto:[email protected]>
*Envoyé :* lundi 22 septembre 2025 17:11
*À :* BOUCADAIR Mohamed INNOV/NET
<[email protected]>
<mailto:[email protected]>; The IESG
<[email protected]> <mailto:[email protected]>
*Cc :* [email protected];
[email protected]; [email protected]; [email protected]
*Objet :* Re: Mohamed Boucadair's Discuss on
draft-ietf-lsr-igp-ureach-prefix-announce-09: (with DISCUSS
and COMMENT)
Hi Med,
thanks for the comments, please see inline (##PP):
On 21/09/2025 12:21, Mohamed Boucadair via Datatracker wrote:
Mohamed Boucadair has entered the following ballot position for
draft-ietf-lsr-igp-ureach-prefix-announce-09: Discuss
When responding, please keep the subject line intact and reply to
all
email addresses included in the To and CC lines. (Feel free to cut
this
introductory paragraph, however.)
Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT
positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi Peter, Clarence, Daniel, Shraddha, and Gyan,
Thank you for the effort put into this specification.
I like the approach adopted here as it leverages exiting features
(which is
good for backward compatibility) and thus eases incremental
deployment.
# Meta comment
The flow of the document can be made better by introducing the
explicit
signaling part early in the document as that is what actually demux
the use
defined in the draft vs. any other future uses of the specific
metric. The
current flow reveals that the signaling part was added as an after
though, not
as part of the design.
##PP2
the document has been re-ordered several times based on the
comments during various stages of the review process.
I'm a bit reluctant to change it again, as different people
have a different priorities, and it's not possible to make
everyone happy.
In the end, what we are specifying is rather simple, so the
ordering does not play that significant role IMHO.
*/[Med] I understand, but I still think this is important to
fix. FWIW, as part of this review, I have checked
implementations available out there and I was puzzled by one
UPA implementation that says “UPA flags are not supported”./*
*/The current structure reveals this issue: the
support/advertisement/propagation are specified separately
than signaling (which is the core of the extension and which
justifies at the first place the PS status). The signaling
part should be integrated in the “Supporting …” part./*
##PP2
done
*/[Med] Thanks./*
*/ 3. Supporting UPA in IS-IS . . . . . . . . . . . . . . .
. . . . 5/*
*/ 3.1. Advertisement of UPA in IS-IS . . . . . . . . . .
. . . . 5/*
*/ 3.2. Propagation of UPA in IS-IS . . . . . . . . . . .
. . . . 6/*
*/ 4. Supporting UPA in OSPF . . . . . . . . . . . . . . .
. . . . 6/*
*/ 4.1. Advertisement of UPA in OSPF . . . . . . . . . .
. . . . 7/*
*/ 4.2. Propagation of UPA in OSPF . . . . . . . . . . .
. . . . 8/*
*/ 5. Signaling UPA . . . . . . . . . . . . . . . . . . . .
. . . . 8/*
*/ 5.1. Signaling UPA in IS-IS . . . . . . . . . . . . .
. . . . 8/*
*/ 5.2. Signaling UPA in OSPF . . . . . . . . . . . . . .
. . . . 9/*
*/5.2.1. Signaling UPA in OSPFv2 . . . . . . . . . . . . . .
. 9/*
*/5.2.2. Signaling UPA in OSPFv3 . . . . . . . . . . . . . .
. 9 /*
Please find below some DICUSS points:
# Planned Maintenance
I expect that adequate reconfiguration will be put in place to
isolate a node
for PM purposes. The document does not explain how the signal
defined here is
needed or solves an issue. I appreciate that the introduction
include a short
mention of the use of overload bit, though.
I’m also asking the question because there is no ** normative **
discussion (at
least I missed it) about how that can be triggered at the
originating ABR.
Also, unlike a random failure, a planned failure is associated with
an expected
start and end times. Signaling the event without those
characteristic questions
the value of tagging a loss as an NP.
##PP
I'm not sure what is being asked. This document does not
specify the PM procedure of any kind.
This document specifies the UPA signaling, including the bit
that signals that the UPA was originated on the ABR/ASBR as a
result of the PM in its source area/domain.
UPA helps in propagating the information about the
connectivity loss caused by the beginning of the PM outside of
the area/domain. That's all.
*/[Med] The main point is what issue are we solving by
indicating a planned failure, compared to sole use of U-flag?
What we lose if the UP-flag is removed?/*
##PP2
application that uses these flags may treat them differently.
That's all. We are not specifying the application treatment of any
of these flags, but we offer the distinction.
*/[Med] We are making hidden assumptions here as we don’t know why
these applications need such signal, how they intend to make use
of the UP-signal, whether a simple additional flag is sufficient
from them compared to what is already exposed with U-flag, etc./*
##PP3
we are not making any assumptions at all. We offer distinction if it
becomes useful for any app.
*/[Med] This looks more like a bet here, Peter: assume that a single
flag that says this a PM loss is sufficient for what these
applications needs to do compared to reacting to the U-flag. /*
##PP4
yes, that was exactly what was requested by several folks in the WG. You
may see it as a bet, but I see no harm.
*//*
*/Also, we don’t say how the UP-flag is triggered./*
##PP3:
Section 2 says:
UPA MAY be generated by an ABR or ASBR for a prefix that is
summarized by the summary prefix originated by an ABR or ASBR in the
following cases:
1. Reachability of a prefix that was reachable earlier was lost.
2. For any of the planned maintenance cases:
- if the node originating the prefix is signalling the
overload state in IS-IS, or or H-bit in OSPFv2 [RFC8870], or
R-bit in OSPFv3 [RFC5340] .
- the metric to reach the prefix from an ABR or ASBR crosses
the configured threshold.
(2) is specific for planned maintenance. That's when the UP flag is set.
# Configuration Efficiency
Section 2
Implementations MAY limit the UPA generation to specific prefixes,
e.g. host prefixes, SRv6 locators, or similar. Such filtering is
optional and MAY be controlled via configuration.
I’m afraid that for the limit to be useful, it should be tweaked based
on local
operator policy and not on some magic that is internal to the
implementation. I
suggest the second MAY to be changed to SHOULD when such limit is
supported.
##PP
done
*/[Med] Thanks./*
Idem for the following:
Implementation MAY provide a configuration option to specify
the UPA
lifetime at the originating ABR or ASBR.
I suggest we update it to:
UPA implementations SHOULD provide a configuration option to
specify the UPA
^^^^^^^^^^^^^^^^^^^
lifetime at the originating ABR or ASBR.
##PP
done
*/[Med] Thanks./*
The reasoning for this change is that a failure may last long and
that an
operator would like to maintain that loss state longer (than
allowed by a
default limit) to accommodate how the specific application
consuming the loss
signal.
Please note that you say that the validity depends on the use case:
CURRENT (S.2):
The
time the UPA is kept in the network SHOULD also reflect the
intended
use-case for which the UPA was advertised.
# Withdrawal
Section 2 says:
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.
The
time the UPA is kept in the network SHOULD also reflect the
intended
use-case for which the UPA was advertised.
…
ABR or ASBR MUST withdraw the previously advertised UPA when the
reason for which the UPA was generated ceases - e.g. prefix
reachability was restored or its metric has changed such that
it is
below the configured threshold value.
The second MUST is not useful if that reason disappears before the
timeout that
triggers the SHOULD.
I think a simple text reorder would fix this. For example,
NEW:
ABR or ASBR MUST withdraw the previously advertised UPA when the
reason for which the UPA was generated ceases - e.g. prefix
reachability was restored or its metric has changed such that
it is
below the configured threshold value.
Even if the reasons persist, UPA advertisements SHOULD
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.
The
time the UPA is kept in the network SHOULD also reflect the
intended
use-case for which the UPA was advertised.
##PP
done
*/[Med] ACK/*
# Scalability control
Section 2 says:
It is also RECOMMENDED that implementations limit the number of
UPA
advertisements which can be originated at a given time.
The benefits gained by summarization may be nullified if a large
number of UPAs
are injected. This recommendation is really great, but there is a
need to
expose a configuration parameter here. Pease
NEW:
UPA implementations SHOULD provide a configuration option to
limit
the number of such UPAs.
##PP
done.
*/[Med] ACK/*
# Backward compatibility Check
CURRENT (3.2/4.2):
Such requirement of
reachability MUST NOT be applied for UPAs, as they are
propagating
unreachability.
Does this mean that an ABR that don’t support UPA might discard it?
##PP
it will not discard it, bit it will not propagate it between
areas.
*/[Med] OK. This confirms what I had in mind: for the feature
to be useful, all ABRs should upgraded. Can you please
indicate this in the operational considerations section?
Thanks. /*
##PP2
Section 4.2 says (updated based on Ketan's comment):
"OSPF ABRs, which would be responsible for propagating
UPA advertisements into other areas need to recognize such
advertisements.
Failure to do so would prevent UPA to reach the routers in
the remote areas."
*/[Med] This is a great addition. I still prefer we group these
considerations under an OPS consideration section as this is more
about how to operate the protocol extension./*
##PP3
I believe what we have is sufficient. As far as I know operational
section is not mandatory, at least not yet. I wish it never becomes.
*/
/*
I added similar text to section 3.2 for consistency and completeness:
"ISIS L1/L2 routers, which would be responsible for propagating UPA
advertisements between levels need to recognize such
advertisements.
Failure to do so would prevent UPA to reach the routers in
the remote areas.
That should be sufficient I believe.
*/[Med] Thank you./*
# Avoid redefining exiting behaviors
CURRENT (Section 4):
In addition, NU-bit is defined for OSPFv3 [RFC5340]. Prefixes
having
the NU-bit set in their PrefixOptions field SHOULD NOT be included
in
the routing calculation.
The SHOULD NOT part is already defined in 5340. What is this redefined
again?
##PP
I changed to:
"Prefixes having the NU-bit set in their PrefixOptions field
are not included in the routing
calculation."
Is that ok? Without any text it's not clear what's the
relevance of the NU bit here.
*/[Med] It is better. You can add a pointer to Section 4.8.1
of [RFC5340]./*
##PP2:
pointer to///RFC5340 is provided in the previous sentence:/
"In addition, NU-bit is defined for OSPFv3 [RFC5340]. Prefixes
having the NU-bit set in their PrefixOptions field are not
included in the routing calculation."
*/[Med] Having an explicit pointer where to look in that RFC will
be convenient for readers./*
# Check on “UP-Flag” is useless
5.1.1
The prefix that is advertised with U-Flag or UP-Flag MUST have the
metric set to a value larger than 0xFE000000. If the prefix metric
is less than or equal 0xFE000000, both of these flags MUST be
ignored.
5.2.2
The prefix that is advertised with U-Flag or UP-Flag MUST have the
NU-bit set in the PrefixOptions of the parent TLV.
The “or UP-Flag” part of both MUSTs is useless as U-Flag will be set in such
case as well. The case where only UP-Flag is set is invalid and will be
ignored.
Unless I missed a subtle thing here, please update these two.
##PP
good catch, fixed it.
We changed the UP flag from standalone one to be suplementary, but
we forgot to update the text.
*/[Med] Thanks./*
# Service stability
The document declares the applications that consume the signal out of
scope.
Which is fine. However, there might be some negative implications due
to how
the loss signal (or it withdrawal/absence) is interpreted. For example,
add a
warning to insist that withdrawal does not mean revert to a nominal
state.
Having few sentences for these service to take appropriate measure
before
reverting.
##PP
The usage of the UPA depends on the application. As we may not
know what applications are going to use it, I would be reluctant
to specify the application behavior.
*/[Med] This is not about specifying the behavior but indicating
precaution that these applications need to take care of./*
For some applications, the presence of the UPA may be
required, before the application itself detects the loss later.
Section 2 says:
"ABR or ASBR MUST withdraw the previously advertised UPA when
the reason for which the UPA was generated ceases"
In such case the withdrawal could mean that the prefix for
which the UPA was generated became reachable again.
*/[Med] but we also withdraw UPA after a timer even if the
reachability is not OK. Depending solely on the absence of UPA
to infer that reachability is back, is not deterministic./*
UPA is a one time signal for applications that there might be
some loss of connectivity. Application itself must use its own
mechanism to verify/detect the loss eventually. In the
meantime it may decide to do some proactive measures, but UPA
does not dictates the application behavior.
*/[Med] We just need to say so in the OPS consideration section./*
##PP2
I added the following text at the end of the "Processing of the
UPA" section:
"Applications using the UPA cannot use the absence of the UPA
to infer that the
reachability of the prefix is back. They must rely on their
own mechanisms to verify
the reachability of the remote end-points."
*/[Med] Looks good to me. Thanks./*
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
# Topology-dependent matters
Abstract:
This enables fast
convergence by steering traffic away from the node which owns the
prefix and is no longer reachable.
“steering..” part of the text is only possible when there alternate routes
for
that prefix. Otherwise, the traffic will be dropped anyway.
Pleas reword. For example, saying “when applicable” or similar would be just
fine.
##PP
done
*/[Med] Thanks./*
# Why now?
Summarization was there since decades. A mention about what exacerbates
the
need for this new feature now (and was not considered as a major issue
in past)
would be helpful.
##PP
is it really required? I was not planning to mention it in the
text . But if you insist...
*/[Med] As a reader, it is helpful to understand this. /*
It's the SRv6 that brings summarization back in life for underlay
(IGPs). With MPLS summarization was not possible.
*/[Med] I see that Robert/Joel have some comments on this. I trust
that some motivation that captures the discussion will be recorded
in the draft. Thank you./*
/##PP*2
*/I intentionally did not want to spark that discussion and that
was the reason there was no such text there. I would rather leave
it that way.*/
/**/[Med] Up to you to decide here./*
# "Egress" depends on the traffic directionality
Section 1:
Similarly, when an egress router needs to be taken out of
service for
maintenance, the traffic is drained from the node before taking
it
down.
A router may behave as ingress/egress as a function of traffic
direction. I
would delete “egress” here.
##PP
done
*/[Med] ACK/*
# (ni) There might be many ABRs per area, not single one
Please make this change in Section 1 (and similar):
OLD:
When prefixes from such node are summarized by the
Area Border Router (ABR) or Autonomous System Boundary Router
(ASBR),
NEW:
When prefixes from such node are summarized by an
Area Border Router (ABR) or Autonomous System Boundary Router
(ASBR),
##PP
done
*/[Med] ACK/*
# (Operational Considerations) Many signals, distinct expected uses
Section 1 has the following:
This document does not define how to advertise prefix that is
not
reachable for routing. That has been defined for IS-IS in
[RFC5305]
and [RFC5308], for OSPF in [RFC2328], and for OSPFv3 in
[RFC5340].
I wonder whether we can list the signals available out there
(explicit prefer
advertisement, prefix with a specific metric, etc.) and remind the
intend use
scope for each of them. This can be record in the Operational
Considerations.
##PP
that is what the beginning of section 3 and 4 are doing for
ISIS and OSPFv2/v3 respectively.
*/[Med] Yeah, but that is lost in the mass. Moving/extending
that part is as a helpful operational considerations to
clarify the scope for each of these tools and this help those
who will deploy./*
##PP2
I don't feel it's lost.
*/[Med] That’s fine as an author. But, I’m approaching this from
distinct perspective: as an operator who want to digest how this
is different from the tools already./*
##PP3
as an operator, you are only interested in one protocol. As such you
are only going to read the section that is specific to that protocol.
That is my experience with operators :)
*//*
The document is organized in a protocol specific sections because
historically different mechanisms were defined for each protocol.
Section 3.1 and 4.1. discuss in detail the existing protocol
mechanisms. I don't see a need for the operational section that
repeats the same thing.
*/[Med] It does not to repeat things, but better structure some of
the content you already have./*
I’m raising this point, especially that the text right after says the
following
without appropriate scoping:
CURRENT:
This document defines two new flags in IS-IS, OSPF, and OSPFv3.
These flags, together with the existing protocol mechanisms, provide
the support for advertising prefix unreachability , together with
the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
reason for which the unreachability is advertised
##PP
what do you mean by "without appropriate scoping"?
*/[Med] Saying that « /*the support for advertising prefix
unreachability”*/ may be interpreted that we are advertising
explicit prefix reachability, while we are not. /*
##PP2
I still do not follow. Protocols have been defined to advertise
explicit prefix reachability day one. Nothing changes there. We
are defining a way to advertise explicit prefix unreachability.
*/[Med] We are defining a reachability loss not signaling whether
a prefix is UP/DOWN. These are distinct things in my mind./*
##PP3
we are defining unreachability signaling which is needed for something
that has not been signaled as reachable previously - for the
summarization use case, the reachability of the summary component was
never signaled.
For what has been signalled as reachable previously, the withdrawal of
such advertisement makes it unreachable.
Anyway, back to your comment, what exactly do you suggest we do?
*/[Med] At least, s//**/advertising prefix unreachability/advertising
prefix unreachability loss/*
##PP4
I hope you meant */"prefix reachability loss" /*not*/"/**/prefix
unreachability loss"/*
I'm sorry, but that would be incorrect. Advertising prefix reachability
loss is something that exists in LS protocols today. If the prefix x/y
was advertised from the originagtor Z, Z will signal the
prefix reachability loss by withdrawal of the x/y adverisement.
What we specify here is different. We are specifying a mechanism how Z
can make unreachable x/y that he never advertised. And that is what we
call unreachability signaling.
The fact that x/y reachability is covered by the advertisement of some
other less specific prefix is not significant from the signaling
perspective that we are specifying here.
# Unreachable metric?!
Section 1 has the following:
This document defines a method to signal a specific reason for which
the prefix with unreachable metric was advertised.
Unless, I’m mistaken there is no such “unreachable metric” as a thing
in IS-IS.
##PP
Please see the section 3 of this document that
mentions [RFC5305 <https://www.rfc-editor.org/info/rfc5305>].
That RFC defines a metric that makes the prefix "not
reachable" for the purpose of the routing.
*/[Med] I’m not sure to follow here. I interpret that metric
as exclude it from SPF calculation, not more than that. /*
##PP2
if you exclude it from the SPF calculation, you are making it
unreachable, don't you?
*/[Med] No, because reachability of that prefix depends whether
that prefix is included, e.g., another aggregate advertised with a
“normal” metric./*
##PP3
I'm afraid we are diverting from your original comment. The term
“unreachable metric”:
RFC2328 calls the LSInfinity metric as unreachable:
LSInfinity
The metric value indicating that the destination described by an
LSA is unreachable.
RFC5305 <https://www.rfc-editor.org/info/rfc5305> does the same, just
calls it differently.
If you have a better term how to refer to "unreachable metric" please
suggest. We have been using this term for many years in LSR WG and
everybody understand its meaning.
*/[Med] s//*the prefix with unreachable metric/*/the prefix with a
specific metric (Section XX) (then point to the section where the
extact metric are listed). /*
##PP4
this document does not define unrechable metric, that has been defined
by existing RFCs for both OSPF and ISIS. OSPF calls such metric
"unreachable metric", ISIS calls it "metric that MUST NOT be considered
during the normal SPF computation".
Calling this a "specific metric" is simply incorrect.
I can use "metric that excludes prefix from the route calculation" or
something of that nature if you really insist, even though I strongly
believe that "unreachable" is far better.
thanks,
Peter
*/
/*
*//*
*//*
The term "unreachable metric" is a common term used in LS protocol
community for such metric for last three decades.
We are reusing such metric value for UPA.
# (Operational Considerations) Activation default
Section 2 has the following:
UPA MAY be generated by the ABR or ASBR for a prefix that is
summarized by the summary address originated by the ABR or ASBR
in
the following cases:
Can we say something about whether the use of UPA be enabled or
disabled by
default?
##PP
I added the following text as a response to one of the Ketan's
comments:
"Generation of the UPA at the ABR or ASBR is optional and
SHOULD be controlled by
a configuration knob."
I would leave the default behavior for the implementations to
decide. I see no reason why an RFC should mandate any specific
default behavior.
*/[Med] For this specific case, UPA will be useful of enabled
in all ABRs. I would this expect this to be disabled by default./*
##PP2
why?
*/[Med] Because coordination is needed at level of a network to
make use of a feature. Use of distinct defaults may lead to extra
work and sub optimal behavior (e.g., some operators may introduce
some nodes/functions with default picked by a vendor)./*
##PP3
not that I necessarily agree, but I added "It SHOULD be disabled by
default." in section 2:
Generation as well as propagation of the UPA at an ABR or ASBR is
optional and SHOULD be controlled by a configuration knob. It SHOULD be
disabled by default
*/[Med] /* Looks good to me. Thanks.
thanks,
Peter
I'm going to repeat myself, but the role of the IETF is to
maintain interoperability, not to tell implementations what
defaults to use. It's the implementation choice and it's the
reposnsibility of the field to push vendors to what the defaults
should be if needed. There is no role for IETF to play there IMHO.
# Threshold
Section 2 says:
- the metric to reach the prefix from the ABR or ASBR crosses
the configured threshold.
Can we explicit the threshold we are referring to here + add reference
where to
look at?
##PP
there is no explicit threshold here, it's any value of the metric
that the operator defines. For example, if for the planned
maintenance the cost of router's links is set to some high value
X, the operator may set the threshold on the ABR to X + something.
*/[Med] Thanks. May be s/the configured threshold/a configured
threshold/*
##PP2
done
*/[Med] ACK./*
# Explicit references in Section 3
OLD:
[RFC5305] defines the encoding for advertising IPv4 prefixes
using 4
octets of metric information. Section 4 specifies:
..
Similarly, [RFC5308] defines the encoding for advertising IPv6
prefixes using 4 octets of metric information. Section 2 states:
NEW:
[RFC5305] defines the encoding for advertising IPv4 prefixes
using 4
octets of metric information. Section 4 of [RFC5305]
specifies:
..
Similarly, [RFC5308] defines the encoding for advertising IPv6
prefixes using 4 octets of metric information. Section 2 of
[RFC5308]
states:
##PP
Ketan made a similar comment and the text has been updated
already.
*/[Med] ACK./*
# “Advertisement of UPA in IS-IS”
CURENT (S3.1)
Recognition of the advertisement as UPA is only required on
routers
which have a valid use case for this information.
I would delete this sentence as this section is about the
originator.
##PP
done
*/[Med] Thanks./*
# Section 6
Consider moving that section right after current Section 7 as a
subsection of
an Operational Consideration section.
##PP
done
*/[Med] ACK/*
## Multiple ABRs
That section may also discuss whether there are specific
consideration to take
into account, e.g., presence of multiple ABRs with announces UPAs
for a set of
prefixes in an area and measures to prevent routing stability. If
you don’t see
any risk out there, saying that as well would be useful.
##PP
there is no special risk with multiple ABRs - if the egress PE
goes down they will all equally see it and generate the UPA.
The problem is when one ABR sees the egress PE reachable and
other as unreachable. This can only happen when the area
partitions. That problem is described in section 6.
*//*
*/[Med] I like explanation with PEs, better. The case I had in
mind is, e.g., a multi-ABR case with anycast prefixes injected
via distinct PEs but a failure only occurs at one PE leg.
Probably there is no issue at all./*
## Consider adding any implications (or absence of) explicit
withdrawal of an
UPA.
##PP
I'm not sure what do you mean by explicit withdrawal. UPA must
be withdraw by the originator in all cases.
*/[Med] I understand that by withdrawal we mean “to not
advertise”./*
##PP2
yes
thanks,
Peter
Either based on the timeout, or because the reason for which
it was generated does not exist anymore, whatever comes first.
thanks,
Peter
Cheers,
Med
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
