We have yet mentioned that PUA mechanism has been discussed two years
before the UPA solution.
More responses are inline. Anyway, I am glad that your comments have
some bases, although you misunderstood something.
Aijun Wang
China Telecom
On Jul 29, 2022, at 02:04, Acee Lindem (acee) <[email protected]> wrote:
Speaking as WG Member:
Hi Ketan,
Thanks for pointing out the similarities. Even after the recent
changes, there are still some difference between the drafts which
I’ll describe in the baseless comments which follow. For conciseness,
I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak).
1. Backward Compatibility – Now that PUA has appropriated the metric
mechanisms from UPA, it is also backward compatible. However, PUA
still proposes extensions the IGPs to advertise the PUA
capabilities and says the nodes may misbehave if they don’t agree
on these capabilities. I guess removing these was omitted when the
UPA metric mechanisms were appropriated.
WAJ] No. the context in the document just describes why and when the
LSInfinity is necessary. The usages of LSInfinity in two drafts are
different: one(PUA) is to avoid the misbehavior(which is conform to the
RFC rules), another(UPA) is to indicate the unreachable
information(which is not described in the RFC rules)
1.
2. Receive Router Behavior – For UPA, the unreachable prefix
notification is solely for an event signal to be used by other
routers in the IGP domain to trigger actions, e.g., BGP PIC
excluding the unreachable prefix. PUA is used for the switchover
of services as well but is also used to modify persistent state.
In section 4, the PUA advertisement will trigger the advertisement
of the prefix by an ABR that does have a route to the unreachable
prefix advertised by another ABR.
[WAJ] Is this one evidence that PUA covers UPA?
2.
3. Advertisement Persistence – PUA is advertised like any other LSA
and presumably advertised as long as the prefix is unreachable.
Conversely, UPA is an ephemeral LSA that will be withdrawn after
enough time is allowed for the event notification to propagate.
[WAJ] No. if there is no network update again, the PUA will not be
advertised “as long as the prefix is unreachable “. Actually, there is
description in the document:
“The advertisement of PUAM message should only last one configurable
period to allow the services that run on the failure prefixes are
switchovered. If one prefix is missed before the PUAM takes effect,
the ABR will not declare its absence via the PUAM.”
I think you may ignore them.
3.
In my opinion, UPA is superior to PUA since it is addresses the
original requirement with minimal overhead and changes to the IGP.
Even after many revisions, PUA still contains a lot of additional
unnecessary overhead and complexity. I think the WG should adopt UPA
and not spend any more time on this discussion.
[WAJ] From the above responses, I think you should realize that UPA just
cover very minor part of the overall PUA solution, then your conclusion
should be reverted.
Or else, we can compare these two drafts sentences by sentences.
Thanks,
Acee
*From: *Lsr <[email protected]> on behalf of Ketan Talaulikar
<[email protected]>
*Date: *Thursday, July 28, 2022 at 2:29 AM
*To: *Aijun Wang <[email protected]>
*Cc: *"Les Ginsberg (ginsberg)" <[email protected]>,
"[email protected]"
<[email protected]>, lsr
<[email protected]>
*Subject: *Re: [Lsr] Comments on
draft-wang-lsr-prefix-unreachable-annoucement
Hi Aijun,
Indeed, your draft has done a "pivot" in the latest version with the
use of LSInfinity like the UPA proposal. I hope you will do yet
another "pivot" to move away from the use of Prefix Originator.
IMHO that would also bring the PUA and UPA proposals much closer to
each other.
Thanks,
Ketan
On Thu, Jul 28, 2022 at 6:52 AM Aijun Wang <[email protected]
<mailto:[email protected]>> wrote:
Hi, Les:
I admire you and your comments as usual, but the baseless comments
will decrease your credits within the WG. Would you like to review
the update of the draft more carefully, then post your comments?
Doing this can avoid misleading some of your followers.
To facilitate your review, I copied the related contents
again:(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10#section-5
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10#section-5>)
If not all of nodes within one area support the PUAM capabilities,
the PUAM message should be advertised with the associated
prefix cost
set to LSInfinity. According to the description in [RFC2328
<https://datatracker.ietf.org/doc/html/rfc2328>],
[RFC5305 <https://datatracker.ietf.org/doc/html/rfc5305>] and
[RFC5308 <https://datatracker.ietf.org/doc/html/rfc5308>], the
prefix advertised with such metric value
will not be considered during the normal SPF computation, then such
additional information will avoid the misbehavior of the nodes when
they don't recognize the PUAM message.
If all of nodes within one area support the PUAM capabilites, the
PUAM message can be safely advertised without the additional
LSInfinity metric information.
Then, how can the “legacy nodes MUST interpret as meaning
reachable.” ? I wish to hear your explanation.
Aijun Wang
China Telecom
On Jul 28, 2022, at 06:39, Les Ginsberg (ginsberg)
<[email protected]
<mailto:[email protected]>> wrote:
(Preamble: All of what I am going to say I have said many
times before – on the list – off the list – in private
conversations – in WG meetings…
I don’t say this to start a discussion with the WG authors –
it seems clear that we don’t agree and have no path to agreement.
My purpose in saying this is to respond to the ongoing
existence of this draft and offering my opinion as to what
action the WG should take.)
The mechanism defined in this draft is broken. Not only is it
not backwards compatible – the PUA advertisements will be
misinterpreted to mean the exact opposite of what is intended
i.e., the intent is to signal that a prefix is unreachable,
but you do so by using an advertisement which legacy nodes
MUST interpret as meaning reachable. This is simply broken and
should not be done.
The authors deserve credit for bringing the attention of the
WG to the problem space – but the solution offered is not
deployable. Given the long period of time during which this
draft has been published and the many times it has been
presented/discussed in the WG I think it is now time to say
thank you to the authors for their work, but the WG is not
interested in adopting this draft.
Les
*From:* Lsr <[email protected]
<mailto:[email protected]>> *On Behalf Of *Ketan Talaulikar
*Sent:* Wednesday, July 27, 2022 1:36 AM
*To:* [email protected]
<mailto:[email protected]>
*Cc:* lsr <[email protected] <mailto:[email protected]>>
*Subject:* [Lsr] Comments on
draft-wang-lsr-prefix-unreachable-annoucement
Hello Authors,
I am sharing some comments on the latest version of this
document since we seem to have a packed agenda in LSR this time.
1) I notice that in the latest update of the draft, there is a
big change to start using LSInfinity for indicating prefix
unreachability (similar
to draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this
as a sign of a degree of convergence between the two drafts.
2) However, I then question the motivation of the authors to
continue with the bad design of overloading Prefix Originator
and the added capability stuff on top. I don't wish to repeat
why that design was an absolute NO-GO for me and I am glad to
see the authors acknowledge the problem with misrouting by
implementations not supporting this specification. So I don't
see the point of still retaining all that.
Thanks,
Ketan
_______________________________________________
Lsr mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
