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).
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. 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. 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
