Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Peter Psenak <[e-mail]>]

Robert,

On 31/08/2023 01:18, Robert Raszuk wrote:
> *Hi Les,*
> 
>> But existing implementations will NOT ignore a prefix reachability advertisement just because 
>> it has a source Router ID set to 0 as draft-wang-lsr-prefix-unreachable-annoucement defines.
> 
> True, but let's do not forget the bigger picture here. The dst is 
> already covered by summary so for the
> app it really does not matter ... It is reachable anyway.
> 
> Bottom line is that both solutions need to have upgraded code to use the 
> new trigger.
> 
> 
> *Dear LSR chairs,*
> 
> I am not sure what harm would it make to start WG adoption call on both 
> drafts and see the results.
> 
> So far I am not seeing strong and uniform adoption support for either 
> one :)

I hope you are not serious. Having two different ways of signalling the 
same thing in a protocol is hardy something you would want.

thanks,
Peter

> 
> Not sure why some authors feel like their work was rejected.
> 
> Cheers,
> R.
> 
> 
> On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg) 
> <ginsberg=[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Zhibo -____
> 
>     __ __
> 
>     Please see inline.____
> 
>     __ __
> 
>      > -----Original Message-----
> 
>      > From: Huzhibo <huzhibo=[e-mail]
>     <mailto:[e-mail]>>
> 
>      > Sent: Wednesday, August 30, 2023 6:33 PM
> 
>      > To: Les Ginsberg (ginsberg) <[e-mail]
>     <mailto:[e-mail]>>; Peter Psenak (ppsenak)
> 
>      > <[e-mail] <mailto:[e-mail]>>; linchangwang
>     <[e-mail] <mailto:[e-mail]>>;
> 
>      > Acee Lindem <[e-mail] <mailto:[e-mail]>>;
>     lsr <[e-mail] <mailto:[e-mail]>>
> 
>      > Cc: [e-mail]
>     <mailto:[e-mail]>
> 
>      > Subject: RE: [Lsr] Working Group Adoption of "IGP Unreachable Prefix
> 
>      > Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04
> 
>      >
> 
>      > Hi Les:
> 
>      >
> 
>      >     I think you may have connected something. Existing routers,
>     on receiving a
> 
>      > prefix reachability advertisement with a
> 
>      > U-Flag described in
>     https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-
>     <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>
> 
>     > ureach-prefix-announce/
>     <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/> also will interpret that prefix as being reachable.
> 
>     __ __
> 
>     [LES:] This statement is incorrect.____
> 
>     RFC 5305 states:____
> 
>     __ __
> 
>     <snip>____
> 
>     If a prefix is advertised with a metric larger then MAX_PATH_METRIC____
> 
>         (0xFE000000, see paragraph 3.0), this prefix MUST NOT be
>     considered____
> 
>         during the normal SPF computation.  This allows advertisement of
>     a____
> 
>         prefix for purposes other than building the normal IP routing
>     table.____
> 
>     <end snip>____
> 
>     __ __
> 
>     (Equivalent statement in RFC 5308 for IPv6)____
> 
>     __ __
> 
>     Existing implementations will ignore the advertisement purely on the
>     basis of the metric value - this does not depend upon understanding
>     the U bit.____
> 
>     __ __
> 
>     But existing implementations will NOT ignore a prefix reachability
>     advertisement just because it has a source Router ID set to 0 as
>     draft-wang-lsr-prefix-unreachable-annoucement defines.____
> 
>     __ __
> 
>     It is worth noting that AFTER the publication of
>     draft-ppsenak-lsr-igp-pfx-reach-loss-00 in March 2022 (subsequently
>     renamed as draft-ppsenak-lsr-igp-ureach-prefix-announce), the
>     authors of draft-wang-lsr-prefix-unreachable-annoucement apparently
>     realized they had  an interoperability problem with existing routers
>     (something many of us had been highlighting for years) and in V10
>     (published in Jul 2022) an option was added to advertise using
>     maximum metric (the solution already proposed by draft-ppsenak). But
>     because the authors apparently didn’t want to abandon the use of
>     "Router ID = 0", the new version of the draft proposed a dependency
>     on how the unreachable prefix should be advertised. If all routers
>     in the network indicated support for the new extension (indicated by
>     yet another protocol extension - a new Router Capability sub-TLV for
>     IS-IS) then the use of Router ID = 0 could be used, but if any
>     router in the network did not advertise the new capability, then the
>     use of max-metric is required. Which means the solution requires
>     routers advertising unreachability to potentially regenerate the
>     advertisement in a different form whenever the state of support by
>     all routers in the network for the extension changes.____
> 
>     __ __
> 
>      > Both two draft used The 0xFE000000 metric indicates that the
>     prefix is not
> 
>      > reachable. Doesn't make a difference at this point.
> 
>     __ __
> 
>     [LES:] The solution defined in
>     draft-ppsenak-lsr-igp-unreach-prefix-announce does not introduce any
>     interoperability issues with existing routers, does not require
>     multiple encoding formats, and does not require a router to
>     regenerate advertisements in a different form based on the state of
>     support by all routers in the network.____
> 
>     I think this makes a big difference. 😊____
> 
>     __ __
> 
>         Les____
> 
>     __ __
> 
>      >
> 
>      > Thanks
> 
>      >
> 
>      > Zhibo Hu
> 
>      >
> 
>      > > -----Original Message-----
> 
>      > > From: Lsr [mailto:[e-mail]
>     <mailto:[e-mail]>] On Behalf Of Les Ginsberg
> 
>      > > (ginsberg)
> 
>      > > Sent: Thursday, August 31, 2023 12:31 AM
> 
>      > > To: Peter Psenak <ppsenak=[e-mail]
>     <mailto:ppsenak=[e-mail]>>; linchangwang
> 
>      > > <[e-mail]
>     <mailto:[e-mail]>>; Acee Lindem
>     <[e-mail] <mailto:[e-mail]>>;
> 
>      > > lsr <[e-mail] <mailto:[e-mail]>>
> 
>      > > Cc: [e-mail]
>     <mailto:[e-mail]>
> 
>      > > Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable
>     Prefix
> 
>      > > Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04
> 
>      > >
> 
>      > > Changwang -
> 
>      > >
> 
>      > > It is very important to note ...
> 
>      > >
> 
>      > > <snip>
> 
>      > > > > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and
> 
>      > > > > [RFC9084] to
> 
>      > > > indicate reachability by checking whether the originator
>     information
> 
>      > > > is
> 
>      > > > >    NULL.
> 
>      > > <end snip>
> 
>      > >
> 
>      > > This statement is incorrect. There is no existing mechanism
>     defined in the
> 
>      > > protocol that states that a prefix reachability advertisement
>     sent with a
> 
>      > > source router ID == 0 implies unreachability.
> 
>      > > Please see
>     https://www.rfc-editor.org/rfc/rfc7794.html#section-2.2
>     <https://www.rfc-editor.org/rfc/rfc7794.html#section-2.2>
> 
>      > >
> 
>      > > Existing routers, on receiving a prefix reachability
>     advertisement with a
> 
>      > > Source Router ID == 0 will interpret that prefix as being
>     reachable - which
> 
>      > > is exactly the opposite of the intent defined in
> 
>      > >
>     https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annouc <https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annouc>
> 
>      > > ement-12.txt
> 
>      > > This is one of the things which is broken in this draft.
> 
>      > > This fact has been pointed out to the authors many times over
>     the years -
> 
>      > > but they have consistently ignored it.
> 
>      > >
> 
>      > > On the other hand,
> 
>      > >
>     https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-ureach-prefix-annou <https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-ureach-prefix-annou>
> 
>      > > nce-04.txt uses an existing mechanism defined in RFC 5305 to
>     insure that
> 
>      > > legacy routers who do not understand the new use case or the
>     new flags
> 
>      > > will ignore the prefix reachability advertisement. This has
>     been verified by
> 
>      > > testing against multiple implementations.
> 
>      > >
> 
>      > > Please be accurate in the statements that you make.
> 
>      > >
> 
>      > >    Les
> 
>      > >
> 
>      > >
> 
>      > > > -----Original Message-----
> 
>      > > > From: Lsr <[e-mail]
>     <mailto:[e-mail]>> On Behalf Of Peter Psenak
> 
>      > > > Sent: Wednesday, August 30, 2023 8:43 AM
> 
>      > > > To: linchangwang <[e-mail]
>     <mailto:[e-mail]>>; Acee Lindem
> 
>      > > > <[e-mail] <mailto:[e-mail]>>; lsr
>     <[e-mail] <mailto:[e-mail]>>
> 
>      > > > Cc: [e-mail]
>     <mailto:[e-mail]>
> 
>      > > > Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable
>     Prefix
> 
>      > > > Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04
> 
>      > > >
> 
>      > > > Changwang,
> 
>      > > >
> 
>      > > > On 30/08/2023 08:15, linchangwang wrote:
> 
>      > > > > Hi WG,
> 
>      > > > >
> 
>      > > > > When considering adoption, it's important to take into
>     account the
> 
>      > > > > following
> 
>      > > > drafts as well.
> 
>      > > > >
> 
>      > > > > Draft #1 link：https://www.ietf.org/archive/id/draft-wang-
>     lsr-prefix- <https://www.ietf.org/archive/id/draft-wang-lsr-prefix->
> 
>      > > > unreachable-annoucement-12.txt
> 
>      > > > > Draft #2 link：https://www.ietf.org/archive/id/draft-
>     ppsenak-lsr-igp-
>     <https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp->
> 
>      > > > ureach-prefix-announce-04.txt
> 
>      > > > >
> 
>      > > > > Reasons are as follows:
> 
>      > > > >
> 
>      > > > > 1. The two drafts mentioned above are similar in nature.
> 
>      > > > >    The draft #1 covers more scenarios than the draft #2 as
>     mentioned
> 
>      > > > > by
> 
>      > > > Zhibo Hu mail.
> 
>      > > > >    Therefore, a more in-depth discussion and technical
>     comparison
> 
>      > > > > should
> 
>      > > > take place before any adoption decision is made.
> 
>      > > > >
> 
>      > > > > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and
> 
>      > > > > [RFC9084] to
> 
>      > > > indicate reachability by checking whether the originator
>     information
> 
>      > > > is
> 
>      > > > >    NULL. On the other hand, the draft #2 introduces a new
>     flag to
> 
>      > > > > indicate
> 
>      > > > reachability.
> 
>      > > > >    From an implementation perspective, it would be easier to
> 
>      > > develop
> 
>      > > > > using
> 
>      > > > the existing RFC mechanisms.
> 
>      > > > >
> 
>      > > > > 3. The Draft #1 covers more scenarios and can address the
> 
>      > > > > aggregation issues
> 
>      > > > of multiple ABRs.
> 
>      > > > >    However, the Draft #2 explicitly states in Chapter 6
>     that it does
> 
>      > > > > not support
> 
>      > > > this scenario.
> 
>      > > >
> 
>      > > > to be more precise, draft #1 talks about more scenarios, it
>     does not
> 
>      > > > solves any of them, as these scenarios can not be solved by
>     what the
> 
>      > > > draft #1 introduces.
> 
>      > > >
> 
>      > > > draft#2 clearly states the fact that these scenarios are not
>     addressed.
> 
>      > > >
> 
>      > > > thanks,
> 
>      > > > Peter
> 
>      > > >
> 
>      > > > >
> 
>      > > > > 4. If we remove the additional scenarios covered in Draft
>     #1 and
> 
>      > > > > compare the
> 
>      > > > two drafts, the only remaining difference is the method of
>     indicating
> 
>      > > > unreachable prefixes -
> 
>      > > > >    either through a UPA flag or using the originator TLV.
> 
>      > > > >
> 
>      > > > >
> 
>      > > > > Thanks,
> 
>      > > > > Changwang
> 
>      > > > >
> 
>      > > > >
> 
>      > > > > -----Original Message-----
> 
>      > > > > From: Lsr [mailto:[e-mail]
>     <mailto:[e-mail]>] On Behalf Of Acee Lindem
> 
>      > > > > Sent: Thursday, August 24, 2023 3:58 AM
> 
>      > > > > To: lsr
> 
>      > > > > Cc: [e-mail]
>     <mailto:[e-mail]>
> 
>      > > > > Subject: [Lsr] Working Group Adoption of "IGP Unreachable
>     Prefix
> 
>      > > > Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04
> 
>      > > > >
> 
>      > > > > LSR Working Group,
> 
>      > > > >
> 
>      > > > > This begins the working group adoption call for “IGP
>     Unreachable
> 
>      > > > > Prefix
> 
>      > > > Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> 
>      > > > > Please indicate your support or objection on this list prior to
> 
>      > > > > September 7th,
> 
>      > > > 2023.
> 
>      > > > >
> 
>      > > > > Thanks,
> 
>      > > > > Acee
> 
>      > > > > _______________________________________________
> 
>      > > > > Lsr mailing list
> 
>      > > > > [e-mail] <mailto:[e-mail]>
> 
>      > > > > https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
> 
>      > > > >
>     --------------------------------------------------------------------
> 
>      > > > > ------------------------
> 
>      > > > -----------------------------------------
> 
>      > > > > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地
> 
>      > > 址
> 
>      > > > 中列出
> 
>      > > > > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全
> 
>      > > 部
> 
>      > > > 或部分地泄露、复制、
> 
>      > > > > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或
> 
>      > > 邮
> 
>      > > > 件通知发件人并删除本
> 
>      > > > > 邮件！
> 
>      > > > > This e-mail and its attachments contain confidential
>     information
> 
>      > > > > from New
> 
>      > > > H3C, which is
> 
>      > > > > intended only for the person or entity whose address is listed
> 
>      > > > > above. Any use
> 
>      > > > of the
> 
>      > > > > information contained herein in any way (including, but not
>     limited
> 
>      > > > > to, total
> 
>      > > > or partial
> 
>      > > > > disclosure, reproduction, or dissemination) by persons
>     other than
> 
>      > > > > the
> 
>      > > > intended
> 
>      > > > > recipient(s) is prohibited. If you receive this e-mail in
>     error,
> 
>      > > > > please notify the
> 
>      > > > sender
> 
>      > > > > by phone or email immediately and delete it!
> 
>      > > > > _______________________________________________
> 
>      > > > > Lsr mailing list
> 
>      > > > > [e-mail] <mailto:[e-mail]>
> 
>      > > > > https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
> 
>      > > > >
> 
>      > > >
> 
>      > > > _______________________________________________
> 
>      > > > Lsr mailing list
> 
>      > > > [e-mail] <mailto:[e-mail]>
> 
>      > > > https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
> 
>      > > _______________________________________________
> 
>      > > Lsr mailing list
> 
>      > > [e-mail] <mailto:[e-mail]>
> 
>      > > https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
> 
>     _______________________________________________
>     Lsr mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
>