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

m: Lsr <lsr-boun...@ietf.org> On Behalf Of Christian Hopps Sent: Monday, April 23, 2018 7:03 AM To: lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org Subject: [Lsr] WG Last Call for draft-ietf-isis-segment-routing-extensions-16 Hi Folks, We are starting a new 2 week

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

On 15/05/18 10:54 , Christian Hopps wrote: > > Hi Les, > > I was going over the 2 SR-MSD documents (IS-IS and OSPF) just wondering > how viable it would be and if we should combine them. > > In any case doing the diff highlighted

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

Les Ginsberg (ginsberg) writes: Chris - Issue: Under both the Node and Link sub-tlv's the MSD type (1?) is not actually mentioned, only the "MSD value", if one was pedantic it would mean that regardless of the type the value was always the same, certainly not what is

Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

>> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee) >> Sent: Friday, May 18, 2018 7:29 AM >> To: Christian Hopps <cho...@chopps.org> >> Cc: lsr@ietf.org >> Subject: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs >> >> Hi Chris, >

Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

ument that shared semantic in one place? How about an option 2c 2c: Leave the encodings the way they are, and use a common registry to define the type/value semantics. Thanks, Chris. > Les > > >> -Original Message- >> From: Christian Hopps <cho...@chopps.org>

Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

> Thanks, > Acee > > On 5/20/18, 9:21 AM, "Peter Psenak (ppsenak)" <ppse...@cisco.com> wrote: > >Chris, > >On 20/05/18 01:47 , Christian Hopps wrote: >> How about an option 2c >> >> 2c: Leave the encodings the way they are,

Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

or… > > If we cannot agree on this then we will never agree on anything. > > “types” at any level are protocol specific and should be managed on protocol > specific registries. > >Les > > > > From: Christian Hopps <cho...@chopps.org> > Sent:

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

Hi Les, I was going over the 2 SR-MSD documents (IS-IS and OSPF) just wondering how viable it would be and if we should combine them. In any case doing the diff highlighted a couple issues in the IS-IS version. Issue: Under both the Node and Link sub-tlv's the MSD type (1?) is not actually

[Lsr] Publication has been requested for draft-ietf-isis-segment-routing-msd-12

Christian Hopps has requested publication of draft-ietf-isis-segment-routing-msd-12 as Proposed Standard on behalf of the LSR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd

[Lsr] IPR poll for draft-ietf-isis-reverse-metric-10

Hi Authors, Can you please respond (including the mailing list) indicating if you are aware of any IPR relating to draft-ietf-isis-reverse-metric? Thanks, Chris. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

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

[Sigh, I quoted the wrong email and mixed things up -- thanks Bruno!] Authors, The original WGLC requested the authors indicate if they were aware of any additional IPR. This seems to have gotten lost in a bunch of comments that followed. Can each author reply to this email (and the list)

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

if they are aware of any *new* IPR on this document. Currently declared related IPR: https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-isis-segment-routing-msd Thanks, Chris. Christian Hopps writes: Hi Folks, We are starting a new 2 week WG last call on https://datatracker.ietf.org

[Lsr] Call for agenda topics for LSR @ IETF-101 (a.k.a. IS-IS and OSPF :)

Hi Folks, The newly forming LSR (link-state-routing) WG will be meeting on Wednesday March 21, 2018 from 9:30 to 12:00. Please send us (lsr-cha...@ietf.org) any requests for presentation slots. Currently we have 1 slot request: - https://datatracker.ietf.org/doc/draft-li-dynamic-flooding/

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

tony...@tony.li writes: so it's party like it's 1999, seems the peer group leader election gets rediscovered ;-) Interesting old new problems, interesting old new attack vectors like https://ieeexplore.ieee.org/document/822780/ No argument

[Lsr] Publication has been requested for draft-ietf-isis-reverse-metric-11

Christian Hopps has requested publication of draft-ietf-isis-reverse-metric-11 as Proposed Standard on behalf of the LSR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/ ___ Lsr

Re: [Lsr] Request slot for LSR@101 - draft-eckert-teas-bier-te-framework

Toerless Eckert writes: Thanks, Acee - too bad. Very much a fan of creation of LSR. Sad that it meant moving from two underused WG meetings to one WG meeting that does not have enough time for new work. Reminds me of TSVWG. *sigh* Well now that's not really fair, is it?

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

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 our last WG last call last year. Here's the diff.

Re: [Lsr] IPR Disclosure Eric Kenneth Rescorla's Statement about IPR related to draft-ietf-isis-reverse-metric and draft-shen-isis-spine-leaf-ext belonging to Chemtron Research LLC

The IPR disclosure referenced 2 drafts, reverse metric and spine leaf and a patent. Is there any more specific information on how this patent might have relevance to these drafts in particular? Thanks, Chris. > On Dec 3, 2018, at 5:11 PM, Alvaro Retana wrote: > > Dear lsr WG: > > The filing

Re: [Lsr] When to augment LSR base YANG modules...

n return? Thanks, Chris. > > Thanks, > Yingzhen > > From: Lsr on behalf of Susan Hares > Date: Sunday, March 31, 2019 at 7:15 AM > To: 'Rob Shakir' , "'Acee Lindem (acee)'" > Cc: "lsr@ietf.org" , "tony...@tony.li" , > 'Christian Hopps' > S

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

+1 Thanks, Chris. > On Apr 2, 2019, at 13:25, tony...@tony.li wrote: > > > I am in complete agreement with both Les’s extensive analysis and opinion. > ;-) > > Tony > > >> On Apr 2, 2019, at 8:37 AM, Les Ginsberg (ginsberg) >> wrote: >> >> In reply to my own post, here is my opinion

[Lsr] When to augment LSR base YANG modules...

The base YANG modules for IS-IS and OSPF both include operational state to describe TLV data. During the discussion about OSPFv3's version of this data, I brought up the issue of when and how the base modules should be augmented to add new TLV types to the model, suggesting it be done inline

Re: [Lsr] "unknown TLVs" in YANG data models

> On Mar 31, 2019, at 6:00 PM, Acee Lindem (acee) wrote: > > Hi Chris, > > On 3/31/19, 4:24 PM, "Lsr on behalf of Christian Hopps" > wrote: > >So this came up during the second session at IETF104. Our base YANG data > models have "baked&quo

Re: [Lsr] When to augment LSR base YANG modules...

So to have something to look at while we discuss this I wrote a bare-bones module document for IS-IS reverse metrics: https://tools.ietf.org/html/draft-hopps-lsr-yang-isis-reverse-metric-00 If you look at the meat of that document and then imagine including it as an appendix or whatever

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

Let's use new email threads for suggested changes. One thread per suggested change/problem to keep things easier to follow. Thanks, Chris. signature.asc Description: Message signed with OpenPGP ___ Lsr mailing list Lsr@ietf.org

[Lsr] Configuration of LSR routers in WRT dynamic flooding

Huaimo wrote: > > Tony wrote: > > > >There is no need for a backup leader. If the area leader is partitioned > >from the topology, then > > leader election is repeated, resulting in a new leader. Again, no > > configuration is required. > > The above does not talk about topology split, but

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

Of Christian Hopps Sent: 11 February 2019 16:15 To: lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org Subject: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll. Hi Folks, We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02

Re: [Lsr] IS-IS lite (an aside)..

FWIW, this use of IS-IS was not adopted by homenet, which is why we now have babel wg. Thanks, Chris. Acee Lindem (acee) writes: On 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" wrote: tony...@tony.li writes: >Robert Raszuk writes: >> >&

Re: [Lsr] IS-IS lite (an aside)..

le them long-term you problably know by now what the real answer is I pursuit ;-) --- tony On Fri, Mar 8, 2019 at 5:36 AM Christian Hopps wrote: FWIW, this use of IS-IS was not adopted by homenet, which is why we now have babel wg. Thanks, Chris. Acee Lindem (acee) writes: > On 3/8/19, 7:2

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

-lsr-flooding-reduction-distributed-mode. Best Regards. Aijun Wang Network R and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, China. -邮件原件- 发件人: Christian Hopps [mailto:cho...@chopps.org] 发送时间: 2019年2月11日 18:45 收件人: lsr@ietf.org 抄送: lsr

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

they get defined in the future, i.e., a way to signal which one is in use. Thanks, Chris. > > I hope you could clarify the above issues firstly for the adoption. > > > Thanks & Regards, > Zhenbin (Robin) > > > > > ___

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

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 information. It does not standardize any specific algorithm for flooding topology creation.

[Lsr] Flooding Reduction Draft Redux

We've had the authors of the individual conflicting drafts take a shot at merging their work. This has failed. Here is the full history (which I also summarized during IETF103 as well). I will send a second email discussing this. - Jan 2, 2018 Publication: draft-li-dynamic-flooding and

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

us problem with this path forward? Thanks, Chris & Acee. LSR Chairs. Christian Hopps writes: We've had the authors of the individual conflicting drafts take a shot at merging their work. This has failed. Here is the full history (which I also summarized during IETF103 as well). I will

Re: [Lsr] Flooding Reduction Draft Redux

Huaimo Chen writes: Hi Everyone, My comments are inline below with prefix [HC]. Best Regards, - IETF 101 (Mar 2018) - Video: https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS - Minutes:

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

* of multiple author documents, we're not hurrying at all, it's time to move forward. Thanks, Chris. Aijun Wang China Telecom 在 2019年2月1日，20:25，Christian Hopps 写道： Summary of where we are at with dynamic flooding reduction: - We have a well written original work that came first and described

[Lsr] IS-IS lite (an aside)..

tony...@tony.li writes: Robert Raszuk writes: See TORs are one case .. but there are ideas to run dynamic protocols to the hosts too. I have heard there was even a volunteer to write ISIS-lite to be used on hosts :) I would…. discourage that concept. Perhaps Robert is referring to when

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

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. Authors: Please indicate your knowledge of any IPR related to this work to the list as well. Thanks,

Re: [Lsr] Migration between normal flooding and flooding reduction

tony...@tony.li writes: Huaimo, This seems like it’s a job for the NMS/configuration management system and that there are no protocol interactions required. I'm definitely not a fan of using routing protocols for configuration management, so +1 to this. Thanks, Chris. Oh, and yes, we

[Lsr] WGLC: draft-ietf-isis-yang-isis-cfg (and remaining IPR replies)

Hi Folks, As mentioned in the meeting in Montreal, due to mixup (IPR call but no WGLC) the IS-IS yang module was submitted to the IESG prior to a WGLC being done. We are belated doing a WGLC on this document now. Please voice any objections to the continued progression of this document. Prior

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

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 comments to the list by Wednesday Oct 16th, 2019. Thanks, Chris. signature.asc Description: Message signed with OpenPGP

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

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, 2019. Thanks, Chris. signature.asc Description: Message signed with OpenPGP

[Lsr] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

Hi LSR WG and Draft Authors, This begins a 2 week WG adoption poll for the following draft: https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode/ Please indicate your support or objection by Dec 27th. Authors, please respond indicating whether you are aware of any IPR that

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

Hi LSR WG and Draft Authors, This begins a 2 week WG adoption poll for the following draft: https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-reverse-metric/ Please indicate your support or objection by Dec 27th. Authors, please respond indicating whether you are aware of any IPR that

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

That should have been: draft-ietf-lsr-ospf-yang-augmentation-v1-00. Thanks, Chris. > On Oct 22, 2019, at 2:30 AM, Christian Hopps wrote: > > The WG Adoption poll has ended. The work is adopted. Please republish as > draft-ietf-lsr-ospf-yang-augmentation-v1-01. > &g

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

The WG Adoption poll has ended. The work is adopted. Please republish as draft-ietf-lsr-ospfv3-extended-lsa-yang-00. Thanks, Chris. > On Oct 2, 2019, at 5:26 PM, Christian Hopps wrote: > > Hi Folks, > > This begins a 2 week WG adoption poll for the followi

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

The WG Adoption poll has ended. The work is adopted. Please republish as draft-ietf-lsr-ospf-yang-augmentation-v1-01. Thanks, Chris. > On Oct 2, 2019, at 5:27 PM, Christian Hopps wrote: > > Hi Folks, > > This begins a 2 week WG adoption poll for the followi

Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)

This strikes me as one of these artificial limits that gains us almost nothing (what if the platform supports less than 32 or it supports 32?), and creates these backward incompatible YANG issues (ranges that have to change) that are part of what is driving the complexity in the YANG versioning

Re: [Lsr] Adam Roach's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)

should have read "or it supports more than 32" > On Oct 8, 2019, at 5:53 AM, Christian Hopps wrote: > > This strikes me as one of these artificial limits that gains us almost > nothing (what if the platform supports less than 32 or it supports 32?), and > creates th

[Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi LSR WG and Draft Authors, The authors originally requested adoption back @ 105; however, some comments were received and new version was produced. Moving forward... This begins a 2 week WG adoption poll for the following draft:

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

The document is adopted. Authors, please repost as draft-ietf-lsr-ospfv3-srv6-extensions. Thanks, Chris & Acee. > On Jan 23, 2020, at 3:24 PM, Christian Hopps wrote: > > Hi LSR WG and Draft Authors, > > The authors originally requested adoption back @ 105; however, so

[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

This begins a 2 week WG Last Call, ending after Feb 4, 2020, for draft-ietf-lsr-isis-srv6-extensions https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ Authors please indicate if you aware of any other IPR beyond what is posted: https://datatracker.ietf.org/ipr/3796/

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

The WG Last Call has completed successfully, and the document will be submitted to IESG after the shepherd finishes the write-up. Thanks, Chris. > On Jan 2, 2020, at 2:06 PM, Christian Hopps wrote: > > This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for > draft-i

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

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 authors already responded during the adoption poll), please indicate your knowledge of any IPR related to this

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

The document is adopted. Authors, please repost with the name draft-lsr-ospf-bfd-strict-mode-00. Thanks, Chris & Acee. > On Dec 13, 2019, at 6:54 AM, Christian Hopps wrote: > > Hi LSR WG and Draft Authors, > > This begins a 2 week WG adoption poll for the following

Re: [Lsr] [spring] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Ketan Talaulikar (ketant) writes: [KT] The behaviors currently listed in the draft do not have an argument nor is the use of B and N required for them. We cannot preclude a future use-case or extension where such behaviors introduced are also applicable to ISIS. So IMHO ruling such aspects

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

> On Mar 11, 2020, at 6:13 AM, Peter Psenak wrote: > > On 11/03/2020 09:24, Christian Hopps wrote: >>> On Mar 10, 2020, at 8:06 PM, Les Ginsberg (ginsberg) >>> wrote: >>> >>> Chris/Acee - >>> I strongly agree with Peter. >>&

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

to find the numerical value(s) associated with that name then > you refer to the registry created by > draft-ietf-spring-srv6-network-programming. Yes, but again, I wasn't talking about this. Thanks, Chris. [as WG member] > >Les > > > > -Original Messag

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

y directly and add protocol specific columns to it? Thanks, Chris. (as WG member) thanks, Peter Thanks, Acee On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps" wrote: > On Mar 9, 2020, at 6:36 AM, Peter Psenak wrote: > > Hi Chris,

[Lsr] bad xrefs [Re: I-D Action: draft-ietf-lsr-isis-srv6-extensions-06.txt]

I'm finding cross-references in this document to be incorrect, is something wrong with the XML to foo generation? For example: Section 7.2 says sub-TLVs are defined in Section 6 (Advertising Anycast Property) which I think is supposed to be Section 8 (Advertising SRv6 Adjacency SIDs) Section

[Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

1) I think we should have an IANA registry instead of just a table defined in section 10 of draft-ietf-lsr-isis-srv6-extensions-06. The registry could be cross-referenced by and to "SRv6 Endpoint Behaviors" for each protocol carrying these behaviors (IS-IS, OSPFv3, ...). If/when new behaviors

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

Oops, That was "Speaking as a WG member". > On Mar 7, 2020, at 9:46 AM, Christian Hopps wrote: > > 1) I think we should have an IANA registry instead of just a table defined in > section 10 of draft-ietf-lsr-isis-srv6-extensions-06. > > The registry could be cros

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

> On Mar 9, 2020, at 6:36 AM, Peter Psenak > wrote: > > Hi Chris, > > On 07/03/2020 15:46, Christian Hopps wrote: >> 1) I think we should have an IANA registry instead of just a table defined >> in section 10 of draft-ietf-lsr-isis-srv6-extensions-06.

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Les Ginsberg (ginsberg) writes: Tony – If you have a suggestion for Tx back-off algorithm please feel free to share. The proposal in the draft is just a suggestion. As this is a local matter there is no interoperability issue, but certainly documenting a better algorithm is worthwhile.

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

> On Mar 11, 2020, at 10:38 AM, Les Ginsberg (ginsberg) > wrote: > > Chris - > > >> >> Do you think we should get rid of the "used in" columns in the IS-IS TLV and >> sub-TLV registries? The documents that define those TLVs and sub-TLVs >> already indicate which PDUs and TLVs they go in,

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

> On Mar 11, 2020, at 10:38 AM, Les Ginsberg (ginsberg) > wrote: > > Chris - > > >> >> Do you think we should get rid of the "used in" columns in the IS-IS TLV and >> sub-TLV registries? The documents that define those TLVs and sub-TLVs >> already indicate which PDUs and TLVs they go in,

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

Router Capabilities here is wrong in my view. > >Les > > > > -Original Message- > > From: wangyali > > Sent: Wednesday, April 01, 2020 8:12 PM > > To: Acee Lindem (acee) ; Les Ginsberg (ginsberg) > > ; Christian Hopps > > Cc: lsr@ietf.o

Re: [Lsr] LSR Interim Invitations (.ics attached)

u will have time to read the drafts. > > > > Thanks, > > Acee > > > > From: Yingzhen Qu > Date: Tuesday, March 24, 2020 at 11:45 PM > To: "lsr@ietf.org" , "lsr-cha...@ietf.org" > Subject: LSR Interim Invitations (.ics attached) &g

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

t; >> There is nothing in the lfit-capability draft that defines any information >> that can be used by IGPs to do what you suggest. >> Perhaps it is possible that information gleaned via a telemetry application >> could be used by the IGPs to do something like what you suggest - bu

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

>> you would be right. IGP is not a configuration push protocol. Sufficient to >>> observe how BGP became one :) >>> >>> Many thx, >>> R. >>> >>> >>> On Thu, Apr 2, 2020 at 8:46 AM Les Ginsberg (ginsberg) >>> wrote: &g

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

> On Apr 2, 2020, at 5:17 PM, Robert Raszuk wrote: > > Many thx, > R. > > PS. As we are talking LSR 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. > I am very sorry

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

that the link they send is no good so I will contact them again. Thanks, Chris. > On Apr 3, 2020, at 6:14 AM, bruno.decra...@orange.com wrote: > > Chris, > > Please see inline. > > >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps >> Sen

Re: [Lsr] Link State Routing (lsr) WG Virtual Meeting: 2020-04-29 CHANGED

Well that's sub-optimal. Contacting tools team about this. Thanks, Chris. > On Apr 3, 2020, at 7:05 AM, IESG Secretary wrote: > > MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. > > The Link State Routing (lsr) Working Group will hold > a virtual interim meeting on 2020-04-29 from

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

ility into consideration. Perhaps this isn't the right way to go about configuring IFIT, as it requires changes to all the routing protocols. There are other ways to do this that doesn't require changing or impacting all the routing protocols. Thanks, Chris. [as WG member] > > Best re

[Lsr] Webex Details 1st LSR interim

Here are the details for the first interim - PLEASE MUTE: if you aren't presenting or called on for the mic please mute. After talking please mute again. - MIC QUEUE: if you'd like to ask a question post a "+q" in the webex chat, we will call you when it's your turn. - HEADSETS: Please use a

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

Sorry that was "as WG member" btw. > On Mar 31, 2020, at 9:59 PM, Christian Hopps wrote: > > > >> On Mar 31, 2020, at 9:28 PM, Tianran Zhou wrote: >> >> ZTR> Let's not boil the ocean to compare NETCONF/YANG or routing protocol, >> wh

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

> On Mar 31, 2020, at 9:28 PM, Tianran Zhou wrote: > > ZTR> Let's not boil the ocean to compare NETCONF/YANG or routing protocol, > which is better. But I did not see the modification to routing protocol with > some TLVs is a heavy work, or more complex than NETCONF/YANG. I see both are >

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

Hi Yali, I think the overall concept of ifit is interesting enough. My concern is that we aren't adding things to routing protocols (in particular IGPs) simply to allow for another way of configuring applications in the network. This is what netconf/YANG etc, are for. If I were trying to code

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

> On Apr 30, 2020, at 9:57 AM, Henk Smit wrote: > > I still think we'll end up re-implementing a new (and weaker) TCP. Hi Henk, Thanks for the thoughtful writeup. Let's not be too cynical at the start though! :) I'd note that our environment is a bit more controlled than the end-to-end

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

> On May 4, 2020, at 5:47 AM, Henk Smit wrote: > > I'm looking forward to seeing (an outline of) your algorithm. I'm not trying to push any particular algorithm, we already have some proposals. My intention was only to suggest that we not disregard solutions too aggressively. The argument

[Lsr] Congestion (flow) control thoughts.

[As WG member] I like the start these drafts are making, I have a few thoughts. - I think its worthwhile work and as a WG we should end up adopting a draft or drafts that try to solve the problem. - Congestion control is hard, and a very well studied problem, as such whatever we end up should

Re: [Lsr] Flooding across a network

[as WG member] I think it would be more productive if we stay focused on trying to improve flooding speed/efficiency here. How about let's get some of the proposals being mulled over actually written, and provide some data, and leave all the hand-wringing and theorizing about being

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

ol again with a user > transport in the whole ball of yarn that IP is already. > > kind of all I had to say, next thing ;-) > > --- tony > > On Tue, Mar 10, 2020 at 7:48 AM Christian Hopps wrote: > > Les Ginsberg (ginsberg) writes: > > > Tony – >

Re: [Lsr] Question about OSPF (transit area routing loop)

Why does ABR_1 create a summary LSA to ASBR using the more expensive non-backbone path? This would seem to violate 12.4.3: Else, if the destination of this route is an AS boundary router, a summary-LSA should be originated if and only if the routing table entry describes the

Re: [Lsr] Flooding across a network

Bruno persistence has made me realize something fundamental here. The minute the LSP originator changes the LSP and floods it you have LSDB inconsistency. That is going to last until the last node in the network has updated it's LSDB. Les is pointing out that LSDB inconsistency can be bad in

Re: [Lsr] Flooding across a network

routers or altering the position of the problematic routers in the > network so as to reduce the overall load on those routers, or > reducing the LSP transmission rate network-wide." > > Les > >> -Original Message- >> From: Christian Hopps >>

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

. Thanks, Chris. [chair hat] > > > Rgds > Shraddha > > > Juniper Business Use Only > > -Original Message- > From: Peter Psenak > Sent: Thursday, September 3, 2020 1:25 PM > To: Shraddha Hegde ; olivier.dug...@orange.com; > tony...@tony.li; Robert Ras

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

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, please respond to the list indicating whether you are aware of any IPR that applies to this

Re: [Lsr] Review of draft-ietf-lsr-isis-ttz-00.txt

> On Sep 22, 2020, at 1:21 AM, Donald Eastlake wrote: > > > One final question: I may be confused but my understanding of IS-IS is > that there are Level 1 links, Level 2 links, and links that are both > Level 1 and 2. A border router between Level 1 and Level 2 is a router > that has both

Re: [Lsr] Pre-writeup review comments

Thanks for the update, a couple issues remain. [ ] 7.1 and 8.1 The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID sub-TLV" are defined differently (and probably incorrectly) than the other reserved bits. Reserved bits "MUST" be set to zero, not "SHOULD", I believe. [ ] 11.

[Lsr] WG last call complete draft-ietf-lsr-isis-srv6-extensions-11 [Re: Pre-writeup review comments]

Thanks Joel, Peter, et al. The WG last call is now complete (it was mainly being held during the appeal on the base document, and was ready a while ago). The document improved in the meantime which is great. I have completed the write-up and the document has been submitted to the IESG for

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

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.org/ipr/3448/ Authors, Please indicate to the list, your knowledge of any other IPR related

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

is (and > should be) focused on simple protocol extensions. [As WG member] I find this very compelling and so support the removal of the referred to non-normative appendices. Thanks, Chris. > > Thanx. > > Les > > >> -Original Message- >> From: Aijun

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

we want to do protocol extension, we should always convince > other the reason/motivation/prospects to do so. On the other hand, the use > case described in the current appendix is very prominent for operator to > accomplish the TE task in multi-area environment. > > Aijun Wang &

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

should be) focused on simple protocol extensions. >> >> Thanx. >> >> Les >> >> >>> -Original Message- >>> From: Aijun Wang >>> Sent: Thursday, October 15, 2020 6:51 PM >>> To: 'Jeff Tantsura' ; 'John E Drake' >>&

[Lsr] WG Last Call for draft-ietf-lsr-flex-algo

This begins a 2 week WG Last Call, ending after September 1st, 2020, for draft-ietf-lsr-flex-algo https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ All authors, please indicate by sending an email to the list, whether you aware of any other IPR beyond what is already posted:

Re: [Lsr] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

Hi folks, It seems that we followed the wrong procedure for this. The registries in question are Expert Review only and so RFC7120 does not apply. I wanted to send a quick email indicating that our input as chairs is not technically required as part of the process so our email was a NO-OP on

[Lsr] Pre-writeup review comments

During my review and while doing the Shepherd writeup for https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I came up with the following comments: 4.3 - Maximum H.Encaps MSD Type: - what is the default if not advertised? 6. Advertising Anycast Property Should "Locator

Re: [Lsr] Request WG adoption of TTZ

r to > the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy. > > Best Regards, > Huaimo > From: Acee Lindem (acee) > Sent: Tuesday, July 7, 2020 3:41 PM > To: Huaimo Chen ; Christian Hopps > > Cc: lsr@ietf.org ; lsr-cha...@ietf.org > Subject: Re: [

Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo, Can you speak to the differences of this with Area Proxy? They are similar solutions, right? There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i found it confusing to have this document also talking about TTZ for OSPF; is it redefining it, updating it,

Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

> On Jun 30, 2020, at 2:33 AM, tony...@tony.li wrote: > > > Hi all, > > The authors are on-board with this round of suggestions from Les. Could I > get a review by one more of our Designated Experts before we update the draft? So: - Top Level Area Proxy TLV - can be used to communicate

  1   2   3   >