Subject: [Lsr] Adoption Question Stub-Link vs RFC5316

From: Christian Hopps <[email-masked]>
Date: Thu, 17 Feb 2022 23:45:51 -0500

[As WG Chair]

Hi LSR-WG,

As my co-chair has joined the draft as a co-author making the call on whether we have rough consensus to adopt draft-wang-lsr-stub-link-attributes-02 now falls to me alone.

I've reread the numerous emails on this adoption call and I see some support, and a few objections, and most of the objections are not that there is no problem to solve here, but they think this draft isn't the right way to do it and a revision of RFC5316 could be done instead.

"A bird in the hand is worth two in the bush"

While it might be nice that there is another way to accomplish things by re-using an existing TLV, that work has not been done, whereas we have a written draft in front of us -- that has now been beaten up and reviewed a good deal -- that does seem to provide a solution to an actual problem.

So I'd like to give the WG a final chance to comment here, is there a strongly compelling reason to reject the work that is done here. Examples of "strongly compelling" would be something like "This will break the (IS-IS) decision process" or "this will badly affect scaling" or "this will significantly complicate a protocol implementation", but not "this can be done differently" as the latter is work not done (i.e., it's two birds "in the bush")

I am *not* looking to rehash the entire discussion we've already had so please restrict your replies to the above question only.

Thanks,
Chris.
[As WG Chair]

---

From: Peter Psenak <[email-masked]>
Date: Fri, 18 Feb 2022 08:51:56 +0100

Chris,

the draft attempt to use the local subnet information for identifying 
two endpoints of the same link. That seems wrong in itself. In addition:

1) We have link local/remote IDs (and IP addresses) to pair the two
endpoints of the link in both OSPF and ISIS. We do not need another 
mechanism for the same.

2) What is proposed does not work for unnumbered links.

thanks,
Peter

On 18/02/2022 05:45, Christian Hopps wrote:
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 18 Feb 2022 16:39:17 +0800

Hi, Peter:

I think you may not have time to follow the previous discussions. 
Please refer to
https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/ for
my summary responses, for how to apply the solution in various scenarios,
include the unnumbered scenario(we have updated the draft during the
adoption call process).
We have discussed the drawback of using RFC5316 to solve such requirements
intensely, and I think we need not loop it back again.

And, I can give you(also other LSR experts) another information for the
potential application of this draft:
The CAN(Computing-Aware Network) BOF has been established, here is its
contents
https://datatracker.ietf.org/doc/bofreq-liu-computing-aware-networking-can/

In the last of its description section, we can see:
"This work may then result in an analysis of which protocols/extensions are
required to discover, advertise the location and status of, dynamically
share, and load-balance between services using computation        resources
and those resources themselves."

Besides the solution advantage compared to RFC 5316, the CAN related
scenarios is also one drive to forward this draft, as also described in the
reference document
https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Peter Psenak
Sent: Friday, February 18, 2022 3:52 PM
To: Christian Hopps <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316

Chris,

the draft attempt to use the local subnet information for identifying two
endpoints of the same link. That seems wrong in itself. In addition:

thanks,
Peter

On 18/02/2022 05:45, Christian Hopps wrote:
> [As WG Chair]
> 
> Hi LSR-WG,
> 
> As my co-chair has joined the draft as a co-author making the call on
whether we have rough consensus to adopt
draft-wang-lsr-stub-link-attributes-02 now falls to me alone.
> 
> I've reread the numerous emails on this adoption call and I see some
support, and a few objections, and most of the objections are not that there
is no problem to solve here, but they think this draft isn't the right way
to do it and a revision of RFC5316 could be done instead.
> While it might be nice that there is another way to accomplish things by
re-using an existing TLV, that work has not been done, whereas we have a
written draft in front of us -- that has now been beaten up and reviewed a
good deal -- that does seem to provide a solution to an actual problem.
> 
> So I'd like to give the WG a final chance to comment here, is there a 
> strongly compelling reason to reject the work that is done here. 
> Examples of "strongly compelling" would be something like "This will 
> break the (IS-IS) decision process" or "this will badly affect 
> scaling" or "this will significantly complicate a protocol 
> implementation", but not "this can be done differently" as the latter 
> is work not done (i.e., it's two birds "in the bush")
> 
> I am *not* looking to rehash the entire discussion we've already had so
please restrict your replies to the above question only.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Feb 2022 10:59:47 +0100

Hi Aijun,

I do have some sympathy to what you are trying to do here. But I also have
a concern if IGP is the right protocol to load it and use it disseminate
completely opaque to its main role information.

Imagine your CAN use case and use of areas with summarization. The ingress
nodes/machines may be far away in different areas. How are you planning to
pass the information around ? Leak all stub links along with new
information attached to them all over the domain ?

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Fri, 18 Feb 2022 19:52:40 +0800

Hi, Robert:
Thanks for your considerations.
Currently the optimization routing for CAN scenarios are mainly for local area, I think such information needn’t flood throughout the original area. 
In future, it may be needed in other areas if the cost from the IGP metric play the weak role for optimizations forwarding. 
Then summary or not for these stub link related information depends on the specfic  requirements and can be controlled at the ABR, as we done today.

Aijun Wang
China Telecom

> 在 2022年2月18日，18:00，Robert Raszuk <[email-masked]> 写道：
> 
> 
> Hi Aijun,
> 
> I do have some sympathy to what you are trying to do here. But I also have a concern if IGP is the right protocol to load it and use it disseminate completely opaque to its main role information. 
> 
> Imagine your CAN use case and use of areas with summarization. The ingress nodes/machines may be far away in different areas. How are you planning to pass the information around ? Leak all stub links along with new information attached to them all over the domain ? 
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Fri, Feb 18, 2022 at 9:39 AM Aijun Wang <[email-masked]> wrote:
>> Hi, Peter:
>>

---

From: Christian Hopps <[email-masked]>
Date: Fri, 18 Feb 2022 07:14:12 -0500

> endpoints of the same link. That seems wrong in itself. In addition:

The -03 revision uses other methods to identify an inter-AS link (the same that are used in RFC5316 if I'm not mistaken).

> endpoints of the link in both OSPF and ISIS. We do not need another mechanism
> for the same.

Tony Li (at least) seemed to think that it was useful to be able to attach TE attributes to a link, not just to prefixes. Perhaps I've missed this in the thread but what current mechanism (rfc?) are you referring to, to identify a link and attach TE attributes to it?

> 2) What is proposed does not work for unnumbered links.

Can you clarify if you are saying this b/c you are refusing to look at the -03 revision as "out of process" or does the -03 revision also still fail on this point?

Thanks,
Chris.

>> As my co-chair has joined the draft as a co-author making the call on whether
>> we have rough consensus to adopt draft-wang-lsr-stub-link-attributes-02 now
>> falls to me alone.
>> I've reread the numerous emails on this adoption call and I see some support,
>> and a few objections, and most of the objections are not that there is no
>> problem to solve here, but they think this draft isn't the right way to do it
>> and a revision of RFC5316 could be done instead.
>> So I'd like to give the WG a final chance to comment here, is there a strongly
>> compelling reason to reject the work that is done here. Examples of "strongly
>> compelling" would be something like "This will break the (IS-IS) decision
>> process" or "this will badly affect scaling" or "this will significantly
>> complicate a protocol implementation", but not "this can be done differently"
>> as the latter is work not done (i.e., it's two birds "in the bush")
>> I am *not* looking to rehash the entire discussion we've already had so please
>> restrict your replies to the above question only.
>> Thanks,
>> Chris.
>> [As WG Chair]

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Feb 2022 14:15:19 +0100

Hi Chris,

Tony Li (at least) seemed to think that it was useful to be able to attach
> TE attributes to a link, not just to prefixes. Perhaps I've missed this in
> the thread but what current mechanism (rfc?) are you referring to, to
> identify a link and attach TE attributes to it?

I have two questions which are perhaps more to the WG & Chairs then
authors of this draft.

1. While it is perhaps a good thing to construct better transport paths in
the network this draft puts clients data into the network. So for me it
look like client and application awareness injection is being mixed with
the transport layer. I am not sure if there is common agreement that IGPs
should do that now.

2. If we know that proposed solution may work only on a subset of links and
only in specific flat topologies do we still proceed ?

Thx,
R.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 18 Feb 2022 08:22:56 -0500

Robert Raszuk <[email-masked]> writes:

> Hi Chris,
>
>
>     Tony Li (at least) seemed to think that it was useful to be able
>     to attach TE attributes to a link, not just to prefixes. Perhaps
>     I've missed this in the thread but what current mechanism (rfc?)
>     are you referring to, to identify a link and attach TE attributes
>     to it?
>
>
> 1. While it is perhaps a good thing to construct better transport
> paths in the network this draft puts clients data into the network.
> So for me it look like client and application awareness injection is
> being mixed with the transport layer. I am not sure if there is
> common agreement that IGPs should do that now. 

I didn't see any client/app data in this proposal.. There are other drafts out there that seem to be talking about that, which I also don't like (as wg member )

>
> 2. If we know that proposed solution may work only on a subset of
> links and only in specific flat topologies do we still proceed ? 

It says "stub-links" right in the title so yeah I guess it's only working with a subset of links. :) Apparently this is useful to some people.

Thanks,
Chris.
[as wg member]

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Feb 2022 14:29:25 +0100

> I didn't see any client/app data in this proposal.. There are other drafts
> out there that seem to be talking about that, which I also don't like (as
> wg member )
>

The way I look at them and seeing authors referencing directly those drafts
is that this draft is just a transport for the new stuff to be loaded on
top. Maybe I am wrong, but not sure ...

> It says "stub-links" right in the title so yeah I guess it's only working
> with a subset of links. :) Apparently this is useful to some people.
>

Oh I should say" subset of stub link types,.

Thx !
R.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 18 Feb 2022 14:36:52 +0100

Chris,

I looked at ver-3.

It defines a new top-level TLV, that advertises prefix  and supports all 
existing sub-TLVs defined for link advertisement ("IS-IS Sub-TLVs for 
TLVs Advertising Neighbor Information").

And why? Because authors want to use common subnet to identify two 
endpoints of the same link.

Does not sound right to me.

- we have more than enough TLVs in ISIS to advertise prefix already, 
actually too many of them. We don't need another one.

- using common subnet to identify two endpoints of the same link is 
wrong. We have existing mechanisms for that as as well.

thanks,
Peter

---

From: Christian Hopps <[email-masked]>
Date: Fri, 18 Feb 2022 08:32:31 -0500

Robert Raszuk <[email-masked]> writes:

>  
>
>     I didn't see any client/app data in this proposal.. There are
>     other drafts out there that seem to be talking about that, which
>     I also don't like (as wg member )
>
>
> The way I look at them and seeing authors referencing directly those
> drafts is that this draft is just a transport for the new stuff to be
> loaded on top. Maybe I am wrong, but not sure ... 

[as wg-member] I see this as well, but that's a debate for another day I think, as this particular draft has other (TE) uses which it directly talks to.

[as wg-chair] Once this document is a WG document then the WG is free to rip from it anything it finds objectionable. Anything is possible as this is only an adoption call, not a WGLC for publication.

Thanks,
Chris.

>     It says "stub-links" right in the title so yeah I guess it's only
>     working with a subset of links. :) Apparently this is useful to
>     some people.
>
>

---

From: Christian Hopps <[email-masked]>
Date: Fri, 18 Feb 2022 08:47:49 -0500

[resent with correct CC's]

Peter Psenak <ppsenak=[email-masked]> writes:

> existing sub-TLVs defined for link advertisement ("IS-IS Sub-TLVs for TLVs
> Advertising Neighbor Information").
>
> And why? Because authors want to use common subnet to identify two endpoints of
> the same link.
>

That is not required though, and that is how they addressed the unnumbered case.  but...

> - we have more than enough TLVs in ISIS to advertise prefix already, actually
>  too many of them. We don't need another one.
>
> - using common subnet to identify two endpoints of the same link is wrong. We
>  have existing mechanisms for that as as well.

This is rehashing the old arguments, we're passed that point now.

I've asked for cases that this draft would break things, not whether it has warts or not.

Thanks,
Chris.
[as wg chair]

>> The -03 revision uses other methods to identify an inter-AS link (the same
>> that are used in RFC5316 if I'm not mistaken).
>>
>> Tony Li (at least) seemed to think that it was useful to be able to attach TE
>> attributes to a link, not just to prefixes. Perhaps I've missed this in the
>> thread but what current mechanism (rfc?) are you referring to, to identify a
>> link and attach TE attributes to it?
>>
>> Can you clarify if you are saying this b/c you are refusing to look at the -03
>> revision as "out of process" or does the -03 revision also still fail on this
>> point?
>> Thanks,
>> Chris.
>>
>>>
>>> thanks,
>>> Peter
>>>
>>>
>>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 18 Feb 2022 21:59:14 +0000

Chris -

My objections to this draft are similar to Peter's - the use of a prefix to identify a link is flawed - does not work in all cases. And the use case for the draft can be met using RFC 5316.

It is also incorrect to state that a bis of RFC 5316 is required. That statement was made based on the requirement of RFC 5316 to include AS numbers and the concern that if BGP were not running that you would not have an AS #. But it was pointed out in the thread that this issue could be addressed by using one of the reserved ASNs (0 or 65535) or one of the private ASNs.

I also strongly object to your statement below:

" I've asked for cases that this draft would break things, not whether it has warts or not."

This suggests (intentionally or not) that so long as a draft doesn't break anything it is OK to consider it for adoption. I hope we have a higher bar than that.

In summary, this draft is at best redundant with RFC 5316 and introduces the use of a flawed construct in doing so.
This should NOT be adopted.

    Les

> From: Lsr <[email-masked]> On Behalf Of Christian Hopps
> Sent: Friday, February 18, 2022 5:48 AM
> To: Peter Psenak <ppsenak=[email-masked]>
> Cc: [email-masked]; Christian Hopps <[email-masked]>
> actually
> mechanism
> whether
> support,
> strongly
> please

---

From: John E Drake <[email-masked]>
Date: Fri, 18 Feb 2022 22:27:28 +0000

Hi,

I completely agree with the email from Les, below.  "Do no harm" is an insufficient reason to adopt a draft of redundant and dubious functionality. 

Yours Irrespectively,

John

Juniper Business Use Only

> From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, February 18, 2022 4:59 PM
> To: Christian Hopps <[email-masked]>; Peter Psenak
> <ppsenak=[email-masked]>
> Cc: [email-masked]
> [External Email. Be cautious of content]
> 
> 
> Chris -
> 
> My objections to this draft are similar to Peter's - the use of a prefix to identify a
> link is flawed - does not work in all cases. And the use case for the draft can be
> met using RFC 5316.
> 
> It is also incorrect to state that a bis of RFC 5316 is required. That statement was
> made based on the requirement of RFC 5316 to include AS numbers and the
> concern that if BGP were not running that you would not have an AS #. But it
> was pointed out in the thread that this issue could be addressed by using one of
> the reserved ASNs (0 or 65535) or one of the private ASNs.
> 
> This suggests (intentionally or not) that so long as a draft doesn't break anything
> it is OK to consider it for adoption. I hope we have a higher bar than that.
> 
> > > It defines a new top-level TLV, that advertises prefix  and supports
> > > all existing sub-TLVs defined for link advertisement ("IS-IS
> > > Sub-TLVs for TLVs Advertising Neighbor Information").
> > >
> > >>> the draft attempt to use the local subnet information for
> > >>> identifying two endpoints of the same link. That seems wrong in itself. In
> addition:
> > >> The -03 revision uses other methods to identify an inter-AS link
> > >> (the same that are used in RFC5316 if I'm not mistaken).
> > >>
> > >>> 1) We have link local/remote IDs (and IP addresses) to pair the
> > >>> two endpoints of the link in both OSPF and ISIS. We do not need
> > >>> another
> > mechanism
> > >>> for the same.
> > >> Tony Li (at least) seemed to think that it was useful to be able to
> > >> attach TE attributes to a link, not just to prefixes. Perhaps I've
> > >> missed this in the thread but what current mechanism (rfc?) are you
> > >> referring to, to identify
> > a
> > >> Can you clarify if you are saying this b/c you are refusing to look
> > >> at the -03 revision as "out of process" or does the -03 revision
> > >> also still fail on this point?
> > >> Thanks,
> > >> Chris.
> > >>
> > >>>
> > >>> thanks,
> > >>> Peter
> > >>>
> > >>>
> > >>>
> > >>>> we have rough consensus to adopt
> > >>>> draft-wang-lsr-stub-link-attributes-
> > 02 now
> > >>>> falls to me alone.
> > >>>> and a few objections, and most of the objections are not that
> > >>>> there is
> > no
> > >>>> problem to solve here, but they think this draft isn't the right
> > >>>> way to do
> > it
> > >>>> While it might be nice that there is another way to accomplish
> > >>>> things by re-using an existing TLV, that work has not been done,
> > >>>> whereas we
> > have a
> > >>>> compelling reason to reject the work that is done here. Examples
> > >>>> of
> > "strongly
> > >>>> compelling" would be something like "This will break the (IS-IS)
> > >>>> decision process" or "this will badly affect scaling" or "this
> > >>>> will significantly complicate a protocol implementation", but not
> > >>>> "this can be done
> > differently"
> > >>>> as the latter is work not done (i.e., it's two birds "in the
> > >>>> bush") I am *not* looking to rehash the entire discussion we've
> > >>>> already had so
> > please
> > >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo
> > >>>> /lsr__;!!NEt6yMaO-
> gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713
> > >>>> hGe1f64KVJZUwTuypus$
> > >>>>
> > >>
> > >
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls
> > > r__;!!NEt6yMaO-
> gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713hGe1f6
> > > 4KVJZUwTuypus$
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > _;!!NEt6yMaO-
> gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713hGe1f64KVJ
> > ZUwTuypus$
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-
> gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713hGe1f64KVJZUwTuypus
> $

---

From: Aijun Wang <[email-masked]>
Date: Sat, 19 Feb 2022 06:56:46 +0800

Hi, Les:
I remembered we have discussed your proposal. If you ignored, let me repeat its drawbacks:

Don’t you think it is curious to construct the bogus information within the network, just want to let the operator conform their deployment with the non-aimed application scenarios of one RFC?
The bogus information is not only AS, but also the remote ASBR Identifier.

And I think such scenarios are popular within any operator’s network.

Aijun Wang
China Telecom

> 在 2022年2月19日，05:59，Les Ginsberg (ginsberg) <ginsberg=[email-masked]> 写道：
> 
> Chris -
>

---

From: Aijun Wang <[email-masked]>
Date: Sat, 19 Feb 2022 06:58:13 +0800

Hi, John:
If you follow Les, then also follow my responses to Les.

Aijun Wang
China Telecom

> 在 2022年2月19日，06:28，John E Drake <jdrake=[email-masked]> 写道：
> 
> Hi,
>

---

From: John E Drake <[email-masked]>
Date: Fri, 18 Feb 2022 23:19:43 +0000

I don’t see any response to the points Les made in the email thread, below.  RFC5316 should be fine, so, as I indicated, your draft is redundant and dubious.  As an aside. I find it incredibly obnoxious and not within your remit to be instructing WG members what to do and I hope the WG chairs will curb your behavior.
y
Sent from my iPhone

On Feb 18, 2022, at 5:58 PM, Aijun Wang <[email-masked]> wrote:
[External Email. Be cautious of content]

Hi, John:

Aijun Wang
China Telecom

Hi,

Yours Irrespectively,

John

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, February 18, 2022 4:59 PM
To: Christian Hopps <[email-masked]>; Peter Psenak

Chris -

" I've asked for cases that this draft would break things, not whether it has warts
or not."

In summary, this draft is at best redundant with RFC 5316 and introduces the use
of a flawed construct in doing so.
This should NOT be adopted.

  Les

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Christian Hopps
Sent: Friday, February 18, 2022 5:48 AM
To: Peter Psenak <ppsenak=[email-masked]>
Cc: [email-masked]; Christian Hopps <[email-masked]>
Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316

Chris,

I looked at ver-3.

endpoints of
the same link.

That is not required though, and that is how they addressed the
unnumbered case.  but...

- using common subnet to identify two endpoints of the same link is wrong.
We
have existing mechanisms for that as as well.

I've asked for cases that this draft would break things, not whether
it has warts or not.

Thanks,
Chris.
[as wg chair]

thanks,
Peter

Chris,

thanks,
Peter

As my co-chair has joined the draft as a co-author making the
call on
I've reread the numerous emails on this adoption call and I see
some
written draft in front of us -- that has now been beaten up and
reviewed a
So I'd like to give the WG a final chance to comment here, is
there a

_______________________________________________
Lsr mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RgKRu4nOwH8sR99blLpKhKefs-snXw_uaBREc-siedkHLMhGbrj3E8VIO4H-ibY$

---

From: Christian Hopps <[email-masked]>
Date: Fri, 18 Feb 2022 19:44:44 -0500

> Chris -

[... trimmed out the restated points ...]

> This suggests (intentionally or not) that so long as a draft doesn't break anything it is OK to consider it for adoption. I hope we have a higher bar than that.

No, I really don't think it suggests that if you read my email on this. I think it's pretty obviously that I'm only talking about this draft, and specifically in the context of there having already been a great deal of discussion already during the adoption call. I am specifically asking that people not rehash that discussion again is all.

What one can probably safely infer though, by the email, is that it's looking to the chair like there is rough consensus to adopt the draft. The bar is not as high for adoption as it is for WGLC, and so the consensus can be rather rough.

Adoption is no guarantee of publication.

In fact, one could imagine someone (perhaps from the objecting group) writing an *info* track document that concisely describes how to tie together existing IS-IS and OSPF technologies to more cleanly solve the same problems this draft is targeting, if that is indeed possible, this possibility has certainly been suggested in some emails.

One could then imagine this new document is seen by (a rough consensus of) the WG as a better, cleaner route to take, and so the WG publishes the new document content (either as a newly adopted document, or as large modifications to the existing adopted document) instead.

Thanks,
Chris.
[as wg chair]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 19 Feb 2022 03:26:48 +0000

Chris  -

I don't agree with everything you state below - but let's put that aside.
You have a tough call to make - no matter what you decide some folks will be very unhappy - I don't want to make things tougher for you.

But there is one point that seems highly relevant to me. A compelling case has been made by multiple folks that RFC 5316 can already do what is required. All of Aijun's concerns have been addressed in the original email thread (which is not the same as saying Aijun himself is satisfied on this point).
I do not see why the WG should take on redundant work. And if you think that the question as to whether RFC 5316 is sufficient has not yet been answered to your satisfaction, then I suggest the WG focus on answering that question - which should be done BEFORE deciding whether to adopt The Stub-Link draft.
That seems to me to be the most appropriate way forward.

Good luck!!

   Les

> From: Christian Hopps <[email-masked]>
> Sent: Friday, February 18, 2022 4:45 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; Peter Psenak
> <ppsenak=[email-masked]>; [email-masked]
> > This suggests (intentionally or not) that so long as a draft doesn't break
> anything it is OK to consider it for adoption. I hope we have a higher bar than
> that.
> 
> No, I really don't think it suggests that if you read my email on this. I think it's
> pretty obviously that I'm only talking about this draft, and specifically in the
> context of there having already been a great deal of discussion already
> during the adoption call. I am specifically asking that people not rehash that
> discussion again is all.
> 
> What one can probably safely infer though, by the email, is that it's looking to
> the chair like there is rough consensus to adopt the draft. The bar is not as
> high for adoption as it is for WGLC, and so the consensus can be rather rough.
> 
> In fact, one could imagine someone (perhaps from the objecting group)
> writing an *info* track document that concisely describes how to tie
> together existing IS-IS and OSPF technologies to more cleanly solve the same
> problems this draft is targeting, if that is indeed possible, this possibility has
> certainly been suggested in some emails.
> 
> One could then imagine this new document is seen by (a rough consensus
> of) the WG as a better, cleaner route to take, and so the WG publishes the
> new document content (either as a newly adopted document, or as large
> modifications to the existing adopted document) instead.
> 
> Thanks,
> Chris.
> [as wg chair]

---

From: Aijun Wang <[email-masked]>
Date: Sat, 19 Feb 2022 12:26:22 +0800

Hi, Les:
Would you like to revisit https://mailarchive.ietf.org/arch/msg/lsr/7DwbQXjBO8qeGsES7In7OavN1mk/ for our previous discussion on this point?
If there is no more new contents/inputs, can we stop looping it back again?

I think you should also notice that the bogus information that needs to be flooded within the network, regardless the efforts that the operator must apply these bogus information on all stub links.
I am curious you are still sticking to the inappropriate solutions for the operator.

Aijun Wang
China Telecom

> 在 2022年2月19日，11:27，Les Ginsberg (ginsberg) <ginsberg=[email-masked]> 写道：
> 
> Chris  -
>