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

;, <ospf-cha...@ietf.org>, <lsr@ietf.org> Cc: <rtg-...@ietf.org>, <rtg-...@ietf.org> Subject: Re: RtgDir Early review: draft-ietf-ospf-segment-routing-msd.txt Resent-From: <alias-boun...@ietf.org> Resent-To: Jeff Tantsura <jefftant.i...@gmail.com>, <uma.ch

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,

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)" <ket...@cisco.com> Date: Thursday, May 10, 2018 at 08:05 To: Jeff Tantsura <jefftant.i...@gmail.com>, "Acee Lind

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

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.

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

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

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

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

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

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

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

with 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 discu

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

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,

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

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

ll never support multiple address familes). Thanks, Acee On 4/6/18, 5:29 PM, "Jeff Tantsura" <jefftant.i...@gmail.com> wrote: Acee, What about ospfv2 vs ospfv3 specifics? We keep it as before - eg “ospf” covers either or

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:

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

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

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

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

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

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

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

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

  1   2   >