Re: [Lsr] draft-ietf-isis-segment-routing-extensions-16 - Shepherd review comments

Les, Thanks for your quick response and changes in the document. Please find my further response below* [Uma]:* -- Uma C. On Mon, Jun 11, 2018 at 10:00 PM, Les Ginsberg (ginsberg) < ginsb...@cisco.com> wrote: > Uma – > > > > Thanx for the prompt review. > > > > 2. Section 2.1 > > > > a. "The

Re: [Lsr] IPR Poll draft-ietf-isis-segment-routing-msd.

I am not aware of any other IPRs on this draft other than what's been already disclosed. BR, -- Uma C. On Wed, Jun 13, 2018 at 6:37 AM, Christian Hopps wrote: > [Sigh, I quoted the wrong email and mixed things up -- thanks Bruno!] > > Authors, > > The original WGLC requested the authors

[Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up)

Dear All, Are you aware of any IPR that applies to https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16 ? Sending this email as suggested by LSR chairs - as this was not noticed during/around WGLC. === If so, has this IPR been disclosed in compliance with IETF IPR rules

Re: [Lsr] Flex Algorithms Drafts

> > > these are being renamed in the next update to: > > Flex-Algorithm - Single octet value between 128 and 255 inclusive > > > IGP Alg. Type - Single octet. Value between 0 and 127 inclusive, that > identifies IGP algorithm type used to compute paths for the Flex-Algoritm. > Values are defined

Re: [Lsr] Flex Algorithms Drafts

Hi Peter, Thanks for your response. See my questions below - On Tue, Apr 17, 2018 at 2:31 AM, Peter Psenak <ppse...@cisco.com> wrote: > Hi Uma, > > please see inline: > > > On 17/04/18 00:14 , Uma Chunduri wrote: > >> Dear All, >> I am n

Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

Hi Peter, -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Tuesday, July 17, 2018 9:34 AM To: Uma Chunduri ; Ketan Talaulikar (ketant) ; lsr@ietf.org Cc: spr...@ietf.org Subject: Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

Re: [Lsr] Concerns with draft-chunduri-lsr-isis-preferred-path-routing

Hi Ketan, In-line [Uma]: -- Uma C. -Original Message- From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Tuesday, July 17, 2018 7:13 AM To: Uma Chunduri ; lsr@ietf.org Cc: spr...@ietf.org Subject: Concerns with draft-chunduri-lsr-isis-preferred-path-routing Hi Uma, I

[Lsr] Fwd: IPR Poll follow up on draft-ietf-isis-segment-routing-extensions-16

ard Crabbe < edward.cra...@gmail.com>, ro...@google.com, milojevici...@gmail.com, slu...@cisco.com, lsr-cha...@ietf.org Not aware of any IPR. On Sat, 23 Jun 2018 at 00:16, Uma Chunduri wrote: > > Dear All, > > All authors have responded to the IPR Poll. > > Still couple of contri

Re: [Lsr] Flex Algorithms Drafts

Dear All, I am neutral to combining the content of OSPF and IS-IS into a single draft. However, I have 2 questions on this draft. 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

Hi Peter, > I have the feeling that the dependency of the "flooding topology" on the > flooded data is going to bring more complexity, than the selection of the > distributed algorithm to be used, if we ever need to support more then one. I see

Re: [Lsr] LSR WG Adoption call for "IS-IS Traffic Engineering (TE) Metric Extensions" - draft-ginsberg-lsr-isis-rfc7810bis-00

Thanks for clearly documenting the changes being made in a separate section. Support. -- Uma C. On Apr 9, 2018, at 21:20, Acee Lindem (acee) > wrote: This draft simply fixes a problem in RFC 7810 that resulted in an incompatibility issue with

Re: [Lsr] IS-IS over TCP

>BTW, there is another reason for our proposal. With the incoming drafts about flooding-topology-reduction, there is a new problem. >All these proposals have situations where non-flooding adjacencies suddenly change to flooding adjacencies. When that happens, the LSDBs need to

Re: [Lsr] Comments on draft-chunduri-lsr-isis-mt-deployment-cons-01

Les, Thanks for your comments. > If we were to proceed with this draft at all, I therefore think we should limit the scope to merely explaining what the requirements for correct operation are using the various modes. Agree and this aspect is baked-in along with some common pitfalls. It

Re: [Lsr] AD Review of draft-ietf-isis-reverse-metric-11

Hi Naiming & Co-authors Thanks for excellent work. Though, I reviewed the early versions of this draft could not follow all latest discussions/updates. But just want to chime-in on part of the text posted here and the subsequent AD’s comment. In-line [Uma]: -- Uma C. From: Lsr

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

A quick comment below – Cheers & have a great weekend! -- Uma C. From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Jeff Tantsura Sent: Friday, November 16, 2018 12:15 AM To: Robert Raszuk Cc: t...@cs.fau.de; Les Ginsberg (ginsberg) ; r...@rob.sh; tony1ath...@gmail.com; lsr@ietf.org

Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Les, Few more comments for your updated version. in-line [Uma2]: On Wed, May 29, 2019 at 10:09 PM Les Ginsberg (ginsberg) wrote: Uma – > > Hopefully we are making progress this time. > [Uma2]: Indeed! Thx! > Replies inline. Look for *[Les2:] * > > *From:* Uma

Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Les, Replies in-line [Uma1]: On Tue, May 28, 2019 at 6:01 PM Les Ginsberg (ginsberg) wrote: Uma - > > > > Newly added Section 2.2.3 a says this: > > * The "remaining time" transmitted according to (b)* > *below MUST reflect the actual time after which the adjacency will* > *

Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Hi Acee, On Wed, May 29, 2019 at 7:06 AM Acee Lindem (acee) wrote: > Hi Les, Uma, > > > > Excuse the top-post but Outlook doesn’t do well with inline response for > messages such as this one. AFAIK, no implementation defaulted to aborting > graceful restart due to any topology change as

Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

On Mon, Jun 3, 2019 at 12:06 AM Les Ginsberg (ginsberg) wrote: Uma – > > V2 of the draft has been published addressing your comments. > > Les, Saw the updates and it addresses more than what I asked for (oh yes, other than topology change prescription). Looking good. Ship it! -- Uma C.

[Lsr] draft-ietf-lsr-isis-rfc5306bis-01

As asked by chairs I was trying to write the shepherd report on this doc. Have few quick questions on this work: 1. Observation: The new text added in 2.2.3 (PR and PA bits) is almost similar to section 2.2.1 (RR and RA bits) Now is there any relation of the timer here with T3 (which would

[Lsr] draft-ietf-isis-mpls-elc-07

Can anybody tell what was the conclusion (if any) in previous discussions in various WGs on why the readable label depth in an LSR has to be entropy label specific ? IOW can we just modify this as "readable label depth" as opposed to "entropy readable label depth" ? This would allow any other

Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

>Because the intra-area link topology is not exposed across areas or to other >protocols. Agreed Acee. But just looking this again then: 1. Not really clear why ELC is required in Section 4, when it’s confirmed from Stephane’s email (Sept 4th 2019) ERLD covers both reading + doing and

Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

Support. One question to authors: On E bit in section 4: The motivation seems to extend this in Prefix attributes is for inter-area consideration and advertised per every local host prefix (link) . Is there any specific reason why link MSD is not

Re: [Lsr] draft-ietf-isis-mpls-elc-07

clear in this document. It would be useful to specify the same. -- Uma C. From: Les Ginsberg (ginsberg) Sent: Wednesday, August 28, 2019 1:59 PM To: Acee Lindem (acee) ; Uma Chunduri ; lsr@ietf.org Subject: RE: [Lsr] draft-ietf-isis-mpls-elc-07 Point taken… Les From: Acee Lindem (acee) ma

[Lsr] Fwd: New Version Notification for draft-chunduri-lsr-isis-mt-deployment-cons-03.txt

Dear LSR WG, Any comments, suggestions or feedback is welcome. -- Uma C. -- Forwarded message - From: Date: Sun, May 17, 2020 at 9:16 PM Subject: New Version Notification for draft-chunduri-lsr-isis-mt-deployment-cons-03.txt To: Uma Chunduri , Jeff Tantsura < jefftan

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Support. -- Uma C. On Tue, Aug 18, 2020 at 7:17 AM Acee Lindem (acee) wrote: > > > Based on the discussions in the last meeting and on the mailing list > regarding draft-chen-isis-ttz-11, the chairs feel that there are enough > differences with draft-ietf-lsr-isis-area-proxy-03 and in the

Re: [Lsr] Request WG adoption of TTZ

Acee, In-line .. On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee) wrote: > Speaking as WG member… > > > > See inline. > > > > *From: *Lsr on behalf of Uma Chunduri < > umac.i...@gmail.com> > *Date: *Wednesday, July 15, 2020 at 12:52 PM > *To: *

Re: [Lsr] Request WG adoption of TTZ

Dear Chris, On Sat, Jul 11, 2020 at 4:44 AM Christian Hopps wrote: > > > > On Jul 10, 2020, at 7:07 PM, Uma Chunduri wrote: > > > > I would support the IS-IS TTZ solution for WG adoption. > > > > Of course, obviously not with OSPF encodings or c

Re: [Lsr] Request WG adoption of TTZ

On Wed, Jul 15, 2020 at 5:22 AM Henk Smit wrote: > Huaimo Chen wrote on 2020-07-14 06:09: > > > 2). IS-IS TTZ abstracts a zone to a single node. A zone is any target > > block or piece of an IS-IS area, which is to be abstracted. This seems > > more flexible and convenient to users. > > I don't

Re: [Lsr] Request WG adoption of TTZ

I would support the IS-IS TTZ solution for WG adoption. Of course, obviously not with OSPF encodings or concepts only relevant to OSPF (thx for the updated version). Thanks for the good work which was started way back on TTZs with OSPF protocol first (RFC 8099). I will send my specific

[Lsr] LSR meeting comment on draft-acee-lsr-ospf-transport-instance

Dear Authors, Just want to quickly clarify my comment today on this draft. We know there was a significant discussion many years ago when similar work was done during RFC 6822 (ISIS-MI) and RFC 6823 (GenInfo). The usefulness of this is evident with the more recent publication