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