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-ureach-prefix-announce/
also will interpret that prefix as being reachable.
Both two draft used The 0xFE000000 metric indicates that the prefix is not
reachable. Doesn't make a difference at this point.
Thanks
Zhibo Hu
> -----Original Message-----
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Thursday, August 31, 2023 12:31 AM
> To: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; linchangwang
> <linchangwang.04...@h3c.com>; Acee Lindem <acee.i...@gmail.com>;
> lsr <lsr@ietf.org>
> Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
> 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
>
> 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
> 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
> 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 <lsr-boun...@ietf.org> On Behalf Of Peter Psenak
> > Sent: Wednesday, August 30, 2023 8:43 AM
> > To: linchangwang <linchangwang.04...@h3c.com>; Acee Lindem
> > <acee.i...@gmail.com>; lsr <lsr@ietf.org>
> > Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
> > 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-
> > unreachable-annoucement-12.txt
> > > Draft #2 link：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:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> > > Sent: Thursday, August 24, 2023 3:58 AM
> > > To: lsr
> > > Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
> > > 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
> > > Lsr@ietf.org
> > > 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
> > > Lsr@ietf.org
> > > https://www.ietf.org/mailman/listinfo/lsr
> > >
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
