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://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
