ether to adopt The Stub-Link draft.
> That seems to me to be the most appropriate way forward.
>
> Good luck!!
>
> Les
>
>
>> -Original Message-
>> From: Christian Hopps
>> Sent: Friday, February 18, 2022 4:45 PM
>> To: Les Ginsberg (ginsberg)
>&g
.
Good luck!!
Les
> -Original Message-
> From: Christian Hopps
> Sent: Friday, February 18, 2022 4:45 PM
> To: Les Ginsberg (ginsberg)
> Cc: Christian Hopps ; Peter Psenak
> ; lsr@ietf.org
> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
>
>
"Les Ginsberg (ginsberg)" writes:
Chris -
[... trimmed out the restated points ...]
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
2022 4:59 PM
To: Christian Hopps ; Peter Psenak
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
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
f Of Christian Hopps
>> Sent: Friday, February 18, 2022 5:48 AM
>> To: Peter Psenak
>> Cc: lsr@ietf.org; Christian Hopps
>> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
>>
>> [resent with correct CC's]
>>
>> Peter Psenak writes:
ginsberg)
> Sent: Friday, February 18, 2022 4:59 PM
> To: Christian Hopps ; Peter Psenak
>
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
>
> [External Email. Be cautious of content]
>
>
> Chris -
>
> My objections to thi
ak
> Cc: lsr@ietf.org; Christian Hopps
> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
>
> [resent with correct CC's]
>
> Peter Psenak writes:
>
> > Chris,
> >
> > I looked at ver-3.
> >
> > It defines a new top-level TLV, that a
[resent with correct CC's]
Peter Psenak 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
Robert Raszuk writes:
I didn't see any client/app data in this proposal.. There are
other drafts out there that seem to be talking about that, which
I also don't like (as wg member )
The way I look at them and seeing authors referencing directly those
drafts is that this
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
Robert Raszuk writes:
Hi Chris,
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
Hi Chris,
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?
I have two
Peter Psenak 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
/datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03
>>
>>
>> Best Regards
>>
>> Aijun Wang
>> China Telecom
>>
>> -Original Message-
>> From: lsr-boun...@ietf.org On Behalf Of Peter Psenak
>> Sent: Friday, Februar
ietf.org On Behalf Of Peter
> Psenak
> Sent: Friday, February 18, 2022 3:52 PM
> To: Christian Hopps ; lsr
> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
>
> Chris,
>
> the draft attempt to use the local subnet information for identifying two
> endpoin
: Re: [Lsr] Adoption Question Stub-Link vs RFC5316
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:
1) We have link local/remote IDs (and IP addresses) to pair the two
endpoints of the link in both OSPF an
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:
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
[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
19 matches
Mail list logo
