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

2018-05-14 Thread Christian Hopps
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

2018-05-15 Thread Christian Hopps
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

2018-05-15 Thread Christian Hopps
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

2018-05-19 Thread Christian Hopps
>> 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

2018-05-19 Thread Christian Hopps
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

2018-05-21 Thread Christian Hopps
> 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

2018-05-21 Thread Christian Hopps
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

2018-05-15 Thread Christian Hopps
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] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

2018-05-23 Thread Christian Hopps
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, Chris. ___ Lsr mailing list Lsr@ietf.org

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

2018-06-16 Thread Christian Hopps
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

2018-06-18 Thread Christian Hopps
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.

2018-06-13 Thread Christian Hopps
[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]

2018-06-13 Thread Christian Hopps
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 :)

2018-02-19 Thread Christian Hopps
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

2018-08-28 Thread Christian Hopps
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

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

2018-08-27 Thread Christian Hopps
> On Aug 24, 2018, at 12:29 PM, tony...@tony.li wrote: > > Being distributed would be very nice. However, that implies that all nodes > are going to get to the exact same solution. Which implies that they all must > execute the same algorithm, presumably with the same inputs. > > That’s all

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

2018-07-06 Thread Christian Hopps
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

2018-03-07 Thread Christian Hopps
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

2018-04-23 Thread Christian Hopps
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

2018-12-19 Thread Christian Hopps
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...

2019-03-31 Thread Christian Hopps
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

2019-04-02 Thread Christian Hopps
+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...

2019-03-29 Thread Christian Hopps
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

2019-03-31 Thread Christian Hopps
> 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...

2019-03-31 Thread Christian Hopps
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.

2019-03-06 Thread Christian Hopps
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

2019-03-06 Thread Christian Hopps
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.

2019-02-24 Thread Christian Hopps
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] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

2019-02-25 Thread Christian Hopps
authors, or justification is required prior to publication. Thanks, Chris & Acee LSR WG Chairs. Christian Hopps writes: 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

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

2019-03-08 Thread Christian Hopps
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)..

2019-03-08 Thread Christian Hopps
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.

2019-02-14 Thread Christian Hopps
-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.

2019-02-11 Thread Christian Hopps
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.

2019-02-11 Thread Christian Hopps
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

2019-02-01 Thread Christian Hopps
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]

2019-02-01 Thread Christian Hopps
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

2019-02-01 Thread Christian Hopps
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]

2019-02-04 Thread Christian Hopps
* 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

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

2019-02-04 Thread Christian Hopps
raft names to reflect different solutions without causing confusion. Thanks & Regards, Zhenbin (Robin) 发件人: Lsr [lsr-boun...@ietf.org] 代表 Christian Hopps [cho...@chopps.org] 发送时间: 2019年2月1日 20:25 收件人: lsr@ietf.org 抄送: cho...@chopps.org 主题: [Lsr

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

2019-03-08 Thread Christian Hopps
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

2019-06-12 Thread Christian Hopps
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

2019-05-22 Thread Christian Hopps
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

Re: [Lsr] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-lsr-dynamic-flooding

2019-08-28 Thread Christian Hopps
Hi WG, First, IANAL. It may be worth noting that in this IPR disclosure the licensing is not the "normal" patent protection type (i.e., "use freely as long as you don't sue us on some other patent"). Thanks, Chris. > On Aug 14, 2019, at 10:09 AM, IETF Secretariat wrote: > > Dear Tony Li,

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

2019-07-29 Thread Christian Hopps
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

2019-10-02 Thread Christian Hopps
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

2019-10-02 Thread Christian Hopps
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

2019-12-13 Thread Christian Hopps
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

2019-12-13 Thread Christian Hopps
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

2019-10-22 Thread Christian Hopps
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

2019-10-22 Thread Christian Hopps
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

2019-10-22 Thread Christian Hopps
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)

2019-10-08 Thread Christian Hopps
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)

2019-10-08 Thread Christian Hopps
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

2020-01-23 Thread Christian Hopps
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

2020-02-12 Thread Christian Hopps
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

2020-01-21 Thread Christian Hopps
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

2020-01-21 Thread Christian Hopps
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

2020-01-02 Thread Christian Hopps
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

2020-01-06 Thread Christian Hopps
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] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

2020-01-06 Thread Christian Hopps
That should be draft-ietf-lsr-ospf-bfd-strict-mode Thanks, Chris. > On Jan 6, 2020, at 1:18 PM, Christian Hopps wrote: > > The document is adopted. > > Authors, please repost with the name draft-lsr-ospf-bfd-strict-mode-00. > > Thanks, > Chris & Acee. >

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

2020-01-06 Thread Christian Hopps
The document is adopted. Authors, please post a new version with name draft-ietf-lsr-ospf-reverse-metric-00. Thanks, Chris. > On Dec 13, 2019, at 6:28 AM, Christian Hopps wrote: > > Hi LSR WG and Draft Authors, > > This begins a 2 week WG adoption poll for the following dra

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

2020-03-12 Thread Christian Hopps
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]

2020-03-11 Thread Christian Hopps
> 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]

2020-03-11 Thread Christian Hopps
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]

2020-03-10 Thread Christian Hopps
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]

2020-03-07 Thread Christian Hopps
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]

2020-03-07 Thread Christian Hopps
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]

2020-03-07 Thread Christian Hopps
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]

2020-03-09 Thread Christian Hopps
> 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

2020-03-10 Thread Christian Hopps
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]

2020-03-11 Thread Christian Hopps
> 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]

2020-03-13 Thread Christian Hopps
> 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

2020-04-02 Thread Christian Hopps
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)

2020-03-25 Thread Christian Hopps
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

2020-04-02 Thread Christian Hopps
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

2020-04-02 Thread Christian Hopps
>> 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]

2020-04-02 Thread Christian Hopps
> 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]

2020-04-03 Thread Christian Hopps
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

2020-04-03 Thread Christian Hopps
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

2020-03-31 Thread Christian Hopps
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

2020-03-31 Thread Christian Hopps
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

2020-03-31 Thread Christian Hopps
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

2020-03-31 Thread Christian Hopps
> 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

2020-03-30 Thread Christian Hopps
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

2020-05-03 Thread Christian Hopps
> 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

2020-05-04 Thread Christian Hopps
> 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.

2020-04-29 Thread Christian Hopps
[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

2020-05-05 Thread Christian Hopps
[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

2020-03-10 Thread Christian Hopps
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)

2020-03-08 Thread Christian Hopps
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

2020-05-06 Thread Christian Hopps
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

2020-05-06 Thread Christian Hopps
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

2020-09-08 Thread Christian Hopps
. 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

2020-10-02 Thread Christian Hopps
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

2020-10-02 Thread Christian Hopps
> 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

2020-10-02 Thread Christian Hopps
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]

2020-10-08 Thread Christian Hopps
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

2020-10-15 Thread Christian Hopps
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

2020-10-16 Thread Christian Hopps
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

2020-10-16 Thread Christian Hopps
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 &

  1   2   >