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 protected]> 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 <[email protected]> 写道： 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 <[email protected]> On Behalf Of Les Ginsberg (ginsberg) Sent: Friday, February 18, 2022 4:59 PM To: Christian Hopps <[email protected]>; Peter Psenak <[email protected]> Cc: [email protected] 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 <[email protected]> On Behalf Of Christian Hopps Sent: Friday, February 18, 2022 5:48 AM To: Peter Psenak <[email protected]> Cc: [email protected]; Christian Hopps <[email protected]> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316 [resent with correct CC's] Peter Psenak <[email protected]> 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 <[email protected]> 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 [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo /lsr__;!!NEt6yMaO- gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713 hGe1f64KVJZUwTuypus$ _______________________________________________ Lsr mailing list [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls r__;!!NEt6yMaO- gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713hGe1f6 4KVJZUwTuypus$ _______________________________________________ Lsr mailing list [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ _;!!NEt6yMaO- gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713hGe1f64KVJ ZUwTuypus$ _______________________________________________ Lsr mailing list [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt 6yMaO- gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713hGe1f64KVJZUwTuypus $ _______________________________________________ Lsr mailing list [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RgKRu4nOwH8sR99blLpKhKefs-snXw_uaBREc-siedkHLMhGbrj3E8VIO4H-ibY$ Juniper Business Use Only
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
