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, 2022

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 pro

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 prog

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] 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: Lsr

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 extensi

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 R

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] WG

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" - draft-ppsenak-lsr-igp-flex-algo-r

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] 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. > > Di

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 (pu

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 AI/ML n

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.

[Lsr] Re: WG Last Call for draft-ietf-lsr-ospf-admin-tags

Yes/support > On Jun 17, 2024, at 11:41, Christian Hopps wrote: > > > This begins a 2 week WG Last Call, ending Monday July 1st, 2024, for: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags > > Authors, > > Please indicate to the list, your knowledge of any IPR related to t

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 rig

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. Cheers

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, pl

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] 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

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 &g

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

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

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, us

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 https://datatracker.ietf.or

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 fo

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 P

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  > https://datatracker.ietf.org

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] 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] Prefix Unreachable Announcement Use Cases

e IGP 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

+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 brin

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

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

Re: [Lsr] Prefix Unreachable Announcement Use Cases

e 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 Ra

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 WG

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 o

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 as

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

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

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 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, p

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, 2021

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, > 2

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 - fle

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] 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 to

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 indica

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 8919/892

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] "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 prefixe

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 total >

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 draf

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 >> draft-d

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] 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 are

Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis-rfc7810bis-00.txt

+1 I’d think the below would work: lsr for #2 lsr-ospf(ospfv3) / lsr-isis for #1 Cheers, Jeff From: Lsr on behalf of "Acee Lindem (acee)" Date: Wednesday, April 4, 2018 at 13:27 To: Tony Li , "Les Ginsberg (ginsberg)" Cc: "lsr@ietf.org" Subject: Re: [Lsr] FW: New Version Notificat

Re: [Lsr] LSR WG IPR Query for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

Hi Acee, I’m aware of the IPR and it has been disclosed in compliance with IETF IPR rules. https://datatracker.ietf.org/ipr/3040/ Thanks! Cheers, Jeff From: Lsr on behalf of "Acee Lindem (acee)" Date: Thursday, April 5, 2018 at 18:22 To: "draft-ietf-ospf-segment-routing-msd...@ietf.

Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis-rfc7810bis-00.txt

+1 Regards, Jeff > On Apr 6, 2018, at 12:25, Acee Lindem (acee) wrote: > > I'm fine with the proposed naming conventions for new drafts. Formally: > >-lsr-ospf- - OSPF Specific drafts >-lsr-isis- - IS-IS Specific drafts >-lsr- - Drafts covering both > protocol

Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis-rfc7810bis-00.txt

Acee, What about ospfv2 vs ospfv3 specifics? We keep it as before - eg “ospf” covers either or ospfv2, “ospfv3” is for ospfv3 only? Regards, Jeff > On Apr 6, 2018, at 12:25, Acee Lindem (acee) wrote: > > I'm fine with the proposed naming conventions for new drafts. Formally: > >-lsr-os

Re: [Lsr] FW: New Version Notification for draft-ginsberg-isis-rfc7810bis-00.txt

ltiple address familes). Thanks, Acee On 4/6/18, 5:29 PM, "Jeff Tantsura" wrote: Acee, What about ospfv2 vs ospfv3 specifics? We keep it as before - eg “ospf” covers either or ospfv2, “ospfv3” is for ospfv3 only?

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

Support! Regards, Jeff > 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 implementations. Given the simplicity of this > document, I’d like to have an abbreviated WG adoption call of one wee

Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

Hi Ketan Thank you for your review, I’ll address the comments during this week. Thanks! Cheers, Jeff From: Lsr on behalf of "Ketan Talaulikar (ketant)" Date: Thursday, April 12, 2018 at 05:04 To: "Acee Lindem (acee)" , "lsr@ietf.org" Subject: Re: [Lsr] LSR WG Last Call for "Signaling

Re: [Lsr] LSR Working Group Secretary

Couldn’t agree more! Yingzhen is great at everything she does, thanks! (Don’t forget us, at RTGWG ;-)) Regards, Jeff > On Apr 23, 2018, at 10:49, Les Ginsberg (ginsberg) wrote: > > Bravo! > Now LSR is a world class WG. > > Thanx to Yingzhen for taking on this additional responsibility. > >

Re: [Lsr] WG Last Call for draft-ietf-isis-segment-routing-extensions-16

Support as co-author Regards, Jeff > On Apr 23, 2018, at 07:02, Christian Hopps wrote: > > Hi Folks, > > We are starting a new 2 week WG last call on > > https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/ > > as there have (*) been some changes to the document since

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

Hi Tal, Many thanks for your review! Coming week I’ll be working to address them as well as on earlier comments provided by Ketan. Should be done by the end of the week. Regards, Jeff > On Apr 29, 2018, at 04:08, Tal Mizrahi wrote: > > + LSR mailing list. > > Cheers, > Tal. > >> On Sun, Ap

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

Resent-From: Resent-To: Jeff Tantsura , , , Resent-Date: Sun, 29 Apr 2018 04:08:12 -0700 (PDT) + LSR mailing list. Cheers, Tal. On Sun, Apr 29, 2018 at 2:04 PM, Tal Mizrahi wrote: Hello I have been selected to do a routing directorate “early” review of this draft. ​https

Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

Hi Ketan, New version (11) should address all your comments, please check and let me know. ISIS version is being aligned as we speak. Many thanks! Cheers, Jeff From: Lsr on behalf of "Ketan Talaulikar (ketant)" Date: Thursday, April 12, 2018 at 05:04 To: "Acee Lindem (acee)" , "ls

Re: [Lsr] LSR WG Last Call for "Signaling MSD (Maximum SID Depth) using OSPF" - draft-ietf-ospf-segment-routing-msd-10.txt

Hi Ketan, Many thanks for you thoughtful reviews, working with the authors to improve the draft! Cheers, Jeff From: "Ketan Talaulikar (ketant)" Date: Thursday, May 10, 2018 at 08:05 To: Jeff Tantsura , "Acee Lindem (acee)" , "lsr@ietf.org" Subject:

Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt

M >>> To: i-d-annou...@ietf.org >>> Cc: lsr@ietf.org >>> Subject: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts

Re: [Lsr] IPR Poll for "OSPFv3 Extensions for Segment Routing" Prior to WG Last Call

Acee, I’m no aware of any IPR that applies to this draft. Regards, Jeff > On May 22, 2018, at 16:43, Acee Lindem (acee) wrote: > > Are you aware of any IPR that applies to > draft-ietf-ospf-ospfv3-segment-routing-extensions-12.txt? > > If so, has this IPR been disclosed in compliance with IE

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

Yes/support Regards, Jeff > On May 23, 2018, at 17:28, Christian Hopps wrote: > > Hi Folks, > > We're starting a 2 week WG Last Call on > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/ > > Please raise any objections or comments before Jun 6th, 2018. > > Thanks, > Chr

Re: [Lsr] LSR Working Group Last Call for "OSPFv3 Extensions for Segment Routing" - draft-ietf-ospf-ospfv3-segment-routing-extensions-13

Support as co-author Regards, Jeff > On May 23, 2018, at 17:03, Acee Lindem (acee) wrote: > > This begins an LSR WG last call for the subject draft. Please send your > comments to this list prior to 12:00 AM GMT, June 7th, 2018. > Thanks, > Acee and Chris > > _

Re: [Lsr] IGP TE Metric Extensions

Muthu, LSR would be a more suitable list to post to, CCed. Regards, Jeff > On May 30, 2018, at 18:06, Muthu Arul Mozhi Perumal > wrote: > > Muthu ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

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

Uma, I’m not aware of any IPR that has not been previously disclosed. Cheers, Jeff From: Lsr on behalf of Uma Chunduri Date: Monday, June 11, 2018 at 12:18 To: Subject: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up) Dear All, Are you awar

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

Uma, Wrt number of authors, if I recall correctly (I don’t have pointers to the discussion anymore), given the lengths and involvement of the authors currently on the front page, as an exception - both ospf and isis sr drafts would keep the initial number of authors. Thanks, Jeff > On Jun 11,

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

Chris, I'm not aware of any IPR outside of that already disclosed. Thanks, Jeff Cheers, Jeff On 6/13/18, 06:37, "Christian Hopps" wrote: [Sigh, I quoted the wrong email and mixed things up -- thanks Bruno!] Authors, The original WGLC requested the authors indicate if th

Re: [Lsr] [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

Gunter, I have nothing to add to Les' comments, 100% agree. Cheers, Jeff On 6/13/18, 08:42, "Idr on behalf of Les Ginsberg (ginsberg)" wrote: Gunter - I strongly support Option #2 and strongly support Ketan's recommendation that an MSD sub-type be used to advertise ERLD. Thi

Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

Robin, Pretty much same comment as Acee - I'm not clear as to why... Protocol YANG models developed in the last years clearly provide much better and more scalable approach to what has been proposed in the draft, since we are talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg

Re: [Lsr] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi, Please see inline (MSD section). Hope this clarifies, thanks! Cheers, Jeff [jeff] both IGP drafts have identical description of the BMI-MSD: “Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a node is capable of imposing, including all service/tra

Re: [Lsr] [OPSAWG] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

We would like to define the NMP based on the usecases. That is, a specific > set of parameters exported by NMP can satisfy the purpose of a specific > usecase. Thus the protocol can be deployed incrementally. > > > Best Regards, > Robin > > > > -Original Messa

Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-13.txt

e Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : Signaling MSD (Maximum SID Depth) using IS-IS Authors : Jeff Tantsura Uma Chunduri

Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

Not going to repeat all the comments made before, +1 Regards, Jeff > On Jul 24, 2018, at 23:08, Tony Przygienda wrote: > > pretty obvious +1 here > > --- tony > >> On Tue, Jul 24, 2018 at 3:41 AM Rob Shakir wrote: >> +1 to Peter. We should not define fragile solutions within the IETF. >>

Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

+1 Nothing really to add to Les’ comments Regards, Jeff > On Aug 3, 2018, at 09:32, Les Ginsberg (ginsberg) > wrote: > > Bruno – > > I appreciate why you suggest per-prefix signaling for ELC, but I would prefer > that we not employ that model. > > ELC is clearly a node capability – signa

Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

Stephane, Leaving protocol semantics aside – do you see a real use cases for multi-area/multi-protocol scenarios? For all practical reasons (and to repeat Gunter’s comments) – this info is really of value for the controller, from distribution prospective, source->BGP-LS speaker, deployment

Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-msd-13

rg" , Christian Hopps Subject: RE: AD Review of draft-ietf-isis-segment-routing-msd-13 Resent-From: Resent-To: Jeff Tantsura , , , Resent-Date: Wed, 15 Aug 2018 15:51:43 -0700 (PDT) Alvaro – A very thorough review – thanx. Jeff has the pen – but I think he is on holiday at the mo

Re: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang

Acee, The draft is in good shape, support. Cheers, Jeff From: Lsr on behalf of "Acee Lindem (acee)" Date: Friday, August 17, 2018 at 13:09 To: "lsr@ietf.org" Subject: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang This begins an LSR WG last call for the subject draft. Ple

Re: [Lsr] AD Review of draft-ietf-ospf-segment-routing-msd-15

:53 To: Cc: , , "Acee Lindem (acee)" Subject: AD Review of draft-ietf-ospf-segment-routing-msd-15 Resent-From: Resent-To: Jeff Tantsura , , , Resent-Date: Wed, 15 Aug 2018 13:53:45 -0700 (PDT) Dear authors: I just finished reading this document. I have several comments an

Re: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang

Tom, Many thanks, great comments (as always)! Regards, Jeff > On Aug 22, 2018, at 08:41, tom petch wrote: > > Original Message - > From: "Jeff Tantsura" > Sent: Friday, August 17, 2018 9:14 PM > > Acee, > > The draft is in good shape, suppo

Re: [Lsr] LSR WG Adoption Poll for "Restart Signaling for IS-IS" - draft-ginsberg-isis-rfc5306bis-01

Acee, I support the adoption and quick progress of this, clear and useful document.. Regards, Jeff > On Aug 22, 2018, at 06:42, Acee Lindem (acee) > wrote: > > This draft has been presented several times and I believe there is general > agreement that IS-IS graceful restart signaling enhance

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

+1 Tony We could start with a document, similar to dc-routing requirements one we did in RTGWG before chartering RIFT and LSVR. Would help to disambiguate requirements from claims and have apple to apple comparison. Doing it on github was a good experience. Regards, Jeff > On Aug 22, 2018, at

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

other work and be a wg/design team effort. Hope this clarifies. Cheers, Jeff From: "Les Ginsberg (ginsberg)" Date: Wednesday, August 22, 2018 at 13:10 To: Tony Przygienda Cc: Jeff Tantsura , Tony Li , "lsr@ietf.org" , "Acee Lindem (acee)" Subject: RE

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 discussio

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

by such 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 docu

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] New Version Notification for draft-wu-lsr-pce-discovery-security-support-00.txt

+1 Having actual key in the protocol - similar issues as with BGP(see recent BGP discussion with Linda), would be a severe security risk. Regards, Jeff > On Aug 25, 2018, at 10:41, Acee Lindem (acee) > wrote: > > Hi Qin, > > I believe it is a significant security exposure to include the ac

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 c

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 SWAP

Re: [Lsr] FW: New Version Notification for draft-ginsberg-lsr-isis-invalid-tlv-00.txt

Great stuff, long time due! Cheers, Jeff On Oct 19, 2018, 12:23 PM -0700, Les Ginsberg (ginsberg) , wrote: > Folks - > > This new draft discusses IS-IS protocol behaviors related to handling TLVs > that are either: > > o Not recognized/supported by an implementation > o Present in a PDU where th

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] 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] 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 detail

  1   2   >