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
