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,
: Tuesday, August 18, 2020 2:33 PM
To: Les Ginsberg (ginsberg) ; Acee Lindem
(acee) ; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" -
draft-chen-isis-ttz-11.txt
Hi Les,
> I see no need for "abstraction at arbitrary boundaries"
I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.
IS-IS already has smooth transition capability for merging/splitting areas.
Given both of the points above, I see no value in “smooth transition to/from
zone abstraction”.
If these are the principal distinguishing
Tony –
I am not “fighting”.
I just found your interpretation very hard to follow.
Moving on…
Les
From: Tony Li On Behalf Of tony...@tony.li
Sent: Tuesday, August 18, 2020 12:33 PM
To: Les Ginsberg (ginsberg)
Cc: Robert Raszuk ; Christian Hopps ;
draft-ietf-lsr-flex-algo@ietf.org
in/Max
Unidirectional Link Delay (34) and be done.
That's all.
Cheers,
R.
On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg)
mailto:40cisco@dmarc.ietf.org>> wrote:
Tony –
As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why you
are confused – nor why you got
Tony –
As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why you
are confused – nor why you got misdirected to code point 33.
RFC 8570 (and its predecessor RFC 7810) define:
34 Min/Max Unidirectional Link Delay
This sub-TLV contains two values:
“Min Delay: This
, 2020 11:46 PM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Bruno Decraene
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Hi Les,
1)Invent a new type of SID which is associated with an area.
In this case some variation of encodings defined in V2 of the draft
: Tony Li
Sent: Thursday, August 06, 2020 2:42 PM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Bruno Decraene
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Les,
Not sure why this needs to be explained.
Because we are not communicating well. We are each making
would not like to go down that path…
Les
From: Tony Li
Sent: Thursday, August 06, 2020 9:32 AM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Bruno Decraene
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Les,
There then remains the question as to whether
Tony -
From: Tony Li
Sent: Wednesday, August 05, 2020 4:26 PM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Bruno Decraene
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Les,
This would make the Area Prefix mandatory for Area Proxy, which is not desired.
We
Tony -
From: Tony Li
Sent: Wednesday, August 05, 2020 1:08 PM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Bruno Decraene
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Les,
a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a router-id
today
Acee -
From: Acee Lindem (acee)
Sent: Wednesday, August 05, 2020 12:31 PM
To: Tony Li ; Bruno Decraene
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Hi Tony, Bruno, Les,
From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of To
Bruno -
Please see inline.
From: Lsr On Behalf Of bruno.decra...@orange.com
Sent: Tuesday, August 04, 2020 5:45 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02
Hi,
I may be missing something but the SR Binding SID TLV extension is not clear
to me.
1. It does not
10:47 AM
To: Les Ginsberg (ginsberg)
Cc: bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-ietf-lsr-isis-area-proxy-02.txt
Hi Les,
Well I am talking about IP routable identifier which I can place on the front
of the packet and which
Robert –
Both OSPF and IS-IS have area identifiers which are advertised.
Why would we need to invent another identifier for an area?
Les
From: Robert Raszuk
Sent: Monday, August 03, 2020 10:31 AM
To: Les Ginsberg (ginsberg)
Cc: bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
Bruno –
Inline.
From: bruno.decra...@orange.com
Sent: Monday, August 03, 2020 8:52 AM
To: Les Ginsberg (ginsberg) ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for
draft-ietf-lsr-isis-area-proxy-02.txt
Les,
From: Les Ginsberg (ginsberg) [mailto:ginsb
Bruno –
The concept of “Area SID” – at least to me – is “please forward to any node in
the Area advertising the Area SID”.
You, however, seem to be asking for either:
a)The node originating the Proxy LSP to advertise a Node SID for a loopback
address on that node
OR
b)The node originating
Bruno -
Regarding the A-flag...
It may not matter much whichever way we decide - but the A-flag was invented
because at the time (prior to RFC 7794) there was no way to determine from
looking at a prefix reachability advertisement whether it was originated by the
advertising node or had been
Bruno –
One of the reasons to use the Binding TLV to advertise the Area SID was that it
has been suggested that other use cases for Area SID – unrelated to Area Proxy
– may come along.
Therefore tying the advertisement to an Area Proxy TLV seems not the best
option if we want to allow for
This update addresses review comments from:
Murray Kucherawy
Roman Danyliw
Benjamin Kaduk
Rob Wilton
Les
> -Original Message-
> From: Lsr On Behalf Of internet-dra...@ietf.org
> Sent: Sunday, July 26, 2020 6:04 PM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D
in
other ways.
Please reread the thread:
https://mailarchive.ietf.org/arch/browse/lsr/?gbt=1=5GdFCy7zg8eCIGvQZpmAbOtrTjQ
Les
From: Lizhenbin
Sent: Friday, July 17, 2020 6:12 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Cc: wangyali
Subject: 答复: New Version Notification for
draft-wang
401 - 500 of 814 matches
Mail list logo
