Aijun,
On 14/06/2022 02:35, Aijun Wang wrote:
Hi,Peter:
Then the final effects of UPA are the followings:
1) If the specified prefix exist, the receiver will delete it upon receiving
the UPA message—-But the specified prefix may still be reachable via other
summary address.
2)If the specified prefix doesn’t exist, it depends on the local behavior of
the receiver—-The specified prefix may still also be reachable via the summary
address.
Wrt the any of the above situations, the problem described at the beginning of
the draft isn’t solved, Right?
above statements are based on some assumptions which may not be
necessary correct.
The handling of the received UPA a local matter on the receiver. What
you want is to trigger BGP PIC for destinations that resolve over the
unreachable prefix. How that is done and if you need to delete anything
from RIB is the matter of the implementation and outside of the scope of
the draft.
thanks,
Peter
Aijun Wang
China Telecom
On Jun 13, 2022, at 21:14, Peter Psenak <[email protected]> wrote:
Aijun,
On 13/06/2022 15:08, Aijun Wang wrote:
Hi, Peter:
Here I want to ask you one question:
If the specified detailed prefix doesn’t exist in the receiver’s route table,
what the receiver will do when it receives the UPA information of this
specified prefix?
it's up to the receiver to process UPA the way he wants. We are not specifying
any of that. It's a local behavior on the receiver.
thanks,
Peter
Aijun Wang
China Telecom
On Jun 10, 2022, at 23:16, Peter Psenak <[email protected]> wrote:
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
