erwise the arguments we make on the consequences of that
choice make no sense to each other.
Les
> -Original Message-
> From: Tony Li On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 1:08 PM
> To: Les Ginsberg (ginsberg)
> Cc: Peter Psenak (ppsenak) ; Shradd
Tony -
> -Original Message-
> From: Tony Li On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 11:25 AM
> To: Les Ginsberg (ginsberg)
> Cc: Peter Psenak (ppsenak) ; Shraddha Hegde
> ; Robert Raszuk ; Van De
> Velde, Gunter (Nokia - BE/Antwerp) ;
> lsr@ietf
Tony -
> -Original Message-
> From: Tony Li On Behalf Of Tony Li
> Sent: Friday, July 30, 2021 9:55 AM
> To: Peter Psenak (ppsenak)
> Cc: Shraddha Hegde ; Robert Raszuk
> ; Van De Velde, Gunter (Nokia - BE/Antwerp)
> ; Les Ginsberg (ginsberg)
> ; lsr@ietf
Guillaume –
Please see LES2: inline.
From: guillaume.solig...@orange.com<mailto:guillaume.solig...@orange.com>
mailto:guillaume.solig...@orange.com>>
Sent: Thursday, July 29, 2021 10:34 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>;
bruno.decra...@orange.com&
Guillaume –
Thanx for the thoughtful response.
Responses inline.
From: guillaume.solig...@orange.com
Sent: Thursday, July 29, 2021 3:20 AM
To: Les Ginsberg (ginsberg) ; bruno.decra...@orange.com;
lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed
...@orange.com
Sent: Monday, July 12, 2021 1:48 AM
To: Les Ginsberg (ginsberg) ; lsr-cha...@ietf.org
Cc: lsr@ietf.org
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111
Les,
Faster flooding may be achieved without protocol extension. But if we are at
changing flooding, it would be reason
solution.
Thanx.
Les
From: Lsr On Behalf Of Tony Li
Sent: Wednesday, July 28, 2021 1:06 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org; Shraddha Hegde
Subject: Re: [Lsr] Generic metric: application-specific vs
application-independent
Les,
ASLA exists to support the advertisement
Tony –
IMO, you are asking the wrong question.
ASLA exists to support the advertisement of attributes which can be used in
application specific ways.
In any particular deployment case, a given attribute advertisement might be
used by one app, multiple apps, or all apps.
ASLA allows to
on as I do not
understand it.
Les
> -Original Message-
> From: Ron Bonica
> Sent: Monday, July 26, 2021 11:31 AM
> To: Peter Psenak (ppsenak) ; Acee Lindem (acee)
> ; Les Ginsberg (ginsberg)
> ; Shraddha Hegde ;
> gregory.mir...@ztetx.com; lsr@ietf.org
> Cc: draft-ietf-lsr
as
ASLA. I would be somewhat surprised if RSVP-TE were extended in this way, but
that is up to the marketplace to decide.
Les
From: Gyan Mishra
Sent: Friday, July 23, 2021 11:44 AM
To: Peter Psenak (ppsenak)
Cc: Acee Lindem (acee) ; Les Ginsberg (ginsberg)
; Ron Bonica ; Shraddha Hegde
not only make sense, but would add value. TE metric is an example which
is very close to Generic Metric and is supported in ASLA.
Please read his email for the complete response.
Les
From: Gyan Mishra
Sent: Friday, July 23, 2021 8:26 AM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee
isn’t the substance
of this discussion and I would much prefer that any future posts on this thread
focus on the substantive issues. We can address improving the RFC language
separately.
Les
> -Original Message-
> From: Ron Bonica
> Sent: Thursday, July 22, 2021 9:13 PM
y 22, 2021 10:28 AM
> To: Acee Lindem (acee) ; Les Ginsberg (ginsberg)
> ; Shraddha Hegde ;
> gregory.mir...@ztetx.com; Peter Psenak (ppsenak) ;
> lsr@ietf.org
> Cc: draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con
I support progression of this document.
Regarding the new registry being requested in Section 8.2, given that the
registry applies to both OSPF and IS-IS codepoints, I think it would make more
sense to place the registry under Interior Gateway Protocol (IGP) Parameters
rather than under OSPF.
sting RFCs.
Please correct the draft as requested.
Les
> -Original Message-
> From: Shraddha Hegde
> Sent: Monday, July 19, 2021 11:05 AM
> To: gregory.mir...@ztetx.com; ppsenak=40cisco@dmarc.ietf.org;
> lsr@ietf.org
> Cc: Les Ginsberg (ginsberg) ; draft-ietf-
Linda -
I think Acee's objections (which I support) make progressing your draft
unlikely - which makes resolution of your questions somewhat moot.
However, please find responses inline.
From: Linda Dunbar
Sent: Tuesday, July 13, 2021 1:02 PM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee
Draft authors -
I note that the new version has altered the advertisement of the Generic Metric
sub-TLV so that it is no longer supported in the ASLA sub-TLV.
This is in direct violation of RFC 8919/8920.
For example, https://www.rfc-editor.org/rfc/rfc8919.html#section-6.1 states:
"New
Linda –
Picking up on this comment from Acee:
“Note that routes are based on IP prefixes and not applications while the draft
uses these two interchangeably. “
As regards how to advertise the new metric, to the best of my understanding
what you want to advertise is the cost to reach an
will not have accomplished much.
However you (as WG chair) go about building an agenda, please ensure that this
happens.
Thanx.
Les
From: Lsr On Behalf Of Christian Hopps
Sent: Monday, July 12, 2021 9:53 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org; bruno.decra...@orange.com; lsr-cha
As is well known, there are two drafts in this problem space:
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
and
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/
Regarding the latter, we also have a working implementation and we also have
I support progressing this document.
Flex-algo has already been demonstrated to be useful with a number of
implementations/deployments.
Les
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Wednesday, June 16, 2021 7:01 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ;
Joel -
I have had concerns from the beginning as to whether this draft is really
needed.
As I have commented previously, the only content of any significance is Section
4 - and that only provides example settings of the management fields for this
interface type.
I question whether a draft is
e Reference RFC 8343 Section 4 as this is
clearly a copy of the Figure in that document/section.
Les
> -Original Message-
> From: Joel Halpern Direct
> Sent: Monday, June 21, 2021 8:47 AM
> To: Les Ginsberg (ginsberg) ; tom petch
> ; Harold Liu
> ; lsr@ietf.org
>
in the context that at least two
people have read it and found it inaccurate and both of us have made very
explicit points about what language is confusing.
Les
> -Original Message-
> From: Joel Halpern Direct
> Sent: Monday, June 21, 2021 8:13 AM
> To: Les Ginsberg (gin
I am in complete agreement with the points Tom has made.
AFAICT, the only new content in this draft is Section 4 - the rest is either
boilerplate or a repetition of text already present in RFC 5309 or RFC 8343.
Neither the Abstract nor the Introduction makes that clear.
The abstract actually
our
concern.
Thanx.
Les
From: Shraddha Hegde
Sent: Wednesday, June 16, 2021 10:05 PM
To: Les Ginsberg (ginsberg) ; Les Ginsberg
(ginsberg) ; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN ; Van De Velde, Gunter
(Nokia - BE/Antwerp)
Subject: RE: Proposed Errata for RFCs 8919/8920
Hi Les,
I am
- and vice versa.
Les
From: Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Wednesday, June 16, 2021 9:07 AM
To: Shraddha Hegde ; Les Ginsberg (ginsberg)
; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN
Subject: RE: Proposed Errata for RFCs 8919/8920
Another item of ambiguity is whether "wildca
how
your proposed text clarifies this confusion.
I am open to revising the proposed text - but I need more help from you to
understand the source of confusion.
Les
From: Lsr On Behalf Of Shraddha Hegde
Sent: Wednesday, June 16, 2021 7:46 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: DECR
Bruno -
Thanx for the prompt review.
I will incorporate your suggested change.
Les
From: bruno.decra...@orange.com
Sent: Tuesday, June 15, 2021 9:33 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp)
Subject: RE: Proposed Errata for RFCs 8919/8920
Gunter -
Thanx for digging into the origins of some of the ambiguity.
I have just sent proposed Errata for RFC 8919/8920 which addresses the issues
raised and better aligns the text in the two RFCs.
Please review and comment on that new thread.
For the record, Option #1 is what is specified -
Folks -
Recent discussions on the list have highlighted some unintentional ambiguity in
how ASLA advertisements are to be used. Please see
https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/
The following proposed Errata address this ambiguity and aligns language in the
Bruno -
The intent of the RFC 8919 language is to say:
1)If there are ASLA advertisements w non-zero SABM/UABM matching the
application, these MUST be used
2)If there are no matching ASLA advertisements as per #1, then ASLA
advertisements w zero length SABM/UABM (if present) MUST be used
I support adoption of this draft.
I believe that there are use cases for algorithm specific adjacency-sids -
primarily (and non-controversially) to provide algorithm specific repair paths.
As others have commented, other use cases mentioned in this draft involve
introducing significant new
h the time being spent on it. So, you have my
input. I leave it to the ADs/WG chairs/IESG review to close this issue.
Thanx for listening.
Les
> -Original Message-
> From: Alvaro Retana
> Sent: Wednesday, May 19, 2021 6:55 AM
> To: Les Ginsberg (ginsberg) ; Acee Lindem (
om: Acee Lindem (acee)
> Sent: Monday, May 17, 2021 7:03 AM
> To: Peter Psenak (ppsenak) ; John Scudder
>
> Cc: Alvaro Retana ; Les Ginsberg (ginsberg)
> ; John Scudder via Datatracker ;
> draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org;
> lsr-cha...@ietf.org;
>
Alvaro –
FWIW, I agree w John here.
There are many examples – to cite a few:
Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS
Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability
information, MT-ISN, and MT IS Neighbor Attribute TLVs)
…
Reference
; ; draft-ietf-lsr-isis-srv6-
> extensi...@ietf.org; Les Ginsberg (ginsberg) ;
> Shraddha Hegde ; lsr@ietf.org;
> cho...@chopps.org
> Subject: Re: [Lsr] Last Call:
> (IS-IS
> Extension to Support Segment Routing over IPv6 Dataplane) to Proposed
> Standard
>
> Peter:
>
Shraddha/ Xuesong -
Since Prefix Attributes sub-TLV is required for correct operation when a
Locator is leaked, would it be safe to assume that your implementations either
do not leak Locators or you advise your customers not to deploy this feature
with multiple levels?
The problem with
As has been mentioned in this thread, the need for the prefix-attributes
sub-TLV to correctly process leaked advertisements is not unique to the Locator
TLV. The reason prefix-attributes TLV was created was to address the same gap
with IP/IPv6 reachability advertisements.
And I think by now
Gurusiddesh -
From: Gurusiddesh Nidasesi
Sent: Friday, April 23, 2021 5:58 AM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; lsr@ietf.org;
spencer.giacal...@gmail.com; stef...@previdi.net; Dona Maria John
; Vikram Agrawal ;
Mahalakshmi Kumar
Subject: Re: [Lsr] Doubt regarding A bit
Gurusiddesh –
The short answer to all your questions is “yes”.
More inline.
From: Gurusiddesh Nidasesi
Sent: Thursday, April 22, 2021 10:33 PM
To: Acee Lindem (acee)
Cc: lsr@ietf.org; spencer.giacal...@gmail.com; stef...@previdi.net; Les
Ginsberg (ginsberg) ; Dona Maria John
; Vikram Agrawal
for it.
This category of flags field was never under discussion - I thought you and I
had agreed on this explicitly early on.
Les
> -Original Message-
> From: Tony Li
> Sent: Wednesday, April 21, 2021 7:47 AM
> To: Les Ginsberg (ginsberg)
> Cc: Christian Hopps ; lsr@ietf.org; l
t 20 years
will be significantly different. This, to me, argues that Tony's proposal is
better.
Anyways, I am done...thanx for listening.
Les
> -Original Message-
> From: Christian Hopps
> Sent: Wednesday, April 21, 2021 7:05 AM
> To: Les Ginsberg (ginsberg)
> Cc: lsr@ietf
Chris/Acee -
Thanx for putting this proposal together.
As I have previously stated, I prefer no registries at all for this case. But
if we are to have registries, I much prefer Tony Li's proposal:
When a potentially shared field is created, the defining document specifies the
name of a
Alvaro/Peter -
In regards to:
> ...
> > 906 12.5. Sub-Sub-TLVs for SID Sub-TLVs
> >
> > 908 This document requests a new IANA registry be created under the IS-IS
> > 909 TLV Codepoints Registry to control the assignment of sub-TLV types
> > 910 for the SID Sub-TLVs specified in this document -
closer scrutiny. Just my opinion of course…
Thanx (again) for listening.
Les
From: Tony Li On Behalf Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg)
Cc: Alvaro Retana ;
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; John Scudder
; Christian
can proceed appropriately.
Les
From: Tony Li On Behalf Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg)
Cc: Alvaro Retana ;
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; John Scudder
; Christian Hopps ; lsr-cha...@ietf.org
Subject: Re: [Lsr] When
definitions come along.
I will leave it to the WG chairs as to how to determine WG consensus. Just hope
we don’t have to write an RFC to define the WG policy on this.
Thanx.
Les
From: Tony Li On Behalf Of Tony Li
Sent: Wednesday, March 17, 2021 1:56 PM
To: Les Ginsberg (ginsberg)
Cc: Alvaro
Tony -
> -Original Message-
> From: Tony Li On Behalf Of Tony Li
> Sent: Wednesday, March 17, 2021 11:37 AM
> To: Alvaro Retana
> Cc: Les Ginsberg (ginsberg) ; draft-ietf-lsr-isis-srv6-
> extensi...@ietf.org; lsr@ietf.org; John Scudder ;
> Christian Hopps ; lsr-cha.
Alvaro -
Inline.
> -Original Message-
> From: Alvaro Retana
> Sent: Wednesday, March 17, 2021 7:04 AM
> To: Les Ginsberg (ginsberg) ; draft-ietf-lsr-isis-srv6-
> extensi...@ietf.org
> Cc: John Scudder ; lsr-cha...@ietf.org; lsr@ietf.org;
> Christian Hopps
> Subj
– they look at drafts/RFCs and only
look at registries when the document points to them.
Les
From: Robert Raszuk
Sent: Tuesday, March 16, 2021 4:46 PM
To: Les Ginsberg (ginsberg)
Cc: Alvaro Retana ; lsr@ietf.org; Christian Hopps
Subject: Re: [Lsr] When is an IANA Registry Required
Hi Les
and might even
convince me that this is a good idea.
Thanx.
Les
> -Original Message-
> From: Alvaro Retana
> Sent: Tuesday, March 16, 2021 12:39 PM
> To: Les Ginsberg (ginsberg) ; draft-ietf-lsr-isis-srv6-
> extensi...@ietf.org
> Cc: John Scudde
Folks -
This revision addresses comments from Dhruv, Alvaro, Donald, and Acee.
Thanx to all for their careful review.
Les
> -Original Message-
> From: Lsr On Behalf Of internet-dra...@ietf.org
> Sent: Wednesday, March 10, 2021 7:57 AM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
Sooo, I have been reluctant to comment on the shortcomings of this draft
because I feel there was no need for the draft to be written in the first place.
I had hoped that the authors would think about this a bit more and realize the
flaws in the proposed solution – or – as Acee suggested during
Alvaro -
Thanx for the clarification.
I will address this in the next revision.
Les
> -Original Message-
> From: Alvaro Retana
> Sent: Thursday, March 04, 2021 9:10 AM
> To: Les Ginsberg (ginsberg) ; Christian Hopps
> ; Dhruv Dhody
> Cc: TEAS WG Chairs ; lsr-...
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee)
; lsr@ietf.org
Subject: Re: Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for
Segment Routing based Virtual Transport Network” -
draft-xie-lsr-isis-sr-vtn-mt-03
Hi, Les,
Thanks for the review of this document.
As the current
From: Dhruv Dhody
Sent: Wednesday, March 03, 2021 10:34 PM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; TEAS WG Chairs ;
teas-...@ietf.org; TEAS WG (t...@ietf.org) ;
lsr-cha...@ietf.org; lsr@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis
I oppose WG adoption for this draft.
I note that the authors – following significant comments received on V0 - have
removed much of the material that was considered confusing and/or inappropriate
– notably discussion of L2 bundle link members.
I also note the draft has moved from Standards
lack of clarity in using
quotes?
Thanx.
Les
From: Alvaro Retana
Sent: Wednesday, March 03, 2021 1:09 PM
To: Les Ginsberg (ginsberg) ; Dhruv Dhody
; Christian Hopps
Cc: TEAS WG Chairs ; lsr-...@ietf.org; teas-...@ietf.org;
lsr-cha...@ietf.org; lsr@ietf.org; TEAS WG (t...@ietf.org)
S
Alvaro -
Thanx for chiming in.
Inline.
> -Original Message-
> From: Alvaro Retana
> Sent: Wednesday, March 03, 2021 12:06 PM
> To: Les Ginsberg (ginsberg) ; Christian Hopps
> ; Dhruv Dhody
> Cc: TEAS WG Chairs ; lsr@ietf.org; lsr-...@ietf.org;
> lsr-
> cha
OK
Les
> -Original Message-
> From: Lsr On Behalf Of Acee Lindem (acee)
> Sent: Wednesday, March 03, 2021 10:41 AM
> To: Donald Eastlake ; Christian Hopps
>
> Cc: teas-cha...@ietf.org; teas-...@ietf.org; t...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; lsr-...@ietf.org
>
Donald -
Thanx for your careful review and your support of the draft.
Replies inline.
> -Original Message-
> From: Lsr On Behalf Of Donald Eastlake
> Sent: Wednesday, March 03, 2021 10:32 AM
> To: Christian Hopps
> Cc: teas-cha...@ietf.org; teas-...@ietf.org; t...@ietf.org; lsr-
>
Dhruv -
Thanx for reviewing/supporting the draft.
Please see inline.
> -Original Message-
> From: Lsr On Behalf Of Dhruv Dhody
> Sent: Wednesday, March 03, 2021 2:09 AM
> To: Christian Hopps
> Cc: TEAS WG Chairs ; teas-...@ietf.org; TEAS WG
> (t...@ietf.org) ;
Alvaro -
In your review of draft-ietf-lsr-isis-srv6-extensions you requested the authors
to
"Please ask IANA to set up a registry for the Flags."
in multiple cases e.g., the flags field defined in the new SRv6 Capabilities
sub-TLV.
This isn't the first time you have made such a
Yingzhen -
Thanx for incorporating my suggestion to use the Application Identifiers
Registry created in RFC 6823 (
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#app-ids-251
) to allow sharing of application IDs between IS-IS and OSPF.
I think, however, that we
IMO there is no need for this draft to exist.
Before a need for such a draft can be established two things have to happen in
the following order:
1)There has to be WG consensus that application info such as VTN should be
advertised by the IGPs.
To date no such consensus exists and there has
Acee -
Thanx for your - as always - meticulous review. I have posted an updated
version incorporating your comments.
Have you considered adding yourself to the IDNITs check?
Les
> -Original Message-
> From: Lsr On Behalf Of Acee Lindem (acee)
> Sent: Thursday,
I am not aware of any IPR related to this draft.
Les
> -Original Message-
> From: Lsr On Behalf Of Christian Hopps
> Sent: Wednesday, February 17, 2021 7:30 AM
> To: lsr@ietf.org
> Cc: Christian Hopps ; teas-cha...@ietf.org; teas-
> a...@ietf.org; t...@ietf.org; lsr-cha...@ietf.org;
Folks -
On behalf of the draft authors I am requesting WG last call on this document.
It is a very minor and non-controversial change to allow GMPLS/TE InterAS
extensions to work in an IPv6 only network.
Summary of the changes can be found in
Support.
These additional aspects of the protocol certainly need to be included in the
model.
Les
> -Original Message-
> From: Lsr On Behalf Of Christian Hopps
> Sent: Tuesday, January 05, 2021 1:20 AM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; Christian Hopps
> Subject: [Lsr]
I support WG adoption.
This functionality has proven very useful in IS-IS. OSPF should have the same
capabilities.
Les
> -Original Message-
> From: Lsr On Behalf Of Christian Hopps
> Sent: Tuesday, January 05, 2021 1:17 AM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; Christian
Russ -
I think you have too many email addresses.
Inline.
> -Original Message-
> From: op...@riw.us
> Sent: Monday, January 04, 2021 10:01 AM
> To: Les Ginsberg (ginsberg) ; 7ri...@gmail.com;
> 'Shraddha Hegde' ; lsr@ietf.org
> Subject: RE: [Lsr] New Ve
Russ -
Happy New Year.
Responses inline.
> -Original Message-
> From: Lsr On Behalf Of 7ri...@gmail.com
> Sent: Saturday, December 19, 2020 4:49 AM
> To: 'Les Ginsberg (ginsberg)' ;
> 'Shraddha Hegde' ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification f
Zhenqiang -
In regards to:
[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I
think one new top-level TLV for ISIS is enough to advertise prefix reachability
associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID
can be used to indicate it is
Shraddha -
Thanx for the responses.
Please see inline.
From: Shraddha Hegde
Sent: Wednesday, December 02, 2020 9:30 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt
Hi Les,
Thanks for the review and comments.
Pls see
I support WG adoption.
This is another useful tool to support traffic engineering in real world
deployments.
Les
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Tuesday, December 01, 2020 1:13 PM
To: lsr
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm)
In IP
I have reviewed the draft and support progressing this document.
Les
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Monday, November 30, 2020 10:15 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse
Metric" -
Draft authors -
I note that as the draft has evolved over the years a number of mechanisms have
been removed (revised adjacency formation and auto tier detection) and the
draft now focuses exclusively on flooding optimizations.
The draft now also references the recent work done in
FYI –
This has been approved by the DEs and IANA has updated the registry.
Les
From: Lsr On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, November 18, 2020 1:45 PM
To: Acee Lindem (acee) ; Huaimo Chen
; Christian Hopps ; Hannes
Gredler
Cc: lsr@ietf.org; Alvaro Retana
Subject: Re
Request noted.
Chris/Hannes/myself will discuss and get back to you.
Les
From: Acee Lindem (acee)
Sent: Wednesday, November 18, 2020 12:21 PM
To: Huaimo Chen ; Christian Hopps
; Hannes Gredler ; Les Ginsberg
(ginsberg)
Cc: lsr@ietf.org; Alvaro Retana
Subject: Re: Early Allocation
that I am – like others – supportive of this work – but
I think WG adoption at this stage (in ANY WG) is premature.
Les
From: Huzhibo
Sent: Friday, November 13, 2020 7:20 PM
To: Les Ginsberg (ginsberg) ; Ketan Talaulikar (ketant)
; Susan Hares ; 'Jeff Tantsura'
; Stephane Litkowski
The points which Ketan has made regarding the use of MTU advertisements defined
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL
specific MTU-probe/MTU-ack procedures defined in
This simple extension to RFC 5316 is analogous to the extension to RFC 4971
defined in RFC 7981. As Acee indicated, this is needed to support operation in
IPv6 only networks.
I support WG adoption as a co-author.
I would appreciate WG support so we can complete this necessary extension.
Les
I am not aware of any relevant undisclosed IPR associated with the bis draft.
Les
From: Acee Lindem (acee)
Sent: Friday, October 23, 2020 7:50 AM
To: draft-chen-lsr-isis-rfc5316...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS
TE" -
it at that.
Les
From: Eric Gray
Sent: Tuesday, October 20, 2020 6:39 PM
To: Les Ginsberg (ginsberg) ; rtg-...@ietf.org;
lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo
Les,
Thanks for your helpful feedback on my
to consensus on your next
step.
Les
> -Original Message-
> From: Aijun Wang
> Sent: Monday, October 19, 2020 12:06 AM
> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'
>
> Cc: 'John E Drake' ; lsr-cha...@ietf.org; lsr@ietf.org;
> 'Jeff Tantsura' ; draft
o do this.
I cannot support the document moving forward with the content in the Appendices
included.
Les
> -Original Message-
> From: Lsr On Behalf Of Aijun Wang
> Sent: Sunday, October 18, 2020 7:08 PM
> To: 'Christian Hopps'
> Cc: 'John E Drake' ; lsr-cha...@ietf.org
Eric –
I will let the draft authors respond to the bulk of your comments. But in
regards to your question/comment:
“I assume (but do not actually know) that a similar situation exists for the
new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS presumably has
well defined handling
> -Original Message-
> From: Lsr On Behalf Of Aijun Wang
> Sent: Friday, October 16, 2020 1:48 AM
> To: Les Ginsberg (ginsberg)
> Cc: John E Drake ; Christian Hopps
> ; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura
> ; draft-ietf-lsr-ospf-prefix-origin
John E Drake'
>
> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les Ginsberg
> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; draft-ietf-
> lsr-ospf-prefix-origina...@ietf.org
> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>
> Hi, Les, John and Jeff:
I support moving this document forward.
Similar functionality in IS-IS has proved useful.
I would however like to repeat comments I made earlier in the review of this
document.
The content of the Appendices should be removed.
The Appendices define and discuss deriving topology information from
I support WG adoption of this draft.
OSPF needs functionality equivalent to that defined for IS-IS in RFC 8668.
Les
> -Original Message-
> From: Lsr On Behalf Of Christian Hopps
> Sent: Friday, October 02, 2020 5:03 AM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; Christian Hopps ;
Ron -
Interesting proposal.
A few mundane - but I think still important - comments.
New IS-IS TLVs
There is no need to have two TLVs for each address-family - one for MTID #0 and
one for all non-zero MTIDs. One TLV/AF will suffice.
The reason we have separate TLVs today
In support of what Tony has said, I think any comparison between what RIFT is
doing and what is proposed in this draft is inappropriate.
RIFT is able to determine what destinations exist in the network but are not
reachable via a certain subset of the topology – and then generate negative
it before defining it. It is
always possible that when the use case arises we will find that there are some
other issues which have been overlooked which might alter how this would be
advertised.
Les
From: Tony Li On Behalf Of tony...@tony.li
Sent: Thursday, August 27, 2020 8:19 AM
To: Les
Tony –
Inline.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 8:56 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Hi Les,
[Les:] Any one of the IERs can be elected Area Leader, therefore all
Tony –
Inline.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 5:40 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Les,
As per the draft:
Area Proxy TLV is advertised by IERs in their L2 LSP
not claim that you need a new SID
type when you don’t.
Les
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 4:02 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Hi Les,
You have chosen to assign
Tony -
You have chosen to assign a prefix as the "Area Destination". This is fine with
me. But having done that, forwarding should be based on the existing mechanisms
for advertising a prefix and the associated prefix SID.
By doing that you avoid a number of problems:
* Duplicate SID
reas isn't
helping you.
Les
From: Huaimo Chen
Sent: Tuesday, August 18, 2020 3:18 PM
To: Les Ginsberg (ginsberg) ; Les Ginsberg (ginsberg)
; Acee Lindem (acee)
; lsr@ietf.org
Subject: Re: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" -
draft-chen-isis-ttz-11.txt
Hi Les,
401 - 500 of 834 matches
Mail list logo