Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

Hey Acee, Yes/support, valuable addition. Thanks, Jeff > On Feb 19, 2024, at 14:25, Acee Lindem wrote: > > > This starts the Working Group Last call for > draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm > enhancements described in the document have been implemented.

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

sr-dynamic-floodingWhile I am a BGP person I feel pretty strongly that BGP is not a best fit for the vast majority of DC fabrics in use today. Cheers,RobertOn Sun, Nov 26, 2023 at 10:49 PM Jeff Tantsura <jefftant.i...@gmail.com> wrote:I agree with all aforementioned comments. Wrt

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

I agree with all aforementioned comments. Wrt AI/ML networking - if a controller is used, what is required is link state exposure northbound and not link state protocol in the fabric. (I could argue for RIFT though ;-)) I’d urge you to take a look at Meta’s deployment in their ML clusters

Re: [Lsr] New Version Notification for draft-liu-lsr-mpls-inspection-msd-01.txt

+1 Tony > On Aug 29, 2023, at 7:18 AM, Tony Li wrote: > > > Hi Eduard, > > I know several different products that use different silicon on different > line cards, ending up with different capabilities on different interfaces. > > This is more of a hardware issue than a software one. > >

Re: [Lsr] WG Last Call for draft-ietf-lsr-ospfv3-extended-lsa-yang

Yes/support Cheers, Jeff > On Aug 18, 2023, at 17:27, Christian Hopps wrote: > >  > This begins a 2 week WG Last Call, ending Sep 1, 2023, for: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ > > Authors, > > Please indicate to the list, your knowledge of any

Re: [Lsr] LSR WG Adoption Call for "IGP Flexible Algorithms Reverse Affinity Constraint" - draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-01

Yes/support Cheers,JeffOn Mar 17, 2023, at 21:23, Gyan Mishra wrote:Support adoption ThanksGyanOn Fri, Mar 10, 2023 at 8:09 AM Acee Lindem wrote: The begins the LSR WG adoption call for "IGP Flexible Algorithms Reverse Affinity Constraint" -

Re: [Lsr] WG Last Call for draft-ietf-lsr-rfc8920bis-00

Chris, I am not aware of any IPR related to this draft and as a co-author support its progress. Cheers,Jeff From: Christian HoppsSent: Wednesday, December 7, 2022 6:07 AMTo: lsr@ietf.orgCc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org; draft-ietf-lsr-rfc8920...@ietf.orgSubject: [Lsr]

Re: [Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

Yes/support Cheers,JeffOn Nov 23, 2022, at 07:50, Tony Przygienda wrote:as co-author support adoption. draft is a derivation of well-known MANET techniques used before successfully. The twists improving it (balancing of flooding across downstream nodes in addition to reduction) has been used in

Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo

+1 Cheers,Jeff From: Les Ginsberg (ginsberg)Sent: Friday, August 12, 2022 9:05 AMTo: 龚立艳; lsr@ietf.org; shraddhaSubject: Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo Liyan – You agree that there is an existing way to prune links from the IGP SPF.Still, you insist that an

Re: [Lsr] WG adoption call for draft-ppsenak-lsr-rfc8920bis-02

Chris, I’m not aware of any IPR that hasn’t been disclosed and support the progress (as co-author). Cheers, Jeff > On Aug 8, 2022, at 05:57, John E Drake > wrote: > > Support > > Yours Irrespectively, > > John > > > Juniper Business Use Only > >> -Original Message- >> From:

Re: [Lsr] [Idr] IGP Monitoring Protocol

. Would be great to  do some study around existing solutions, see what worked, what didn’t’ (and why)   Cheers,Jeff From: Susan HaresSent: Saturday, July 9, 2022 1:44 PMTo: Jeff Tantsura; Robert RaszukCc: Acee Lindem (acee); lsr; i...@ietf.org; g...@ietf.org g...@ietf.orgSubject: RE: [Idr] [Lsr] IGP

Re: [Lsr] [Idr] IGP Monitoring Protocol

Speaking as RTGWG chair: Robert - I don’t think we’d have enough time to accommodate a good discussion during IETF114 (we got only 1 slot), however would be happy to provide a platform for an interim. The topic is important and personally (being a very large BGP-LS user) I’d like to see it

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

I’d support publishing it as Experimental. If there’s a consensus that an additional presentation in RTGWG would be useful, Yingzhen and I would consider it. Cheers, Jeff > On Jun 13, 2022, at 12:17, Acee Lindem (acee) > wrote: > > Hi Tony, Les, Tom, > > When the WG was focused on this

Re: [Lsr] WG adoption call for draft-fox-lsr-ospf-terminology-01

Yes/support Cheers, Jeff > On Apr 25, 2022, at 06:51, Christian Hopps wrote: > > Hi Folks, > > This begins a 2 week WG Adoption Call for the following draft: > > https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/ > > Please indicate your support or objections by May 9th,

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Yes/support Cheers, Jeff > On Jan 27, 2022, at 09:08, Acee Lindem (acee) > wrote: > >  > LSR WG, > > This begins a two week last call for the subject draft. Please indicate your > support or objection on this list prior to 12:00 AM UTC on February 11th, > 20222. Also, review comments

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

I’d very much support applicability draft work! Cheers, Jeff > On Jan 3, 2022, at 08:05, Tony Przygienda wrote: > >  > AFAIS this is a "operational and deployment" or "applicability" draft and not > part of a protocol specification. But yes, such a draft would have value > AFAIS, especially

Re: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

Acee, I support the adoption, and would like to thank the authors for the great work. At this point in time, it feels like experimental track is more suitable. Cheers, Jeff > > >> On Nov 22, 2021, at 6:06 AM, Acee Lindem (acee) >> wrote: >> >> We indicated the intent to adopt of >>

Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

Yes/support Cheers, Jeff > On Nov 22, 2021, at 14:47, Acee Lindem (acee) > wrote: > >  > This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05. Please > post your support or objection to this list by 12:00 AM UTC on Dec 14th , > 2021. Also please post your comments on the

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

> On Oct 13, 2021, at 12:04, Peter Psenak wrote: > > Hi Jeff, > >> On 13/10/2021 19:28, Jeff Tantsura wrote: >> Number of BGP peers isn’t representative here, classical deployments would >> have a number of RR’s to circumvent full mesh. What counts is the tota

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Number of BGP peers isn’t representative here, classical deployments would have a number of RR’s to circumvent full mesh. What counts is the total number of PEs (next-hops) that originate the prefix that is locally imported (needs to be tracked). For further optimization, only multihomed

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

we are going in rounds, +1 Les! Cheers, Jeff >> On Aug 18, 2021, at 1:20 PM, Les Ginsberg (ginsberg) >> wrote: >> >> Ron - >> >> Indeed – it is long past the time when we should be focusing on the “big >> picture”. >> I think Acee has stated it as succinctly as anyone – let me repeat for

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

+1 Les. Cheers, Jeff > > >> On 13/07/2021 17:39, Les Ginsberg (ginsberg) wrote: >> 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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Yes/support Regards, Jeff > On May 12, 2021, at 15:14, Acee Lindem (acee) > wrote: > >  > Esteemed Members of the LSR WG, > > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/ > > Please

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

+1 Cheers, Jeff On May 7, 2021, 9:53 AM -0700, Les Ginsberg (ginsberg) , wrote: > 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

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

Yes/support Regards, Jeff > On May 2, 2021, at 01:47, Christian Hopps wrote: > >  > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/ > > Please indicate your support or objection by May 16th, 2021.

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

In ol’ good RSVP-TE days we already used “severity/relevance indicator” to decide whether changes in link  attributes (BW/etc) are significant enough and should be propagated in into TED and trigger re-optimization/rerouting, this is no different,  define your threshold for a trigger. Note -

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

Yes/support Cheers, Jeff On Feb 17, 2021, 7:30 AM -0800, Christian Hopps , wrote: > Hi LSR and TEAS, > > This begins a joint WG last call for: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/ > > Please discuss any issues on the LSR mailing list. The WGLC will end March 3, >

Re: [Lsr] WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03

support adoption. Cheers, Jeff On Jan 5, 2021, 1:20 AM -0800, Christian Hopps , wrote: > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/ > > Please indicate your support or objection by January 19th,

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-admin-tags-07

yes/support Cheers, Jeff On Jan 5, 2021, 1:17 AM -0800, Christian Hopps , wrote: > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-admin-tags/ > > Please indicate your support or objection by January 19th, 2021. > > Authors,

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

especially when the path is calculated distributedly? The valid topology must consist of a set of connected routers sharing a common Calc-Type, then loop-free calculation is done accordingly Best Regards, Zhenqiang Li li_zhenqi...@hotmail.com From: Jeff Tantsura Date: 2020-12-04 09:18 To: Tony

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

gt; So that is a huge much needed gap as not all operators on the public core > have MPLS or SR and would like an alternative. > > This could be used in both core and data center space as well IP based > infrastructure. > > RSVP TE and SR have their niche and now IP flex alg

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

; Aijun Wang > China Telecom > > From: lsr-boun...@ietf.org On Behalf Of Jeff Tantsura > Sent: Friday, December 4, 2020 9:18 AM > To: Tony Li ; Robert Raszuk > Cc: lsr ; Acee Lindem (acee) > Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms >

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Anything else than IGP metric based SPT is considered TE. Looking holistically - topology virtualization (or similar) could have been a better name. Cheers, Jeff On Dec 3, 2020, 4:25 PM -0800, Robert Raszuk , wrote: > Hi Tony, > > The moment I hit "Send" I knew that this response may be coming

Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

yes/support Cheers, Jeff On Nov 30, 2020, 10:15 AM -0800, Acee Lindem (acee) , wrote: > As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric > augmentation is ready for publication. This begins a two week last call for > the subject draft. Please indicate your support or

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Yes/support - very useful work! Cheers, Jeff On Dec 1, 2020, 1:13 PM -0800, Acee Lindem (acee) , wrote: > This IP Flex Algorithm draft generated quite a bit of discussion on use cases > and deployment prior to IETF 109 and there was generally support for WG > adoption. This begins a two week

Re: [Lsr] Prefix Unreachable Announcement Use Cases

as suggested by Robert. It seems there is some interest here although > I’m not convinced the IGP is the right place to solve this problem. > > Thanks, > Acee > > From: Lsr on behalf of Gyan Mishra > > Date: Tuesday, November 17, 2020 at 4:02 AM > To: Robert Raszuk

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

t if it is in a good > enough state for adoption  > > Thanks, > Ketan > > From: Susan Hares > Sent: 16 November 2020 11:40 > To: 'Jeff Tantsura' ; Les Ginsberg (ginsberg) > > Cc: Ketan Talaulikar (ketant) ; Stephane Litkowski > (slitkows) ; i...@ietf.org;

Re: [Lsr] Prefix Unreachable Announcement Use Cases

+1 with Robert. So you expect the following RIB state after PUA has been advertised: 10.0.0.1 - drop 10/24 - forward Unless there’s a recursively discarded next-hop (ala RTBH ) - how do you envision it? Regards, Jeff > On Nov 16, 2020, at 00:25, Robert Raszuk wrote: > >  >> I was not

Re: [Lsr] Prefix Unreachable Announcement Use Cases

P to flood unreachable only for the purpose > of control plane (namely BGP paths invalidation). > > Cheers, > R. > > > On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura > > wrote: > > > As RIFT chair - I’d like to respond to Robert’ comment -  the example is > > &

Re: [Lsr] Prefix Unreachable Announcement Use Cases

As RIFT chair - I’d like to respond to Robert’ comment - the example is rather unfortunate, in RIFT disaggregation is conditional and well contained within its context, it doesn’t affect overall scalability. Regards, Jeff > On Nov 15, 2020, at 08:44, Robert Raszuk wrote: > >  > Hi Aijun,

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

in all the > protocols of interest in some future version of the draft. > At that point we could then have a far more meaningful WG adoption call. > >Les > > > From: Idr On Behalf Of Ketan Talaulikar (ketant) > Sent: Friday, November 13, 2020 1:35 AM > To: Susan

Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

For OSPFv3 use E-LSAs (RFC8362) Cheers, Jeff On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar , wrote: > Acee, > > Thank you very much for suggesting using the Prefix TLV for carry the Running > Status and environment of 5G Edge Computing servers. > > In a nutshell, the  >

Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

Yes/support Regards, Jeff > On Oct 23, 2020, at 07:43, Acee Lindem (acee) > wrote: > >  > This is simple BIS update to RFC 5316 is required to support IS-IS Inter-AS > TE in IPv6 only networks. The authors have asked for WG adoption. > > This begins a two week LSR Working Group Adoption

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

+1 Regards, Jeff > On Oct 15, 2020, at 11:33, John E Drake > wrote: > > Hi, > > I agree with Les. This is a simple protocol extension for a specific purpose > and there is no reason to include speculation about its use for other > purposes, particularly when it is inherently not suited

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Yes/support Regards, Jeff > On Oct 14, 2020, at 23:16, Christian Hopps wrote: > > This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ > > The following IPR has been filed

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

I’m with Acee here, the presence of a passive interface in a topology is in no way unambiguously signaling domain boundaries. You could “hack around” though, but that would defeat the purpose of an IETF document. Keeping it to OSPFv2 (other protocols have similar ways of doing that), I’d say,

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

gt; > Gyan > > > On Sun, Oct 11, 2020 at 1:38 PM Jeff Tantsura > > wrote: > > > Thanks Ron, indeed!  Autocorrect works in mysterious ways  ;-) > > > > > > Regards, > > > Jeff > > > > > > > On Oc

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

iness Use Only > > -Original Message- > From: Jeff Tantsura > Sent: Saturday, October 10, 2020 3:14 PM > To: Ron Bonica > Cc: Dongjie (Jimmy) ; Peter Psenak ; > Yingzhen Qu ; Gyan Mishra ; > lsr@ietf.org > Subject: Re: [Lsr] FW: New Version Notification for

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Hi Jimmie, > > Inline. > >Ron > > > Juniper Business Use Only > > -Original Message- > From: Dongjie (Jimmy) > Sent: Friday, October 9, 2020 11:06 PM > To: Peter Psenak ; Ron Bonica ; > Yingzhen Qu ; Gyan Mishra > Cc: lsr@ie

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Hi Yingzhen, Yes, that’s the case.  The most important property of an algo computed path is that is has to be consecutive, as either SID or IP address associated with a particular topology is only known within that topology. Looking specifically at Ron’s draft (MPLS could be more complex due to

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

yes/support Cheers, Jeff On Oct 2, 2020, 5:03 AM -0700, Christian Hopps , wrote: > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ > > Please indicate your support or objection by October 16, 2020. > > Authors,

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Hi Ron, the readers would benefit if the draft would state that in order for the technology to work properly, there must be a contiguous set of connected routers that support it between the S/D, since lookup (route installed in context of the algo it is associated with) is done per hop.

Re: [Lsr] [spring] draft-tgraf-ipfix-mpls-sr-label-type

In general, I agree with what Ketan said, what’s important - it is the value that is being used in forwarding, even if multiple control plane entries exist, think about IGP migrations, or LDP to SR, where more than 1 protocol could be distributing the labels/SIDs. I’m not sure the FIB is the

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

+1 to “Application-Specific” Cheers, Jeff On Jun 18, 2020, 2:09 PM -0700, Les Ginsberg (ginsberg) , wrote: > John – > > Yes – I like “Application-Specific” better. This matches the term we use > throughout the documents. > > Thanx. > >     Les > > From: John E Drake > Sent: Thursday, June 18,

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

yes/support the adoption Cheers, Jeff On Jun 11, 2020, 12:04 PM -0700, Jordan Head , wrote: > Support. > > The draft identifies and addresses the problem, and quite cleanly I might add. > > Jordan Head > > On 6/10/20, 3:29 PM, "Lsr on behalf of Christian Hopps" on behalf of cho...@chopps.org>

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

Thanks Chris/Tony, I wish we’d have more of this kind of discussions on the list, discussing pro/cons of the solutions proposed! Have a great weekend! Regards, Jeff > On Jun 6, 2020, at 14:15, Tony Li wrote: > >  > > Hi Chris, > > Thank you for your thoughtful comments. > > >> A

Re: [Lsr] Call for WG adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

yes/support Cheers, Jeff On Jun 4, 2020, 11:05 AM -0700, Tony Przygienda , wrote: > I would like to officially call out for adoption of > https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 as WG > document > > At this point in time flood reflection has been implemented and

Re: [Lsr] draft-ietf-lsr-flex-algo

Weibin, One could have an algo with MSD/ERLD as optimizations constrains, would be quite similar to colored links. Note - ERLD has implemented node capabilities only, so all links on a node will have to be pruned. The tradeoffs are - having centralized controller with global view computing a

Re: [Lsr] Flooding across a network

Robert, Assuming C and E provide access to the same set of destinations, that are closer of further away from C and E. B (which is fast), after it notifies A that it can’t reach C directly will cause A to send traffic to D. D - dependent on total cost would start happily sending some traffic

Re: [Lsr] FW: New Version Notification for draft-ginsberg-lsr-isis-flooding-scale-02.txt

Very well written draft, 02 has significantly improved readability and addressed some missing details. Would support adoption. Cheers, Jeff On Apr 17, 2020, 12:55 PM -0700, Les Ginsberg (ginsberg) , wrote: > Folks - > > A new version of this draft has been uploaded. > > Comments welcomed. > >

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

+1 Please do not take my comments about link vs node capabilities, as support for the solution, they are semantical. Cheers, Jeff On Apr 6, 2020, 8:58 AM -0700, Tony Li , wrote: > > > > This discussion is interesting, but please do not ignore the considerable > > feedback from multiple folks

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

Very valid comment - When working on MSD - we had exactly same considerations, since path computation could use different links over different line cards that may have different capabilities, hence we decided to have per link granularity, details in RFC 8491 Cheers, Jeff On Apr 4, 2020, 7:33

Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

Same here Regards, Jeff > On Apr 3, 2020, at 03:38, Lou Berger wrote: > >  > Fwiw I used the link in the agenda without issue. I did the same for RAW > last week. Also, as host of a different wg interim right before lsr, I > didn't have to do anything to let people in to the session -

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

gt; Aijun Wang > China Telecom > >>> On Apr 3, 2020, at 08:20, Jeff Tantsura wrote: >>> >> Robert, >> >> We are deviating ;-) >> >> There’s no feedback loop from telemetry producers back to the TE headend. >> The telemetry, either end2en

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Robert, We are deviating ;-) There’s no feedback loop from telemetry producers back to the TE headend. The telemetry, either end2end or postcards is sent to a collector that has the context of the data and normalizes it so it can be consumed by an external system, being centralized or

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

here it is strange that joining virtual LSR meeting > is not for everyone. I was waiting and tried three times today for host > approval to join which was not granted. > > > On Thu, Apr 2, 2020 at 11:00 PM Jeff Tantsura > > wrote: > > > Robert, > > > >

Re: [Lsr] Methods to label the passive interfaces within ISIS

Agree with Acee and Les Cheers, Jeff On Jan 13, 2020, 9:29 AM -0800, Les Ginsberg (ginsberg) , wrote: > I agree with Acee that there is no requirement to identify an interface as > passive – or (as suggested in this thread) as loopback or tunnel or stub… > > Before debating the best encoding

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

yes/support Happy New Year all! Cheers, Jeff On Jan 2, 2020, 11:07 AM -0800, Christian Hopps , wrote: > This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for > draft-ietf-lsr-isis-invalid-tlv. > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > Tony P (other

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-reverse-metric

I support the adoption, finally OSPF would catch up with IS-IS ;-) Cheers, Jeff On Dec 13, 2019, 3:28 AM -0800, Christian Hopps , wrote: > Hi LSR WG and Draft Authors, > > This begins a 2 week WG adoption poll for the following draft: > >

Re: [Lsr] "YANG Module for IS-IS Reverse Metric" - draft-hopps-lsr-yang-isis-reverse-metric-02

Yes/support Regards, Jeff > On Nov 25, 2019, at 21:27, Acee Lindem (acee) wrote: > >  > This begins a two week LSR Working Group adoption call for the subject > document. > > https://datatracker.ietf.org/doc/draft-hopps-lsr-yang-isis-reverse-metric/ > > Please indicate your support or

Re: [Lsr] WG Adoption poll for draft-acee-lsr-ospf-yang-augmentation-v1-01

yes/support, missing pieces that need to be added Cheers, Jeff On Oct 2, 2019, 2:28 PM -0700, Christian Hopps , wrote: > Hi Folks, > > This begins a 2 week WG adoption poll for the following: > > https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-yang-augmentation-v1/ > > Please send any

Re: [Lsr] WG Adoption Poll for draft-acee-lsr-ospfv3-extended-lsa-yang-06

yes/support Cheers, Jeff On Oct 2, 2019, 2:27 PM -0700, Christian Hopps , wrote: > Hi Folks, > > This begins a 2 week WG adoption poll for the following: > > https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/ > > Please send any comments to the list by Wednesday Oct 16th,

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

Yes/support Cheers, Jeff > > > From: Lsr On Behalf Of Acee Lindem (acee) > Sent: Friday, August 30, 2019 12:44 PM > To: lsr@ietf.org > Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-isis-mpls-...@ietf.org > Subject: [Lsr] Working Group Last Call for "Signaling Entropy Label > Capability

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

Yes/support Cheers, Jeff > > > From: Lsr On Behalf Of Acee Lindem (acee) > Sent: Friday, August 30, 2019 12:42 PM > To: lsr@ietf.org > Cc: m...@ietf.org; lsr-...@ietf.org; draft-ietf-ospf-mpls-...@ietf.org > Subject: [Lsr] Working Group Last Call for "Signaling Entropy Label > Capability

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

Acee, I agree with your statement. We (MSD DE’s) have OKed temporary allocation. I believe WGLC would be in place. Regards, Jeff > On Aug 28, 2019, at 14:30, Acee Lindem (acee) wrote: > > Hi Uma, > > The draft states that an explicit ERLD is required. I’m not a forwarding ASIC > expert so

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Support Regards, Jeff > On Aug 13, 2019, at 13:18, Jeff Tantsura wrote: > > +1 > > Cheers, > Jeff >> On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk , wrote: >> > lsr-isis-extended-hierarchy >> >> Sounds great ! >> >> __

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

+1 Cheers, Jeff On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk , wrote: > > lsr-isis-extended-hierarchy > >  Sounds great ! > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Regd covering BGP-LS extensions for IGP ELC drafts

+1 Ketan Cheers, Jeff On Jul 25, 2019, 6:43 PM -0400, Ketan Talaulikar (ketant) , wrote: > Hi Acee/All, > > During the LSR WG meeting on Monday, we talked about covering the BGP-LS > aspects of the following two IGP drafts in those drafts instead of requiring > a separate document: > >

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Sue, I support progress of this draft, it addresses real problem. On Redback side of things we have implemented this around 2013, logic (proprietary) kept in BFD indeed, so +1 Ketan. I’d document it as an informal feature, that is recommended (same for YANG) Cheers, Jeff On Jul 25, 2019, 4:27

Re: [Lsr] WG Adoption Call: draft-ginsberg-lsr-isis-invalid-tlv

Yes/support Cheers, Jeff > On Jun 12, 2019, at 15:04, Christian Hopps wrote: > > This begins a 2 week WG adoption call for draft-ginsberg-lsr-isis-invalid-tlv. > > https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv/ > > Please express your support or non-support. > >

Re: [Lsr] Adjacency SID and Passive Interface

+1 Regards, Jeff > On May 10, 2019, at 05:22, Ketan Talaulikar (ketant) wrote: > > +1 > > Hi Oliver, > > Technically Adj-SID refers to an IGP adjacency between two nodes as per > RFC8402 semantics. I don't think a passive (stub) link falls under that > category. It would be better to

Re: [Lsr] IPR Poll for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

Acee, Prem is not with BF anymore, I’ll contact him OOB. I believe Hani is in the similar situation. Will ping him too. Regards, Jeff > On May 9, 2019, at 07:42, Acee Lindem (acee) wrote: > > This poll also applies to the ten contributors… > > From: Acee Lindem > Date: Thursday, May 9,

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

Olivier, +1 Peter. There’s has been significant amount of discussions on the topic some time ago, mostly with Chris Bowers. Please take a look, should provide more context. Regards, Jeff > On Apr 12, 2019, at 15:27, Peter Psenak wrote: > > Hi Oliver, > > There are two major purposes served

Re: [Lsr] IPR Poll for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

Acee, I’m not aware of any IPR that applies to the draft. Regards, Jeff > On Apr 11, 2019, at 18:09, Acee Lindem (acee) wrote: > > Authors, Contributors, > > Are you aware of any IPR that applies to > draft-ietf-ospf-te-link-attr-reuse-07? > > If so, has this IPR been disclosed in

Re: [Lsr] Working Group Last Call for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt (Corrected Author Alias)

Yes/support Regards, Jeff > On Apr 10, 2019, at 23:24, Acee Lindem (acee) wrote: > > LSR Working Group, > > This begins a two week WG last call for the subject document. Please enter > your support or objection to the document before 12:00 AM (EDT) on Wednesday, > April 25th, 2019. >

Re: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01

yes/support Cheers, Jeff On Mar 19, 2019, 7:30 AM -0700, Acee Lindem (acee) , wrote: > This begins a 3 WG last call for the subject document. The extra week is > since the IETF is next week. Please enter your support or objection to the > document before 12:00 AM (EDT) on Wednesday, April 3rd,

Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding

+1 Les. In general - in ECMP cases LFA is meaningless (any ECMP member is loop-free per definition) so commonly used technology is fast-rehash, where in case of failure all the flows that would use the link in question are rehashed over other links in the bundle and that is done in HW.

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

Yes/support Cheers, Jeff On Feb 11, 2019, 2:47 AM -0800, Christian Hopps , wrote: > > Hi Folks, > > We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02. > > The aim of this document is to describe the problem space and standardize a > way to signal dynamic flooding

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

In favor! Regards, Jeff > On Feb 1, 2019, at 08:02, Les Ginsberg (ginsberg) wrote: > > I am in favor of this proposal. > > Les > >> -Original Message- >> From: Lsr On Behalf Of Christian Hopps >> Sent: Friday, February 01, 2019 4:26 AM >> To: lsr@ietf.org >> Cc: cho...@chopps.org

Re: [Lsr] WG Adoption Call for "IS-IS Routing for Spine-Leaf Topology" - draft-shen-isis-spine-leaf-ext-07

Yes/support Regards, Jeff > On Dec 1, 2018, at 16:54, Acee Lindem (acee) wrote: > > This begins a two-week WG adoption call for the subject draft. As anyone who > has been following the topic knows, there are a lot of proposal in this > space. However, as WG co-chair, I believe this simple

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-isis-rfc5306bis-00 - Restart Signaling for IS-IS

Yes/support Regards, Jeff > On Nov 19, 2018, at 14:22, Acee Lindem (acee) wrote: > > The begins a Working Group Last Call for the subject document. Please post > for review comments and/or support/objection to this document before 12:00 AM > UTC on Tuesday, December 4th, 2018. > > Other

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

le config consistently > on every hop. Br. > > To me DSCP can be used to map packets to different routing context, > different plane or can be used as a parameter in flex-algorithm. > > Thx, > R. > > > > > > On Fri, Nov 16, 2018 at 8:19 AM Jeff Tantsura >

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

+1 Rob I have seen number of MBH networks using DSCP to change forwarding - AKA PBR.. The question is really - what is here to standardize? RSVP-TE use cases mentioned by Rob (CBTS/PBTS in IOS realm) are classical examples of Policy Based Routing and as such are subject to implementation

Re: [Lsr] WG Adoption Poll for IGP extension for PCEP security capability support in the PCE discovery - draft-wu-lsr-pce-discovery-security-support-00

Yes/support On Tue, Nov 13, 2018 at 16:53 Qin Wu wrote: > I support this work as one of coauthors. > > > > -Qin > > *发件人:* Lsr [mailto:lsr-boun...@ietf.org] *代表 *Acee Lindem (acee) > *发送时间:* 2018年11月14日 6:11 > *收件人:* lsr@ietf.org > *主题:* [Lsr] WG Adoption Poll for IGP extension for PCEP security

Re: [Lsr] OSPF Routing with Cross-Address Family Traffic Engineering Tunnels - draft-ietf-ospf-xaf-te-04.txt

I support publication of this draft, simple and straightforward. Cheers, Jeff On Oct 23, 2018, 12:49 PM -0700, Acee Lindem (acee) , wrote: > Speaking as a WG member: > >   I support publication of this draft. All of my comments are already in this > revision. > > Thanks, > Acee > > From: Lsr on

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Gents, I’m 100% with Les here, going into platform/asic specifics within this document would inevitably create ambiguity. Cheers, Jeff On Oct 2, 2018, 11:20 AM -0700, Les Ginsberg (ginsberg) , wrote: > Bruno – > > Trimming the thread… > > [Les2:] Label imposition is meant to cover both the

Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

Gents, Thanks for the great review! Both drafts are on the Telechat tomorrow, would be great to come to the agreement, so ospf draft could be updated before tomorrow’s call. Regards, Jeff > On Sep 26, 2018, at 13:21, Les Ginsberg (ginsberg) wrote: > > Julien - > > Thanx for the additional

Re: [Lsr] RtgDir review: draft-ietf-ospf-segment-routing-msd

Hi Tal, Many thanks for your comments. Updated draft has been published for your review. Cheers, Jeff From: Tal Mizrahi Date: Monday, August 20, 2018 at 23:45 To: , , , Cc: , "Yemin (Amy)" Subject: RtgDir review: draft-ietf-ospf-segment-routing-msd Resent-From: Resen

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

a document. And to be completely honest, the requirements are pretty straightforward for anyone that is familiar with the protocols' operation. my 2c, Peter On 22/08/18 18:42 , Jeff Tantsura wrote: > +1 Tony > > We could start with a document, similar to dc-routi

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

9 To: "Les Ginsberg (ginsberg)" Cc: Jeff Tantsura , Tony Li , "lsr@ietf.org" , "Acee Lindem (acee)" Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward I do think to solve all the data centers (massive or small) requirement, this discu

  1   2   >