Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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) > 写道： > > 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 > > >> -Original Message- >> From: Christian Hopps >> Sent: Friday, February 18, 2022 4:45 PM >> To: Les Ginsberg (ginsberg) >> Cc: Christian Hopps ; Peter Psenak >> ; lsr@ietf.org >> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316 >> >> >> "Les Ginsberg (ginsberg)" writes: >> >>> Chris - >> >> [... trimmed out the restated points ...] >> >>> 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. >> >> 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] > > ___ > 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
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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 > -Original Message- > From: Christian Hopps > Sent: Friday, February 18, 2022 4:45 PM > To: Les Ginsberg (ginsberg) > Cc: Christian Hopps ; Peter Psenak > ; lsr@ietf.org > Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316 > > > "Les Ginsberg (ginsberg)" writes: > > > Chris - > > [... trimmed out the restated points ...] > > > 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. > > 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] ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
"Les Ginsberg (ginsberg)" writes: Chris - [... trimmed out the restated points ...] 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. 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] ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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 wrote:
[External Email. Be cautious of content]
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 写道：
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
-Original Message-
From: Lsr On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, February 18, 2022 4:59 PM
To: Christian Hopps ; Peter Psenak
Cc: lsr@ietf.org
Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
[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.
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
-Original Message-
From: Lsr On Behalf Of Christian Hopps
Sent: Friday, February 18, 2022 5:48 AM
To: Peter Psenak
Cc: lsr@ietf.org; Christian Hopps
Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
[resent with correct CC's]
Peter Psenak writes:
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.
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]
thanks,
Peter
On 18/02/2022 13:14, Christian Hopps wrote:
Peter Psenak writes:
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:
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
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.
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.
"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
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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 写道：
>
> 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
>
>> -Original Message-
>> From: Lsr On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Friday, February 18, 2022 4:59 PM
>> To: Christian Hopps ; Peter Psenak
>>
>> Cc: lsr@ietf.org
>> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
>>
>> [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.
>>
>> 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
>>
>>
>>> -Original Message-
>>> From: Lsr On Behalf Of Christian Hopps
>>> Sent: Friday, February 18, 2022 5:48 AM
>>> To: Peter Psenak
>>> Cc: lsr@ietf.org; Christian Hopps
>>> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
>>>
>>> [resent with correct CC's]
>>>
>>> Peter Psenak writes:
>>>
>>>> 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.
>>>
>>> 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]
>>>
>>>> thanks,
>>>> Peter
>>>>
>>>>> On 18/02/2022 13:14, Christian Hopps wrote:
>>>>>> Peter Psenak writes:
>>>>>>
>>>>>>> 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:
>>>>>> 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)
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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)
> 写道：
>
> 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
>
>
>> -Original Message-
>> From: Lsr On Behalf Of Christian Hopps
>> Sent: Friday, February 18, 2022 5:48 AM
>> To: Peter Psenak
>> Cc: lsr@ietf.org; Christian Hopps
>> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
>>
>> [resent with correct CC's]
>>
>> Peter Psenak writes:
>>
>>> 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.
>>
>> 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]
>>
>>> thanks,
>>> Peter
>>>
>>> On 18/02/2022 13:14, Christian Hopps wrote:
>>>> Peter Psenak writes:
>>>>
>>>>> 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:
>>>> 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
>>>> 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.
>>>>
>>>>>
>>>>> thanks,
&
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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
> -Original Message-
> From: Lsr On Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, February 18, 2022 4:59 PM
> To: Christian Hopps ; Peter Psenak
>
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
>
> [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.
>
> 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
>
>
> > -Original Message-
> > From: Lsr On Behalf Of Christian Hopps
> > Sent: Friday, February 18, 2022 5:48 AM
> > To: Peter Psenak
> > Cc: lsr@ietf.org; Christian Hopps
> > Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
> >
> > [resent with correct CC's]
> >
> > Peter Psenak writes:
> >
> > > 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.
> >
> > 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]
> >
> > > thanks,
> > > Peter
> > >
> > > On 18/02/2022 13:14, Christian Hopps wrote:
> > >> Peter Psenak writes:
> > >>
> > >>> 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:
> > >> 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
> > >> 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
> > &g
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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
> -Original Message-
> From: Lsr On Behalf Of Christian Hopps
> Sent: Friday, February 18, 2022 5:48 AM
> To: Peter Psenak
> Cc: lsr@ietf.org; Christian Hopps
> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
>
> [resent with correct CC's]
>
> Peter Psenak writes:
>
> > 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.
>
> 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]
>
> > thanks,
> > Peter
> >
> > On 18/02/2022 13:14, Christian Hopps wrote:
> >> Peter Psenak writes:
> >>
> >>> 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:
> >> 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
> >> 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.
> >>
> >>>
> >>> 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.
> >>>> "A bird in the hand is worth two in the bush"
> >>&
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
[resent with correct CC's]
Peter Psenak writes:
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.
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]
thanks,
Peter
On 18/02/2022 13:14, Christian Hopps wrote:
Peter Psenak writes:
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:
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
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.
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.
"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]
___
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
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
Robert Raszuk 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. > 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. Oh I should say" subset of stub link types,. Thx ! R. ___ 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
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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
On 18/02/2022 13:14, Christian Hopps wrote:
Peter Psenak writes:
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:
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
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.
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.
"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]
___
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
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
Robert Raszuk 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? 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. 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] Thx, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
Peter Psenak writes: 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: 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 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. 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. "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] ___ 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
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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 写道： > > > 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 wrote: >> 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 computationresources >> 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: lsr-boun...@ietf.org On Behalf Of Peter Psenak >> Sent: Friday, February 18, 2022 3:52 PM >> To: Christian Hopps ; lsr >> 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: >> >> 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: >> > [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
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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 wrote: > 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 computationresources > 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: lsr-boun...@ietf.org On Behalf Of Peter > Psenak > Sent: Friday, February 18, 2022 3:52 PM > To: Christian Hopps ; lsr > 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: > > 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: > > [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] > > > > ___ > > 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
Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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 computationresources 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: lsr-boun...@ietf.org On Behalf Of Peter Psenak Sent: Friday, February 18, 2022 3:52 PM To: Christian Hopps ; lsr 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: 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: > [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] > > ___ > 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
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: 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: [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] ___ 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] Adoption Question Stub-Link vs RFC5316
[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] ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
