Note that any member of the LSR can reply technical including the chairs (speaking as a WG members). There is nothing inappropriate here.
> On May 5, 2025, at 12:24 AM, Aijun Wang <[email protected]> wrote: > > Hi, Acee: > > When I want to discuss with the authors, you can’t wait to stand out, try to > represent the authors. > > If you are familiar with the topic, it’s OK. But actually you are not > familiar with this topic(or you stuck in your attitude/prejudice—-this is not > the right behavior of one WG chair) as the authors and us. Then please let’s > wait the authors’ responses. > > I restate them(considering all your responses until now) here, please read > them carefully before any response: > > 1) The “U/UP flag” used to indicate the reason of the unreachable prefixes is: > NOT necessarily(LSInfinity is enough, although I don’t recommended it > either), > NOT suitable(IGP shouldn’t flood management purposes information) and > NOT enough(There are many reasons for the unreachable prefixes). > > 2) The usage of “U/UP flag” in this document is DIFFERENT from that in > RFC8706, in which the receiver of such information will do SPF calculations > based on the related flags. But for “U/UP flag”, they are just trying to give > the reason of unreachable. > > 3) > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-04#section-5 > is the the COPYCAT from other proposal. If the WGLC document wants to > include, please state admirations to the original authors. This is the decent > IETF behavior. > (The original idea was described in Founder Draft[1], ONE YEAR earlier than > the first version of the WGLC document) > > 4) The partition possibilities in the network is also first discussed at the > Founder Draft[1], please remove it because the WGLC document solve nothing > after the “Garrulous” description. Or, just state simply as “out of the scope > of this document”. > > There are also other issues on this WGLC document but I must wait first the > responses from the authors on the above questions. > > [1] Founder Draft: > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7 > > Aijun Wang > China Telecom > >> On May 1, 2025, at 22:42, Acee Lindem <[email protected]> wrote: >> >> Speaking as WG Co-Chair: >> >> Aijun, >> >> You've raised these concerns before and they were responded to. The fact >> that you are more vehement doesn't make them any more compelling. >> Please keep in mind that many of us are busy and don't wish to engage in >> circular arguments. >> >> Speaking as WG Member: >> >> I'll respond one more time for your inevitable appeals... >> >>> On Apr 30, 2025, at 8:53 PM, Aijun Wang <[email protected]> wrote: >>> >>> Hi, Peter: >>> >>> I must remind you that the following things: >>> >>> 1) The newly defined “U/UP flags” MUST be removed, as you declared they are >>> trying to “give the reason of unreachable”, which is not suitable for IGP >>> protocol, and also not enough to describe various reasons for the >>> unreachability. >> >> As I stated previously, there is a precedence with signaling whether or not >> the outage is planned in RFC8706. This may determine the reaction to the >> unreachability by other routers in the domain. It need not be specified >> since this is a generalized mechanism. >> >>> >>> 2) Remove the “partition” related description. Current contents doesn’t >>> solve the problem, no useful information provided to the reader. >> >> This section is useful as it states that the mechanisms do NOT attempt to >> solve the partition problem. >> >>> >>> 3) Remove the control knob considerations on the ABR. Because they are >>> first provided by other proposal, and current contents covers only part of >>> them. >> >> This needs to be configured as well as the ranges of prefixes subject to >> reachability signaling. >> >>> >>> After the above adjustments, there will be nothing needs to be >>> standardized, the document should be changed to “Information Track”. >> >> You either didn't read or understand the draft. The abstract alone should >> make it obvious that this isn't an informational specification. >> >> >> Acee >> >> >>> >>> >>> Aijun Wang >>> China Telecom >>> >>>> On Apr 30, 2025, at 23:09, Peter Psenak >>>> <[email protected]> wrote: >>>> >>>> Robert, >>>> >>>> On 30/04/2025 17:02, Robert Raszuk wrote: >>>>> >>>>> Indeed we agreed on the list but I never noticed text being added to >>>>> address it into section 4. In -04 it is not there. >>>> we have not added it yet, but we agreed I would. I will do when the next >>>> version is pushed, but wanted to wait for some more comments to include. >>>> thanks, >>>> Peter >>>>> >>>>> Thx, >>>>> R. >>>>> >>>>> On Wed, Apr 30, 2025 at 4:59 PM Acee Lindem <[email protected]> wrote: >>>>> To cover the make-before-break situation you and Peter discussed in this >>>>> thread. >>>>> >>>>>>> >>>>>>> If there are no alternate paths I would rather keep one installed >>>>>>> active - for example to address the case where one ABR can still reach >>>>>>> egress PE and the other one generated UPA. >>>>>>> >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>>> On Apr 30, 2025, at 10:57 AM, Robert Raszuk <[email protected]> wrote: >>>>>> >>>>>> Which text ? >>>>>> >>>>>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-igp-ureach-prefix-announce-03&url2=draft-ietf-lsr-igp-ureach-prefix-announce-04&difftype=--html >>>>>> >>>>>> Thx, >>>>>> R. >>>>>> >>>>>> On Wed, Apr 30, 2025 at 4:52 PM Acee Lindem <[email protected]> wrote: >>>>>> Hi Robert, >>>>>> >>>>>> I guess you are now fine with the draft with this text. >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>>> On Apr 23, 2025, at 10:51 AM, Robert Raszuk <[email protected]> wrote: >>>>>>> >>>>>>>> ok, I'm fine adding some text for your case. >>>>>>> >>>>>>> Thx Peter ! >>>>>>> >>>>>>> It is not "my use case" but ability to trigger UPA for >>>>>>> make-before-break which I think always is rather a good thing. >>>>>>> >>>>>>> Cheers, >>>>>>> R. >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 23, 2025 at 4:40 PM Peter Psenak <[email protected]> wrote: >>>>>>> Hi Robert, >>>>>>> >>>>>>> On 23/04/2025 16:35, Robert Raszuk wrote: >>>>>>>> Hi Peter, >>>>>>>>> If the egress PE is the only BGP NH, then reacting to max-metric or >>>>>>>>> OL-bit set would make some BGP destinations unreachable. >>>>>>>> >>>>>>>> Well this entirely depends on how one reacts on UPA if UPA is >>>>>>>> signalling the only one left BGP path/NH as down irrespective of the >>>>>>>> trigger. Does it stop the service to the destination or not ... >>>>>>>> >>>>>>>> If there are alternate paths the best path can install new next hop. >>>>>>>> >>>>>>>> If there are no alternate paths I would rather keep one installed >>>>>>>> active - for example to address the case where one ABR can still reach >>>>>>>> egress PE and the other one generated UPA. >>>>>>>> >>>>>>>>> So why not trigger UPA in such cases to hint him to switch to >>>>>>>>> alternate next hops if available ? >>>>>>>> I'm not saying it can not be done. The implementation can chose to >>>>>>>> advertise the UPA for the summary component prefix if the such prefix >>>>>>>> metric in the source area/domain crosses certain value or if the >>>>>>>> prefix originator is overloaded. >>>>>>>> But this would make it not compliant with current text in section 4 >>>>>>>> which was the main point of my question. So why not leave the door a >>>>>>>> bit open for it in the spec ? >>>>>>> ok, I'm fine adding some text for your case. >>>>>>> thanks, >>>>>>> Peter >>>>>>> >>>>>>>> >>>>>>>> Thx, >>>>>>>> R. >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >> >> _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
