Aijun,
On 08/06/2022 13:22, Aijun Wang wrote:
Hi, Peter:
“MAX-Value” metric just indicates the associated prefix will be removed if it
is installed previously, as the same function of premature aging.
If the prefix doesn’t exist previously on the receiving router, it will do
nothing when it receives such “MAX-Value” metric advertisements.
Thus, it can avoid the misbehavior when receiving the unrecognized TLV that
indicates explicitly the unreachable information, but itself only can’t be used
to trigger the switchover of overlay service on the mentioned prefix(such LSA
will be passed immediately, as described in RFC2328).
sorry, I don't understand the above. Advertising a prefix with
LSInfinity will cause the prefix to become unreachable.
In summary, UPA just told the receiver the detailed prefix is missed(but may
still be reached via the summary address),but not the prefix is unreachable.
and why is that a problem?
Combine current two information together can declare clearly the detailed
prefix is unreachable and unsupported router will not have any misbehavior when
they don’t understand the PUA information.
things as described in UPA draft are sufficient to make prefix
unreachable. There will be no misbehavior, as we are using existing
mechanism to do so.
thanks,
Peter
And, when all the routers be upgraded(which are all necessary for both
proposals) to support the PUA information , the UPA information can be omitted.
Aijun Wang
China Telecom
On Jun 7, 2022, at 23:59, Peter Psenak <[email protected]> wrote:
Aijun,
On 07/06/2022 17:31, Aijun Wang wrote:
Hi, Peter:
The differences between our proposals are just how to indicate the PUA/UPA
information along with the advertised prefixes. All other mechanisms/procedures
are the same, right?
Then one simple way for the convergence is just the encoding: Let the
unreachable prefixes associated with “prefix originator”(with the value set to
NULL”) and also set its metrics to MAX-Value.
there is no need to introduce any new encoding. That the whole point of the UPA
draft. We use existing mechanism.
thanks,
Peter
Other parts can follow the current PUA drafts, which we have discussed
intensively in the list and I think you have no any objections.
Anyway, to make the UPA mechanism take effect, you will also require the router
be upgraded. And the “Max-Value” solution doesn’t necessarily indicate the
prefix is lost. We should announce such information explicitly.
We can also discuss other convergence solutions.
Aijun Wang
China Telecom
On Jun 7, 2022, at 20:34, Peter Psenak <[email protected]> wrote:
Hi Aijun,
thanks for your interest in the UPA draft.
I'm not sure what exactly is there in your draft that you would like to merge.
The mechanism that we use in the UPA draft is an existing mechanism and it
avoids the the problems that have been discussed in context of your draft in
the past completely.
thanks,
Peter
On 07/06/2022 08:59, Aijun Wang wrote:
Hi, Authors of UPA(Unreachable Prefixes Announcement) draft:
After reading your newly proposed draft
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/
<https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>, we
found that the overall aim and procedures in your draft are getting closer again to the
already intensely discussed PUA/PUAM
solutions(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09>).
Regardless to the difference of the two proposals, here we propose to converge
the solutions, based on the PUA/PUAM draft, as we all know the WG has discussed
PUA/PUAM draft about two years, there is no reason to discuss again the similar
procedures and the later work should respect the former’s efforts.
If you agree, we can discuss the details of convergence offline. If you don’t
agree, we can discuss these solutions openly within the WG list.
Aijun Wang
China Telecom
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
