Robert,
On 31/08/2023 02:36, Robert Raszuk wrote:
it would be helpful to summarize the common parts of the two solutions,
Actually IMO it would be much more helpful to summarise differences of
both solutions not common parts.
please read both drafts and you would easily get the difference. If you
are not in favor of doing that, please read Les's response to Zhibo, it
has the most important parts.
thanks,
Peter
Thx,
r.
On Thu, Aug 31, 2023 at 11:23 AM Dongjie (Jimmy) <jie.d...@huawei.com
<mailto:jie.d...@huawei.com>> wrote:
Hi Les and Robert,____
__ __
Please see some comments inline:____
__ __
*From:*Lsr [mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>] *On Behalf Of *Robert Raszuk
*Sent:* Thursday, August 31, 2023 4:19 PM
*To:* Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>>
*Cc:* Huzhibo <huzhibo=40huawei....@dmarc.ietf.org
<mailto:40huawei....@dmarc.ietf.org>>; Peter Psenak (ppsenak)
<ppse...@cisco.com <mailto:ppse...@cisco.com>>; linchangwang
<linchangwang.04...@h3c.com <mailto:linchangwang.04...@h3c.com>>;
Acee Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>>; lsr
<lsr@ietf.org <mailto:lsr@ietf.org>>;
draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
<mailto: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____
__ __
*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. ____
__ __
[Jie] Agreed. Consider the existence of the summary route,
advertising Max_Metric for a prefix covered by the summary route
will not make it unreachable. A router needs to either understand
the new flags as defined in draft-ppsenak, or understand the
semantic of the NULL originator as specified in draft-wang to behave
accordingly. This make me wonder whether it is still necessary to
set the metric of that prefix to Max?____
__ __
After several rounds of update, to me the two solutions becomes
similar in principle , just choose different ways to encode the
trigger information. ____
__ __
__ __
*Dear LSR chairs,*____
__ __
I am not sure what harm would it make to start WG adoption call on
both drafts and see the results. ____
__ __
[Jie] This sounds like a reasonable suggestion. ____
__ __
And since the WG has been discussing this problem and the two
solution drafts for a while, it would be helpful to summarize the
common parts of the two solutions, and highlight their difference,
so that people can understand the current state and make their
decision. ____
__ __
Best regards,____
Jie____
____
So far I am not seeing strong and uniform adoption support for
either one :) ____
__ __
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=40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>> wrote:____
Zhibo -____
____
Please see inline.____
____
> -----Original Message-----____
> From: Huzhibo <huzhibo=40huawei....@dmarc.ietf.org
<mailto:40huawei....@dmarc.ietf.org>>____
> Sent: Wednesday, August 30, 2023 6:33 PM____
> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>; Peter Psenak
(ppsenak)____
> <ppse...@cisco.com <mailto:ppse...@cisco.com>>; linchangwang
<linchangwang.04...@h3c.com
<mailto:linchangwang.04...@h3c.com>>;____
> Acee Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>>; lsr
<lsr@ietf.org <mailto:lsr@ietf.org>>____
> Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
<mailto: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____
> ____
> 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:lsr-boun...@ietf.org
<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
<mailto:ppsenak=40cisco....@dmarc.ietf.org>>; linchangwang____
> > <linchangwang.04...@h3c.com <mailto:linchangwang.04...@h3c.com>>;
Acee Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>>;____
> > lsr <lsr@ietf.org <mailto:lsr@ietf.org>>____
> > Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
<mailto: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
<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 <lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> On
Behalf Of
Peter Psenak____
> > > Sent: Wednesday, August 30, 2023 8:43 AM____
> > > To: linchangwang <linchangwang.04...@h3c.com
<mailto:linchangwang.04...@h3c.com>>;
Acee Lindem____
> > > <acee.i...@gmail.com <mailto:acee.i...@gmail.com>>; lsr
<lsr@ietf.org <mailto:lsr@ietf.org>>____
> > > Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
<mailto: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-
<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:lsr-boun...@ietf.org
<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
<mailto: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 <mailto:Lsr@ietf.org>____
> > > > 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____
> > > > Lsr@ietf.org <mailto:Lsr@ietf.org>____
> > > > https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>____
> > > >____
> > >____
> > > ___________________________________________________
> > > Lsr mailing list____
> > > Lsr@ietf.org <mailto:Lsr@ietf.org>____
> > > https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>____
> > ___________________________________________________
> > Lsr mailing list____
> > Lsr@ietf.org <mailto:Lsr@ietf.org>____
> > https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>____
_______________________________________________
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>____
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
