Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Ketan Talaulikar <[e-mail]>]

Hi Aijun,

Please check inline below.

On Wed, Jul 27, 2022 at 4:13 PM Aijun Wang <[e-mail]>
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:[e-mail]]
> *发送时间:* 2022年7月27日 17:45
> *收件人:* Aijun Wang <[e-mail]>
> *抄送:* [e-mail]; lsr <
> [e-mail]>
> *主题:* 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 <[e-mail]>
> 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
>
>
>
> *发件人:* [e-mail] [mailto:[e-mail]] *代表 *Ketan
> Talaulikar
> *发送时间:* 2022年7月27日 16:36
> *收件人:* [e-mail]
> *抄送:* lsr <[e-mail]>
> *主题:* [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
>
>
>
>