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
