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 <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, February 18, 2022 4:59 PM
> To: Christian Hopps <cho...@chopps.org>; Peter Psenak
> <ppsenak=40cisco....@dmarc.ietf.org>
> Cc: lsr@ietf.org
> 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 <lsr-boun...@ietf.org> On Behalf Of Christian Hopps
> > Sent: Friday, February 18, 2022 5:48 AM
> > To: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>
> > Cc: lsr@ietf.org; Christian Hopps <cho...@chopps.org>
> > Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
> >
> > [resent with correct CC's]
> >
> > Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> 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 <ppse...@cisco.com> 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
> > >>>> Lsr@ietf.org
> > >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo
> > >>>> /lsr__;!!NEt6yMaO-
> gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713
> > >>>> hGe1f64KVJZUwTuypus$
> > >>>>
> > >>
> > >
> > > _______________________________________________
> > > Lsr mailing list
> > > Lsr@ietf.org
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls
> > > r__;!!NEt6yMaO-
> gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713hGe1f6
> > > 4KVJZUwTuypus$
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > _;!!NEt6yMaO-
> gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713hGe1f64KVJ
> > ZUwTuypus$
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-
> gk!Sq6QXSQc0WzKiJppYuSZD0zM2dcdCp7bP8aI4ojSo713hGe1f64KVJZUwTuypus
> $
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
