with that – but it is hard to strongly advocate for that at this point.
Les
From: Liyan Gong
Sent: Wednesday, July 17, 2024 7:05 PM
To: Christian Hopps ; Aijun Wang
Cc: Tony Przygienda ; Acee Lindem ;
Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
; Yingzhen Qu ; lsr-chairs
; shraddha ; lsr
Subject: Re
Przygienda
Sent: Friday, July 12, 2024 11:23 AM
To: Acee Lindem
Cc: Les Ginsberg (ginsberg) ; Liyan Gong
; Aijun Wang ; Peter
Psenak (ppsenak) ; Yingzhen Qu ;
lsr ; lsr-chairs ; shraddha
Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA
Les, whatever you try to suggest here, you
to address with your draft is addressing a
transient issue, it seems relevant to address all aspects – which is what the
combination of “better-idx” and SA will achieve.
Les
From: Acee Lindem
Sent: Friday, July 12, 2024 9:45 AM
To: Les Ginsberg (ginsberg)
Cc: Liyan Gong ; Aijun Wang
this is clear.
Les
From: Acee Lindem
Sent: Friday, July 12, 2024 7:55 AM
To: Les Ginsberg (ginsberg)
Cc: Liyan Gong ; Aijun Wang
; Peter Psenak (ppsenak) ;
Yingzhen Qu ; lsr ; lsr-chairs
; tony Przygienda ; shraddha
Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA
On Jul 12
To: Les Ginsberg (ginsberg)
Cc: Liyan Gong ; Aijun Wang
; Peter Psenak (ppsenak) ;
Yingzhen Qu ; lsr ; lsr-chairs
; tony Przygienda ; shraddha
Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA
On Jul 12, 2024, at 10:40, Les Ginsberg (ginsberg)
mailto:ginsb...@cisco.com>>
the restarting router that
has the pre-restart adjacency advertisements. (point #1 I made below).
So this is not a robust solution.
Les
From: Acee Lindem
Sent: Friday, July 12, 2024 7:21 AM
To: Les Ginsberg (ginsberg)
Cc: Liyan Gong ; Aijun Wang
; Peter Psenak (ppsenak) ;
Yingzhen Qu ; lsr ; lsr
I am happy that work on this problem has begun.
I believe the most robust way forward is to implement the mechanisms defined in
BOTH drafts.
I think the mechanism defined in draft-hegde-lsr-ospf-better-idbx is sound and
not overly complex (sorry Liyan ) and should be done.
But it does not
Aijun –
Please see inline.
From: Aijun Wang
Sent: Wednesday, July 3, 2024 7:55 PM
To: Les Ginsberg (ginsberg) ; 'Ketan Talaulikar'
; 'Yingzhen Qu'
Cc: 'lsr' ; 'lsr-chairs'
Subject: 答复: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 -
7/15/2024)
Hi, Les:
1
Ketan –
Thanx for the support.
Responses inline.
From: Ketan Talaulikar
Sent: Wednesday, July 3, 2024 9:56 AM
To: Yingzhen Qu
Cc: lsr ; lsr-chairs
Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 -
7/15/2024)
Hi All,
I thank the authors for the work on this draft and
I am not aware of any IPR related to this work.
Supporting as co-author.
Les
From: Yingzhen Qu
Sent: Monday, July 1, 2024 11:08 PM
To: lsr ; lsr-chairs
Subject: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)
Hi,
This email begins a 2 week WG Last Call for the
I support the advancement of this draft.
Use of admin tags is commonplace for multiple applications. Current limitations
of the OSPF protocol in regards to tags do not meet the requirements of
current/future deployments (as detailed in the draft).
This draft brings OSPF on a par with IS-IS in
WG Chairs -
The authors of:
https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-srmpls-yang/
https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-yang/
request WG adoption for these two drafts.
Thanx for your prompt attention to this request.
Les (on behalf of the draft authors)
Sue/Tony -
Speaking as one of the designated experts for many IS-IS registries...
If one searches
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
you will see that IANA lists all of the RFCs relevant to a given registry.
For example, for the registry being
Tony –
Thanx for the prompt response.
Please see inline.
From: Tony Przygienda
Sent: Tuesday, June 25, 2024 6:44 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org; draft-ietf-lsr-distoptflood.auth...@ietf.org
Subject: Re: [Lsr] Comments on draft-ietf-lsr-distoptflood-04
Les, thanks
In the past, I have supported the WG adoption and progression of this draft,
which, prior to V4, has confined itself to defining a flooding algorithm
designed to greatly reduce redundant flooding in highly meshed topologies.
V4 of the draft, in addition to defining the optimized flooding
I support progressing the document.
The change of codepoint registration is necessary to allow all RFC document
tracks to get codepoints when necessary.
This is a non-controversial change which should be done without delay.
Les
From: Yingzhen Qu
Sent: Wednesday, May 22, 2024 8:59 AM
To:
this issue unresolved.
Les
Les
> -Original Message-
> From: Shraddha Hegde
> Sent: Thursday, May 16, 2024 1:55 AM
> To: Acee Lindem
> Cc: Shraddha Hegde ; Ketan Talaulikar ; lsr ; draft-ietf-lsr-flex-algo-bw-
> c...@ietf.org; Les Ginsberg (ginsberg)
> Subje
John –
Bruno wrote the new text – so best if we wait for him to respond. Looks like he
will be back next week.
But my understanding is that your interpretation is correct. If Bruno agrees,
then we can spin a new version with better wording.
Thanx for your feedback and patience.
Les
I support WG adoption.
The change will allow all classes of IETF documents to obtain codepoints from
IS-IS related registries and will make the registration mechanism consistent
for all IS-IS related registries – both of which are desirable changes.
Les
From: Lsr On Behalf Of Yingzhen Qu
To: Shraddha Hegde
Cc: Ketan Talaulikar ; lsr ;
draft-ietf-lsr-flex-algo-bw-...@ietf.org; Les Ginsberg (ginsberg)
Subject: Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07
Hi Ketan, Shraddha and Les,
LGTM
Les (Probably slightly slower than Tony’s response )
From: Lsr On Behalf Of Tony Li
Sent: Tuesday, April 23, 2024 4:26 PM
To: lsr
Subject: [Lsr] Fwd: New Version Notification for
draft-li-lsr-labv-registration-01.txt
Per Les’ requeest.
Elapsed time: 3 mins.
T
Begin forwarded
I support the proposed change as modified by Chris's comment that the target
should be to use Expert Review.
In this way all IS-IS codepoint registries would be handled in a consistent
manner and all would allow any class of RFC - including Experimental - to
obtain a code point when
Top posting one comment.
Regarding
[Bruno2] Well, I have large freedom to express myself in an email. Writing a
summary of WG history in an RFC is a little bit more engaging... Also, although
the perspective may be of interest, it’s less likely of little interest to an
IS-IS implementor.
I
Sarker
Sent: Thursday, April 11, 2024 2:00 AM
To: Les Ginsberg (ginsberg)
Cc: John Scudder ; The IESG ;
draft-ietf-lsr-isis-fast-flood...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org;
acee.i...@gmail.com
Subject: Re: Zaheduzzaman Sarker's Discuss on
draft-ietf-lsr-isis-fast-flooding-08
Shraddha -
Thanx for the response.
Please see inline.
> -Original Message-
> From: Shraddha Hegde
> Sent: Friday, April 12, 2024 8:02 AM
> To: Les Ginsberg (ginsberg) ; Acee Lindem ; lsr
> Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org
> Subject: RE: [Lsr] Worki
trongly we can change
that.
Les
> -Original Message-
> From: John Scudder
> Sent: Tuesday, April 9, 2024 10:31 AM
> To: Les Ginsberg (ginsberg)
> Cc: Zaheduzzaman Sarker ; The IESG
> ; draft-ietf-lsr-isis-fast-flood...@ietf.org;
> lsr-cha...@ietf.org;
>
section names) - which we will
certainly do when generating an updated version.
A few more comments inline.
> -Original Message-
> From: John Scudder
> Sent: Tuesday, April 9, 2024 8:28 AM
> To: Zaheduzzaman Sarker
> Cc: Les Ginsberg (ginsberg) ; The IESG ;
> draft-ietf-l
Draft authors -
Regarding Section 5, which defines the rules for deriving Bandwidth metric,
Rule #1 states:
"If the Generic Metric sub-TLV with Bandwidth metric type is advertised for the
link as described in Section 4, it MUST be used during the Flex-Algorithm
calculation."
I think this
To: Les Ginsberg (ginsberg)
Cc: Zaheduzzaman Sarker ; The IESG
; draft-ietf-lsr-isis-fast-flood...@ietf.org;
lsr-cha...@ietf.org; lsr@ietf.org; acee.i...@gmail.com
Subject: Re: Zaheduzzaman Sarker's Discuss on
draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT)
P. S
: Friday, April 5, 2024 9:37 AM
To: Zaheduzzaman Sarker
Cc: Les Ginsberg (ginsberg) ; The IESG ;
draft-ietf-lsr-isis-fast-flood...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org;
acee.i...@gmail.com; acee-i...@gmail.com
Subject: Re: Zaheduzzaman Sarker's Discuss on
draft-ietf-lsr-isis-fast-flooding
John/Zahed –
In regards to Algorithm 2, note that older versions used the term “Flow
Control”, but based on the discussion with Mirja (not that I am blaming her…)
we changed that section to use the term “Congestion Control”.
This seems proper to me. If one looks at Section 6.1 – and in
not work.
Thanx for the good discussion.
Les
From: Dongjie (Jimmy)
Sent: Thursday, March 21, 2024 6:32 PM
To: Peter Psenak (ppsenak) ; Dongjie (Jimmy)
; Les Ginsberg (ginsberg)
; lsr@ietf.org;
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: RE: [Lsr] Comments on draft-zhu-lsr
for a
node on the repair path because forwarding of packets to that address could be
sent towards multiple nodes.
Les
From: Robert Raszuk
Sent: Friday, March 22, 2024 7:33 AM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem ; lsr ;
draft-chen-lsr-anycast-f...@ietf.org
Subject: Re: [Lsr] Working
I support adoption of this draft.
Knowledge of whether a given prefix is Anycast has proven useful in existing
deployments - closing this gap for OSPFv2 is a good thing to do.
One editorial comment. The introduction (and abstract) states:
" Both SR-MPLS prefix-SID and IPv4 prefix may be
Jie –
Inline.
From: Dongjie (Jimmy)
Sent: Wednesday, March 20, 2024 6:35 PM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org;
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
Hi Les,
Thanks for providing your opinion with an example
4 4:30 PM
> To: Les Ginsberg (ginsberg) ; lsr@ietf.org; draft-zhu-lsr-
> isis-sr-vtn-flexalgo.auth...@ietf.org
> Subject: RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
>
> Hi Les,
>
> Thanks for the review and comments.
>
> Please see some replies i
This draft discusses how to use flex-algo in support of Network Resource
Partitions (NRPs). In particular, it proposes to use a combination of L3 links
and
L2 Bundle member links as the topology associated with a given NRP. In those
cases where an L3 link is using an L2 bundle and individual
+1
The problem can be solved - and in a much more robust way than what is proposed
in the draft - without any protocol extensions.
There is no reason for this draft.
Les
> -Original Message-
> From: Lsr On Behalf Of Acee Lindem
> Sent: Monday, March 18, 2024 12:50 PM
> To:
Bruno -
Inline.
> -Original Message-
> From: bruno.decra...@orange.com
> Sent: Friday, March 15, 2024 11:17 AM
> To: Les Ginsberg (ginsberg) ; Barry Leiba
>
> Cc: draft-ietf-lsr-isis-fast-flooding@ietf.org; last-c...@ietf.org;
> lsr@ietf.org;
> sec..
Bruno/Barry -
In regards to:
> > — Section 4.4 —
> >
>> Length: Indicates the length in octets (1-8) of the Value field. The
>> length SHOULD be the minimum required to send all bits that are set.
> >
> > The SHOULD seems very odd: what would be a good reason to make it
> longer than
; Yingzhen Qu ;
Christian Hopps
Cc: Les Ginsberg (ginsberg) ; jie.d...@huawei.com;
AceeLindem ; Gyan Mishra ; lsr
; lsr-chairs ; ketan Talaulikar
Subject: Re:Re: [Lsr]
WGAdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)
Hi All,
Sincerely appreciate all your remainder
Or – if the authors want to consider my comments – replace “unreachable” in the
name with something more apt – perhaps:
“lsr-ospf-max-link-metric”
Les
From: Lsr On Behalf Of Yingzhen Qu
Sent: Tuesday, March 12, 2024 1:11 PM
To: Liyan Gong
Cc: jie.d...@huawei.com; Acee Lindem ; Gyan
Acee -
Sorry, for some reason I thought you had copied the RFC5130 text verbatim - but
I see that is not the case.
Apologies for the noise.
Les
> -Original Message-
> From: Acee Lindem
> Sent: Monday, March 4, 2024 12:56 PM
> To: Les Ginsberg (ginsberg)
> Cc:
are not convinced, so be it - we have lived with the lax language in RFC
5130 for years. But some things may not be working because of that.
Les
> -Original Message-
> From: Acee Lindem
> Sent: Monday, March 4, 2024 12:12 PM
> To: Les Ginsberg (ginsberg)
> Cc: Tony P
I also support publication of this document.
The functionality defined herein adds valuable flexibility to the way Flex
Topologies can be defined.
Although I have not reviewed Acee’s comments exhaustively, I agree with the
points he is making and would like to see an updated version of the
> Sent: Friday, March 1, 2024 10:27 AM
> To: Tony Przygienda
> Cc: Les Ginsberg (ginsberg) ; lsr
> Subject: Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-
> ietf-lsr-ospf-admin-tags
>
> At the risk of complication, I've added text to clarify the o
I support WG adoption of this draft.
Being able to advertise a link that is not used in the base SPF is a useful
functionality to have.
I do think that the language currently used in the draft could be improved.
Currently the draft says:
“there are requirements to advertise unreachable
links
Tony –
In the spirit of a friendly discussion…
From: Lsr On Behalf Of Tony Przygienda
Sent: Thursday, February 29, 2024 10:33 AM
To: Acee Lindem
Cc: lsr
Subject: Re: [Lsr] bunch comments on
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags
1. you can easily rectify by saying,
Mirja -
Please see inline.
LES2:
> -Original Message-
> From: Mirja Kuehlewind (IETF)
> Sent: Thursday, February 8, 2024 5:11 AM
> To: Les Ginsberg (ginsberg)
> Cc: tsv-...@ietf.org; draft-ietf-lsr-isis-fast-flooding@ietf.org;
> lsr@ietf.org
> Subject: Re: [
In regards to "operation on a LAN interface",
>
> > Section 6.2.1.2:
> > “f no PSNPs have been generated on the LAN for a suitable period of time,
> then an LSP transmitter can safely set the number of un-acknowledged LSPs to
> zero.
> > Since this suitable period of time is much higher
Mirja -
In regards to Section 6.3...
>
> Sec 6.3
> This section is entirely not clear to me. There is no algorithm described and
> I
> would not know how to implement this.
[LES:] This is intentional.
As this approach is NOT dependent on any signaling from the receiver, the
transmitter is
ginal Message-
> From: Lsr On Behalf Of Acee Lindem
> Sent: Thursday, February 1, 2024 9:42 AM
> To: Les Ginsberg (ginsberg)
> Cc: DECRAENE Bruno INNOV/NET ; John
> Scudder ; lsr ; Tony Li ;
> gsoli...@protonmail.com; Antoni Przygienda ; Gunter van
> de Velde (Nokia) ; Mare
Acee -
> > ---
> > //Acee
> >
> > A bigger issue from that historical artifact is that some text refers to
> > "LSP
> Burst Window" when they should refer to the "new" (from -01) "Receive
> Window sub-TLV". That's a bigger issue as "in letter" this may be seen as
> technical change (even if "in
draft.
Fair enough. But this is an issue of significance and needs to be openly
discussed – though not in the context of this thread.)
Les
From: Les Ginsberg (ginsberg)
Sent: Friday, January 19, 2024 11:37 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem
Cc: Chongfeng Xie ; TEAS WG ; lsr
scussion of the larger
> questions - not just the one sentence.
>
> No - I have not seen your shepherd writeup - it does not seem to be visible on
> the document status page.
>
>Les
>
>
> > -Original Message-----
> > From: Acee Lindem mailt
status page.
Les
> -Original Message-
> From: Acee Lindem
> Sent: Friday, January 19, 2024 11:05 AM
> To: Les Ginsberg (ginsberg)
> Cc: Chongfeng Xie ; Les Ginsberg (ginsberg)
> ; jmh ; TEAS WG
> ; lsr
> Subject: Re: [Lsr] [Teas] Fwd: Working Group Last
when trying to have a frank exchange of views on the
technical points of a draft.
I am unlikely to respond further after this – but please find some responses
inline. See [LES2:].
From: Aijun Wang
Sent: Thursday, January 18, 2024 1:29 AM
To: Les Ginsberg (ginsberg)
Cc: 'Christian Hopps
Aijun -
From: Aijun Wang
Sent: Tuesday, January 16, 2024 10:56 PM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Huzhibo ; Acee
Lindem ; Yingzhen Qu ;
lsr@ietf.org
Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
(01/05/2024 - 01/19/2024)
Hi, Les:
Let’s keep
Aijun –
Please see inline.
From: Aijun Wang
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
; 'Huzhibo'
Cc: 'Acee Lindem' ; 'Yingzhen Qu'
; lsr@ietf.org
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
(01/05/2024 - 01/19
I respect that individuals may have different opinions - but it is important to
distinguish what is factual from what is not.
Opinions based upon false information are clearly compromised.
Please do heed Chris's (as WG chair) admonition to review the first WG adoption
thread. That will reveal
, 2024 7:41 PM
To: Les Ginsberg (ginsberg) ; jmh
; Acee Lindem ; TEAS WG
; lsr
Subject: Re: [Lsr] [Teas] Fwd: Working Group Last Call for "Applicability of
IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition
(NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Hi Le
(NOTE: I am replying to Joel’s post rather than the original last call email
because I share some of Joel’s concerns – though my opinion on the merits of
the draft is very different.
Also, I want to be sure the TEAS WG gets to see this email.)
I oppose Last Call for
I oppose WG adoption.
The reasons that I opposed adoption the first time remain valid:
1)The use of a prefix to represent a link is a flawed concept
2) RFC 9346 (previously RFC 5316) and RFC 5392 (as well as BGP-LS) are
available to address the use cases.
The updated draft does nothing to
ickly found.
Les
> -Original Message-
> From: tom petch
> Sent: Wednesday, December 13, 2023 9:34 AM
> To: Les Ginsberg (ginsberg) ; lsr-cha...@ietf.org
> Cc: lsr@ietf.org
> Subject: Re: RFC8665
>
> From: Les Ginsberg (ginsberg)
> Sent: 11 December 2023 16:4
Tom -
https://datatracker.ietf.org/doc/rfc8665/
And there is a link to it here: https://datatracker.ietf.org/wg/ospf/documents/
Not sure why you are having issues.
Les
> -Original Message-
> From: Lsr On Behalf Of tom petch
> Sent: Monday, December 11, 2023 4:02 AM
> To:
s a reason to reread the thread and try
to figure out why you have incorrectly concluded that Parag and I are not in
agreement - or you won't. That is totally your decision.
Les
From: Huaimo Chen
Sent: Saturday, December 9, 2023 6:06 AM
To: Parag Kaneriya ; Les Ginsberg (ginsberg)
; li_zhenqi...@h
amically as sub-TLVs are
added/removed.
Deploying something that at best works some of the time is certain to lead to
big problems.
Our responsibility is to define robust solutions.
Les
From: Parag Kaneriya
Sent: Friday, December 8, 2023 8:29 AM
To: Huaimo Chen ; Les Ginsberg (ginsberg)
; li_zhenqi.
.
Les
From: Huaimo Chen
Sent: Friday, December 8, 2023 5:46 AM
To: Tony Przygienda
Cc: Les Ginsberg (ginsberg) ;
li_zhenqi...@hotmail.com; Tony Li ; Linda Dunbar
; Yingzhen Qu ;
draft-pkaneria-lsr-multi-...@ietf.org; lsr
Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv
Gyan>
If we made the sending of MP TLV a MUST it would provide the similar type of
backwards compatibility as BIG TLV with the capability TLV.
Advantage of doing it inside the protocol is that we eliminate configuration of
enable/disable state default variations and are able to ensue
m: John Scudder
> Sent: Thursday, December 7, 2023 1:13 PM
> To: Les Ginsberg (ginsberg)
> Cc: Acee Lindem ; Hannes Gredler
> ; stefano.prev...@gmail.com; Clarence Filsfils (cfilsfil)
> ; abashandy.i...@gmail.com; han...@rtbrick.com;
> DECRAENE Bruno INNOV/NET ;
> slitkows.i.
; From: Acee Lindem
> Sent: Thursday, December 7, 2023 12:44 PM
> To: John Scudder
> Cc: Hannes Gredler ;
> stefano.prev...@gmail.com; Les Ginsberg (ginsberg) ;
> Clarence Filsfils (cfilsfil) ; abashandy.i...@gmail.com;
> han...@rtbrick.com; DECRAENE Bruno INNOV/NET
> ; sl
that I can declare it “backwards compatible”. By that definition everything is
“backwards compatible”.
This makes the term “backwards compatibility” meaningless.
This POV is neither useful nor sensible.
Les
From: Huaimo Chen
Sent: Thursday, December 7, 2023 6:07 AM
To: Les Ginsberg
change/clarification is needed?
Les
> -Original Message-
> From: John Scudder
> Sent: Wednesday, December 6, 2023 1:13 PM
> To: stefano.prev...@gmail.com; Les Ginsberg (ginsberg)
> ; Clarence Filsfils (cfilsfil) ;
> abashandy.i...@gmail.com; han...@rtbrick.c
advertisement to determine when it is safe to use the
advertisements.
Les
From: li_zhenqi...@hotmail.com
Sent: Monday, December 4, 2023 10:35 PM
To: Huaimo Chen ; Les Ginsberg (ginsberg)
; Tony Li ; Linda Dunbar
Cc: Yingzhen Qu ;
draft-pkaneria-lsr-multi-...@ietf.org; lsr
Subject: Re: Re
Linda –
When we have polarized positions (for whatever reasons), coming to consensus is
often difficult. Each side tends to dismiss the arguments of the other –
sometimes regardless of merit.
So, maybe the following won’t help – but I am going to give it a try.
Point #1: There are existing
, 2023 11:24 PM
To: Acee Lindem
Cc: Les Ginsberg (ginsberg) ; Yingzhen Qu
; lsr ; lsr-chairs
Subject: Re: [Lsr] IETF 118 LSR Minutes
Hi Acee/Les,
Seems to be a known issue, See
https://github.com/ietf-tools/datatracker/issues/5952
Perhaps we can comment there asking the tools team
FWIW –
The new format for the chatlog is much less readable than previous.
Here is the format from IETF 116:
Ketan Talaulikar
00:39:39
There is a WG draft for per-algo adj-sid :
https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/
If we have large number of links,
Xiaohu –
I also point out that there are at least two existing drafts which specifically
address IS-IS flooding reduction in CLOS networks and do so in greater detail
and with more robustness than what is in your draft:
https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
Bruno –
You began your comments in the context of the adoption thread (Subject: RE:
[Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 -
12/09/2023)).
I note that you subsequently started a new thread with new (Subject:
draft-pkaneria-lsr-multi-tlv).
But as the new thread
Huaimo -
Every statement you make below is false.
These points have been discussed - in WG meetings, on the mailing list, and in
private conversations.
But you persist in repeating false claims.
This is not helpful.
You are, of course, entitled to have whatever opinion you choose regarding MP
Bruno -
First, without dismissing your comments, this is a WG adoption call - not a
Last Call to publish a draft as an RFC (as Tony has pointed out).
Could you state unambiguously whether you support adoption or not?
I am in agreement with Tony's responses. I think my earlier reply to you is
I support adoption of this draft.
It is a reasonable (and well proven) solution to a real world problem.
Les
> -Original Message-
> From: Lsr On Behalf Of Acee Lindem
> Sent: Friday, November 17, 2023 8:02 AM
> To: Lsr
> Cc: draft-chen-lsr-prefix-extended-fl...@ietf.org
> Subject:
Lindem
Cc: DECRAENE Bruno INNOV/NET ; Les Ginsberg
(ginsberg) ; Loa Andersson ;
lsr@ietf.org
Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
Hi,
About the name, here are some suggestions about the module name and prefix:
* ietf-isis-feature-support.yang, isis-fs (YANG Module
+2 support adoption as coauthor
(Chairs – is it really necessary for the authors to express support for their
own draft? )
Les
From: Tony Przygienda
Sent: Friday, November 17, 2023 10:29 AM
To: Tony Li
Cc: Yingzhen Qu ;
draft-pkaneria-lsr-multi-...@ietf.org; lsr
Subject: Re: [Lsr] WG
"No, I'm not aware of any IPR that applies to this draft"
Les
From: Yingzhen Qu
Sent: Friday, November 17, 2023 9:01 AM
To: draft-pkaneria-lsr-multi-...@ietf.org; lsr
Cc: lsr-chairs
Subject: IPR Poll for draft-pkaneria-lsr-multi-tlv
Hi,
This is an IPR call for
Acee –
Thanx for the comments – inline.
From: Acee Lindem
Sent: Thursday, November 16, 2023 2:33 PM
To: Les Ginsberg (ginsberg)
Cc: Loa Andersson ; lsr@ietf.org
Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
Speaking as a WG contributor:
Hi Les,
I think a simpler name is better
Loa -
I agree with you that simply "IS-IS Support" may not be the best choice.
Although, the meeting minutes have not yet been posted, as I recall my response
to Tony Li's suggestion of "IS-IS Support" was "Yes - something like that."
The draft authors have not yet discussed this - but we will
Bruno –
Thanx for the thoughtful comments.
Please see responses inline.
From: bruno.decra...@orange.com
Sent: Thursday, November 16, 2023 6:40 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps
Cc: lsr@ietf.org
Subject: RE: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"
Ketan –
I am very happy to be wrong in this case.
We are in full agreement.
Les
From: Lsr On Behalf Of Ketan Talaulikar
Sent: Monday, November 6, 2023 11:52 PM
To: Les Ginsberg (ginsberg)
Cc: John Drake ; Peter Psenak (ppsenak)
; Aijun Wang ; lsr@ietf.org
Subject: Re: [Lsr] Technical
To add to what Ketan has stated…
draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism for
both OSPF and IS-IS i.e., it proposes to use a prefix-originator sub-TLV with
address set to 0.0.0.0 to indicate unreachability.
For OSPF, this might be considered compatible with RFC
Hopps
> Sent: Monday, November 6, 2023 6:10 AM
> To: Les Ginsberg (ginsberg)
> Cc: Christian Hopps ; lsr@ietf.org
> Subject: Re: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"
>
>
> My point is that people are not using the same definition of b
Chris (and everyone) -
A more complete response to your comments regarding "backwards compatibility",
routing loops, etc.
It is absolutely true that until all nodes in the network support advertisement
(meaning at least receive processing) of more than 255 bytes for a given
object, that
, November 5, 2023 3:06 PM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: RE: draft-chen-lsr-isis-big-tlv
Hi Les,
Thank you very much for your responses.
draft-chen-lsr-isis-big-tlv resolves the issue: unpredictable behavior with
partial deployment, which are stated in both IETF 117 and IETF
Huaimo -
Thanx for bringing this up. Resolving this before the meeting hopefully will
save us time during the meeting.
"Backwards compatibility" is possible in situations where new advertisements
are being introduced and the legacy nodes either:
* Don't need to process the new
Yao –
A few comments…
While I appreciate that the limits you are defining are different than any of
the limits currently supported by the IGP MSD-Types registry, I think they
still fall conceptually into the same generic bucket i.e., you want to
advertise a limit related to a type of packet
Acee -
From: Acee Lindem
Sent: Thursday, August 31, 2023 10:33 AM
To: Acee Lindem
Cc: lsr ; draft-ietf-lsr-isis-fast-flood...@ietf.org
Subject: Re: Working Group Last Call for "IS-IS Fast Flooding" -
draft-ietf-lsr-isis-fast-flooding-04
I support publication.
I’ve done the shepherds review
Les
Thanks
Zhibo
Les
>
> Thanks
>
> Zhibo Hu
>
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg
> > (ginsberg)
> > Sent: Thursday, August 31, 2023 12:31 AM
> > To: Peter Ps
.
If rereading is of no help – please ask someone else to explain it to you – I
do not know how to state things more clearly than I have.
Respectfully,
Les
From: Lsr On Behalf Of Aijun Wang
Sent: Wednesday, August 30, 2023 8:37 PM
To: 'Les Ginsberg (ginsberg)' ; 'Huzhibo'
; Peter Psenak
Zhibo -
Please see inline.
> -Original Message-
> From: Huzhibo
> Sent: Wednesday, August 30, 2023 6:33 PM
> To: Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
> ; linchangwang ;
> Acee Lindem ; lsr
> Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ie
Changwang -
It is very important to note ...
> > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and [RFC9084] to
> indicate reachability by checking whether the originator information is
> >NULL.
This statement is incorrect. There is no existing mechanism defined in the
1 - 100 of 833 matches
Mail list logo
