Hi Aijun, Please check inline below.
On Wed, Jul 27, 2022 at 4:13 PM Aijun Wang <[email protected]> wrote: > Hi, Ketan: > > > > We have discussed with Bruno offline for the possibilities of defining new > flag to indicate the unreachable status explicitly. > > It’s possible, but the challenge is that for OSPFv3, currently, there only > one bit unassigned ( > https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4). > It may need more works to expand the flag bits for OSPFv3. > KT> There is this individual document for OSPF which helps extend the space for prefix flags ( https://datatracker.ietf.org/doc/draft-chen-lsr-anycast-flag/). So we can do the right thing here. > And, I can’t see there is significant differences between using the > originator field and the flag bits to accomplish such aim. > > > > Would you like to state more clearly why the NULL value of originator > can’t be used to indicate the unreachability explicitly? From my POV, if > the prefix became unreachable, there is no originator advertise it, isn’t > it? > KT> There is a difference between the use of Prefix flags vs Prefix Originator. Semantics are important in protocol encoding. IMHO we should not just overload and stuff things around. > > > Anyway, this can be discussed further later after the adoption. > KT> IMHO the draft is not yet ready for adoption in its current state. Thanks, Ketan > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *发件人:* Ketan Talaulikar [mailto:[email protected]] > *发送时间:* 2022年7月27日 17:45 > *收件人:* Aijun Wang <[email protected]> > *抄送:* [email protected]; lsr < > [email protected]> > *主题:* Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement > > > > Hi Aijun, > > > > Please check inline below for a quick response. > > > > On Wed, Jul 27, 2022 at 2:55 PM Aijun Wang <[email protected]> > wrote: > > Hi, Ketan: > > > > Thanks for your comments. But I should correct some of them: > > 1) In the updated version, the indication of prefix unreachability is > still the “NULL” value of prefix originator, not the LSInfinity. > > KT> Right and I am suggesting you go one step further and remove all that > prefix originator "business" :-) > > > > 2) The LSInfinity is used only for avoiding the misrouting by > implementation not support this implementation, as you have also pointed > out. As pointed out also in the draft, when all the nodes within the area > support such capabilities, the LSInfinity value can be ignored: > > > > KT> Well, as indicated, the use of the prefix originator for this purpose > is broken in my view. The use of LSInfinity is helpful to navigate through > backward compatibility issues. With prefix originator aspects removed, we > don't need the capability anymore. What comes out at the other end of this > "pivot" for draft-wang is much similar to the other proposal ... and this > IMHO is good. > > > > > > “If not all of nodes within one area support the PUAM capabilities, > > the PUAM message should be advertised with the associated prefix cost > > set to LSInfinity. According to the description in [RFC2328 > <https://datatracker.ietf.org/doc/html/rfc2328>], > > [RFC5305 <https://datatracker.ietf.org/doc/html/rfc5305>] and [RFC5308 > <https://datatracker.ietf.org/doc/html/rfc5308>], the prefix advertised with > such metric value > > will not be considered during the normal SPF computation, then such > > additional information will avoid the misbehavior of the nodes when > > they don't recognize the PUAM message. > > > > If all of nodes within one area support the PUAM capabilites, the > > PUAM message can be safely advertised without the additional > > LSInfinity metric information.” > > > > > > We are glad to cooperate with Peter to forward the solution, but want to > say LSInfinity only can’t be used to indicate the unreachable > information, we need some explicit indication method. > > > > KT> There is some value in having an explicit indication in addition to > the use of LSInfinity in draft-ppsenak. Perhaps a prefix attribute flag as > was already suggested to the authors of draft-ppsenak ( > https://mailarchive.ietf.org/arch/msg/lsr/Q9wU3Bo1uzhPd5C7bT_WE7k_3JI/). > But certainly not the prefix originator as proposed by draft-wang. > > > > Thanks, > > Ketan > > > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *发件人:* [email protected] [mailto:[email protected]] *代表 *Ketan > Talaulikar > *发送时间:* 2022年7月27日 16:36 > *收件人:* [email protected] > *抄送:* lsr <[email protected]> > *主题:* [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement > > > > Hello Authors, > > > > I am sharing some comments on the latest version of this document since we > seem to have a packed agenda in LSR this time. > > > > 1) I notice that in the latest update of the draft, there is a big change > to start using LSInfinity for indicating prefix unreachability (similar > to draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a > degree of convergence between the two drafts. > > > > 2) However, I then question the motivation of the authors to continue with > the bad design of overloading Prefix Originator and the added capability > stuff on top. I don't wish to repeat why that design was an absolute NO-GO > for me and I am glad to see the authors acknowledge the problem with > misrouting by implementations not supporting this specification. So I don't > see the point of still retaining all that. > > > > Thanks, > > Ketan > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
