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?
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
