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

2020-09-08 Thread bruno.decraene
Hi Peter, > From: Peter Psenak [mailto:ppse...@cisco.com] > > Hi Bruno, > > please see inline: > > On 07/09/2020 17:31, bruno.decra...@orange.com wrote: > > Hi Peter, > > > >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak > >> Sent: Thursday, September 3, 2020 9:55 AM > >>

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

2020-09-07 Thread bruno.decraene
Hi Peter, > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak > Sent: Thursday, September 3, 2020 9:55 AM > > Hi Shraddha, > > On 03/09/2020 05:39, Shraddha Hegde wrote: > > Peter, > > > > In order to make the document clearer on this point, I would like the text > below to be

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-07 Thread bruno.decraene
Hi Tony, Thanks for your reply. At this point, area proxy spec is clear with regards to nominal behavior. So indeed we are discussing error handling / transitions. (and thank you for considering those cases, much appreciated). From memory, my understanding is the area proxy nominal behaviour

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-07 Thread bruno.decraene
Hi Tony, Thanks for your reply. All good to me. Thanks, --Bruno From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li Sent: Saturday, September 5, 2020 2:18 AM To: DECRAENE Bruno TGI/OLN Cc: lsr@ietf.org Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-04 Thread bruno.decraene
Hi Tony, I may have a comment on 5.2. Filtering LSP information. This is old text, but new re-reading. "A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an Outside Router. > Agreed (so far) "A Level 2 LSP with a source system identifier that is found in the Level 1 LSDB

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-04 Thread bruno.decraene
Hi Tony, Please find below some nits/minor comments. Please feel free to silently discard. 1) OLD: The advertisement in the Proxy LSP informs the remainder of the network that packets directed to the SID will be forwarded by one of the Inside Edge Nodes and the Area SID will be

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-09-04 Thread bruno.decraene
Hi Tony, I've read the diff for -03 and -04. The new encoding of the Area SID is good for me. And thank you for listening to my use case and suggestion. Thanks, --Bruno From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li Sent: Monday, August 24, 2020 7:02 PM To: lsr@ietf.org

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-04 Thread bruno.decraene
Les, Please see inline. From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Tuesday, August 4, 2020 4:50 PM To: DECRAENE Bruno TGI/OLN ; lsr@ietf.org Subject: RE: draft-ietf-lsr-isis-area-proxy-02 Bruno - Please see inline. From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of

[Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-04 Thread bruno.decraene
Hi, I may be missing something but the SR Binding SID TLV extension is not clear to me. 1) It does not seem compliant with RFC 8667 Draft says that the advertisement has: T-flag set, M & A flags cleared, SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present The following

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread bruno.decraene
Les, From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Monday, August 3, 2020 5:22 PM To: DECRAENE Bruno TGI/OLN ; tony...@tony.li Cc: lsr@ietf.org Subject: RE: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt Bruno – The concept of “Area SID” – at least

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread bruno.decraene
Hi Tony, From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li Subject: Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt Hi Bruno, Thank you for the clarification. [Bruno] You are very welcome. Thank you for listening. I understand completely

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-31 Thread bruno.decraene
Hi Tony, Thank you for your reply. Top posting the description of the use case that I have in mind. Ø First off, the Area SID is 100% optional. If you choose not to use it, then the Proxy LSP should be 100% compatible with a standard L2 node. Good. But I think that the idea of the Area SID is

Re: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-31 Thread bruno.decraene
Les, From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Thursday, July 30, 2020 7:29 PM To: DECRAENE Bruno TGI/OLN ; tony...@tony.li; lsr@ietf.org Subject: RE: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt Bruno – One of the reasons to use the

[Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-07-30 Thread bruno.decraene
Hi authors, Please find below some feedback for information. Feel free to ignore. 4.4.13. The Area SID https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13 "The following extensions to the Binding TLV are defined in order to support Area SID: A new flag

Re: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-30 Thread bruno.decraene
Hi Tony, Thanks for the updated draft. “ The Area SID Sub-TLV allows the Area Leader to advertise a SID that represents the entirety of the Inside Area to the Outside Area. This sub-TLV is learned by all of the Inside Edge Nodes who should consume this SID at forwarding time.”

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-28 Thread bruno.decraene
From: Acee Lindem (acee) [mailto:a...@cisco.com] An interesting encoding – note that the draft doesn’t use it for forwarding. [Bruno] Agreed that the distinction between routing and reachability information is a key point. --Bruno Acee From: Bruno Decraene mailto:bruno.decra...@orange.com>>

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-28 Thread bruno.decraene
Another data point about advertising more detailed reachability/unreachability: https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01 (for IPv6 some form of compression may be beneficial). --Bruno From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Tuesday, July

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

2020-06-30 Thread bruno.decraene
Hi Peter, > From: Peter Psenak [mailto:ppse...@cisco.com] > > Hi Bruno, > > On 30/06/2020 18:08, bruno.decra...@orange.com wrote: > > Hi Peter, > > > > Thanks for your reply. > > > >> From: Peter Psenak [mailto:ppse...@cisco.com] > >> > >> Hi Bruno, > >> > >> please see inline: > >> > >> On

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

2020-06-30 Thread bruno.decraene
Hi Peter, Thanks for your reply. > From: Peter Psenak [mailto:ppse...@cisco.com] > > Hi Bruno, > > please see inline: > > On 30/06/2020 16:53, bruno.decra...@orange.com wrote: > > Hi all, > > > > I can live with the current text, but I'm just raising the point for > > discussion > (better

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

2020-06-30 Thread bruno.decraene
Hi all, I can live with the current text, but I'm just raising the point for discussion (better safe than sorry). "16.1.1. IGP Algorithm Types Registry This document makes the following registrations in the "IGP Algorithm Types" registry: Type: 128-255. Description: Flexible

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-11 Thread bruno.decraene
Hi Chris, Acee, I support adoption. I've provided comments on the draft a couple of days ago. Regards, --Bruno -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Wednesday, June 10, 2020 9:28 PM To: lsr@ietf.org Cc: lsr-cha...@ietf.org;

[Lsr] FW: New Version Notification for draft-decraene-lsr-isis-flooding-speed-04.txt

2020-06-10 Thread bruno.decraene
Hi WG, Following our presentation at the latest LSR interim meeting, we have updated the draft as presented and discussed during the meeting. High level changes are: o Adding general introduction on flow control, congestion control, loss detection and recovery. o Reorganizing

[Lsr] draft-li-lsr-isis-area-proxy-06 & draft-przygienda-lsr-flood-reflection-01

2020-06-09 Thread bruno.decraene
Hi all, I've quickly read both drafts. In general, I don't think that I have spent enough time on the subject to provide any feedback on the list, but I've been suggested that some feedback is better than none. So providing some feedback for what it worth (2 cents). I think that the use case

Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

2020-06-05 Thread bruno.decraene
Les, Thanks for the updated draft. Looks ok to me except the point on interoperability. Indeed, I was asking to reinforce the requirement for interoperability with existing attributes, as this interop issue is created by this specification/extension. But you chose the opposite direction by

Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

2020-06-02 Thread bruno.decraene
Les, Thanks for your answers. Comments inline > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > Sent: Saturday, May 30, 2020 12:09 AM > > Bruno - > > Thanx for your (as always) meticulous review. > Responses inline. > Once we have reached agreement I will send out an updated

Re: [Lsr] Flooding across a network

2020-05-06 Thread bruno.decraene
> From: Christian Hopps [mailto:cho...@chopps.org] > > Bruno persistence has made me realize something fundamental here. > > The minute the LSP originator changes the LSP and floods it you have LSDB > inconsistency. Exactly my point. Thank you Chris. I would even say: "The minute the LSP

Re: [Lsr] Flooding across a network

2020-05-06 Thread bruno.decraene
Les, From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Wednesday, May 6, 2020 1:35 AM To: DECRAENE Bruno TGI/OLN; lsr@ietf.org Subject: RE: Flooding across a network Bruno - Seems like it was not too long ago that we were discussing this in person. Ahhh...the good old days...

[Lsr] Flooding across a network

2020-05-05 Thread bruno.decraene
Les, > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg) > Sent: Monday, May 4, 2020 4:39 PM [...] > when only some nodes in the network support faster flooding the behavior of > the whole network may not be "better" when faster flooding is enabled because > it

[Lsr] Research acitivity on IS-IS flooding

2020-04-29 Thread bruno.decraene
Hi all, Following the meeting today, and the first results with existing algorithm, it would a priori be interesting to have simulations or implementations tests results on the proposed algorithms. This email is a call to for info / contribution on this. - Do you know research

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

2020-04-27 Thread bruno.decraene
Ø ISIS flooding churn (and room for optimization) becomes a problem when node boots up (IMHO this is not a problem) and when node fails while having many neighbors attached. Yes maybe second case could be improved but well designed and operated network should have pre-programmed bypass paths

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

2020-04-24 Thread bruno.decraene
Tony From: Tony Przygienda [mailto:tonysi...@gmail.com] Sent: Thursday, April 23, 2020 7:29 PM To: DECRAENE Bruno TGI/OLN Cc: lsr@ietf.org; Les Ginsberg (ginsberg) Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed I was refering to RFC4960. Bruno, for all practical purposes I

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

2020-04-23 Thread bruno.decraene
Tony, Thanks for engaging. Please inline [Bruno2] From: Tony Przygienda [mailto:tonysi...@gmail.com] Sent: Wednesday, April 22, 2020 9:25 PM To: DECRAENE Bruno TGI/OLN Cc: lsr@ietf.org; Les Ginsberg (ginsberg) Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed On Wed, Apr

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

2020-04-23 Thread bruno.decraene
Peter, > From: Peter Psenak [mailto:ppse...@cisco.com] > > Bruno, > > On 22/04/2020 20:04, bruno.decra...@orange.com wrote: > > Les, > > > > Pleasesee inline > > > > *From:*Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > > *Sent:* Tuesday, April 21, 2020 11:48 PM > > *To:* DECRAENE

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

2020-04-22 Thread bruno.decraene
Les, Please see inline From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Tuesday, April 21, 2020 11:48 PM To: DECRAENE Bruno TGI/OLN Cc: lsr@ietf.org Subject: RE: Flow Control Discussion for IS-IS Flooding Speed Bruno - You have made an assumption that historically vendors have

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

2020-04-22 Thread bruno.decraene
Tony, all, Thanks Tony for the technical and constructive feedback. Please inline [Bruno] From: Tony Przygienda [mailto:tonysi...@gmail.com] Sent: Wednesday, April 22, 2020 1:19 AM To: Les Ginsberg (ginsberg) Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org Subject: Re: [Lsr] Flow Control Discussion for

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

2020-04-20 Thread bruno.decraene
Les, Thank you for this first answer. This is inline with my understanding of the behavior. I wish some of the behaviors and values (e.g. queue size, rate limiting) could be shared. At minimum a range of typical values for platform which are not end of sale. I don't think this is secret.

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

2020-04-20 Thread bruno.decraene
Les, After nearly 2 months, can we expect an answer from your side? More specifically, the below question [Bruno] _Assuming_ that the parameters are static, the parameters proposed in draft-decraene-lsr-isis-flooding-speed are the same as the one implemented (configured) on multiple

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

2020-04-03 Thread bruno.decraene
Chris, Please see inline. > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps > Sent: Friday, April 3, 2020 12:00 AM > To: Robert Raszuk > > > > > On Apr 2, 2020, at 5:17 PM, Robert Raszuk wrote: > > > > Many thx, > > R. > > > > PS. As we are talking LSR here it is

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

2020-03-10 Thread bruno.decraene
With regards to punting to TCP, I think that TCP (stacks) enforce packet ordering. i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1 until you receive packet 2. In the meantime, you cannot use the (N-2) packets that you did received. That seems like a regression for IS-IS

[Lsr] New Version Notification for draft-decraene-lsr-isis-flooding-speed-03.txt

2020-03-09 Thread bruno.decraene
Hi all, Following many interesting discussions on the mailing list, during IETF meetings 105 & 106 and of-list, please find below an updated version. Htmlized: https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed Diff:

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

2020-02-28 Thread bruno.decraene
Hi Ketan, Thanks fort the follow up. Clarification inline [Bruno] From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Friday, February 28, 2020 11:11 AM To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers Cc: lsr@ietf.org; SPRING WG List;

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

2020-02-28 Thread bruno.decraene
Hi Ketan, From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant) Sent: Friday, February 28, 2020 6:30 AM Hi Chris, I agree with Peter and I would suggest to drop LSR since this is not a protocol specific thing. I believe the text in

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

2020-02-26 Thread bruno.decraene
Les, Please see inline[Bruno] From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg) Sent: Wednesday, February 19, 2020 3:32 AM To: lsr@ietf.org Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed Base protocol operation of the Update process tracks the

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

2020-02-26 Thread bruno.decraene
Les, From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg) Sent: Wednesday, February 19, 2020 6:49 PM To: Robert Raszuk Cc: lsr@ietf.org Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed Robert – Thanx for your input. Note that one of the suggestions

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

2020-01-28 Thread bruno.decraene
> From: Peter Psenak [mailto:ppse...@cisco.com] > > Hi Bruno, > > On 28/01/2020 18:05, bruno.decra...@orange.com wrote: > > Hi Peter, > > > > Thank you. > > Looks good. > > > > Just one follow up > > > >>> §9 > >>> > >>> A priori the sum of all 4 sizes must be 128 bits. Could you specify the

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

2020-01-28 Thread bruno.decraene
Hi Peter, Thank you. Looks good. Just one follow up > > §9 > > > > A priori the sum of all 4 sizes must be 128 bits. Could you specify the > > error handling when this is not the case? (a choice could be to ignore > > this Sub-Sub-TLV; but given the error handling specified for another > >

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

2020-01-24 Thread bruno.decraene
Les, From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Friday, January 24, 2020 5:39 PM To: DECRAENE Bruno TGI/OLN; lsr@ietf.org Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee) Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions Bruno - Regarding §8.2

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

2020-01-24 Thread bruno.decraene
Hi authors, WG, I've re-read the draft. Please find below some minor comments and nits. Best regards, --Bruno Minors: == " A node indicates that it has support for SRv6 by advertising a new SRv6 Capabilities sub-TLV" I'm not completely certain that "support for SRv6" is perfectly

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

2020-01-22 Thread bruno.decraene
Chris, I'm not aware of non-disclosed IPR. Regards, --Bruno -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Wednesday, January 22, 2020 1:15 AM To: lsr@ietf.org Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee) Subject: [Lsr] WG Last

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

2020-01-06 Thread bruno.decraene
I support publication of the draft. Improving interoperability is definitely something that I support (1), in particular for mission critical protocols. Thank you to authors & Alvaro for the work and the initiative. Bruno (1) Including during error conditions ;-) -Original Message-

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

2019-10-01 Thread bruno.decraene
Hi Xiaohu, Please see inline [Bruno] From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of ???(??) Sent: Thursday, September 12, 2019 3:51 AM To: Lsr; Peter Psenak; Acee Lindem (acee); lsr@ietf.org; draft-ietf-isis-mpls-...@ietf.org Cc: m...@ietf.org; lsr-...@ietf.org Subject: Re: [Lsr] Working

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

2019-09-02 Thread bruno.decraene
Hi Peter, Thanks, looks good. --Bruno -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Monday, September 2, 2019 1:04 PM To: DECRAENE Bruno TGI/OLN; Acee Lindem (acee); lsr@ietf.org; draft-ietf-isis-mpls-...@ietf.org Cc: m...@ietf.org; lsr-...@ietf.org Subject:

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

2019-09-02 Thread bruno.decraene
Support. This is needed for using MPLS Entropy Label in SR-MPLS. Please find below some proposed comments. Please feel free to silently discard. §1 Introduction OLD: “This capability, referred to as Entropy Readable Label Depth (ERLD) as defined in

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

2019-09-02 Thread bruno.decraene
Support. This is needed for using MPLS Entropy Label in SR-MPLS. Please find below some proposed comments. Please feel free to silently discard. §1 Introduction OLD: “This capability, referred to as Entropy Readable Label Depth (ERLD) as defined in

[Lsr] FW: IPR Disclosure Juniper's Statement about IPR related to draft-decraene-lsr-isis-flooding-speed

2019-08-28 Thread bruno.decraene
FYI -Original Message- From: IETF Secretariat [mailto:ietf-...@ietf.org] Sent: Friday, August 2, 2019 8:37 PM To: draft-decraene-lsr-isis-flooding-sp...@ietf.org Cc: ipr-annou...@ietf.org Subject: IPR Disclosure Juniper's Statement about IPR related to

[Lsr] draft-decraene-lsr-isis-flooding-speed

2019-07-22 Thread bruno.decraene
Hi all, Following the presentation and discussion today, we would welcome comments on the draft. https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-01 If you have multiple significant comments on the draft, expecting to turn into a discussion, it would probably be easier to

Re: [Lsr] IETF 105 LSR Working Slot Requests

2019-06-26 Thread bruno.decraene
Hi, I would to like to request one slot : Draft: draft-decraene-lsr-isis-flooding-speed-00 Speaker: Bruno Decraene Duration: 12 minutes https://tools.ietf.org/html/draft-decraene-lsr-isis-flooding-speed-00 Thanks, Bruno From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)

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

2019-06-17 Thread bruno.decraene
Support. --Bruno -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Wednesday, June 12, 2019 2:05 PM To: lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps; draft-ginsberg-lsr-isis-invalid-...@ietf.org Subject: [Lsr] WG

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

2019-05-09 Thread bruno.decraene
Support adoption. (as a co-author) --Bruno From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Thursday, May 9, 2019 3:50 PM To: lsr@ietf.org Subject: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" -

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

2019-04-16 Thread bruno.decraene
Hi, I don't know anything about yang (module) so everything looks easy from 1 feet. Yet, my 2 cents. > I think the main requirement (speaking as an operator) is to get the YANG > part (ops+cfg) standardized at the same time. +1 to Stéphane & Christian Whether this is done in the same

Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

2019-04-15 Thread bruno.decraene
Hi Adrian, > On the other hand, > https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ found > its way onto the RFC Editor Queue at around the same date and has languished > there ever since. The OSPF document progressed well. The decision was made to normatively reference the

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

2019-04-04 Thread bruno.decraene
Les, -03 looks good. Thank you. --Bruno From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Wednesday, April 3, 2019 8:04 PM To: DECRAENE Bruno TGI/OLN; lsr@ietf.org; draft-ginsberg-lsr-isis-invalid-...@ietf.org Cc: Alvaro Retana Subject: RE: draft-ginsberg-lsr-isis-invalid-tlv

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

2019-04-02 Thread bruno.decraene
Les, Thank you for accommodating my comments. -02 looks good. 1 follow up comment: §3.2 "ISes MUST NOT accept purges that contain TLVs other than the authentication TLV" §3.1 " Therefore TLVs in a PDU which are disallowed MUST be ignored and MUST NOT cause the PDU itself to be rejected

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

2019-03-22 Thread bruno.decraene
§4 The presence of a TLV (or sub-TLV) with content which does not conform to the relevant specification MUST NOT cause the LSP itself to be rejected. Again, thank you for your effort to clarify the specification. Given the "MUST", I feel that this sentence may be read as contradicting

[Lsr] draft-ginsberg-lsr-isis-invalid-tlv

2019-03-22 Thread bruno.decraene
Hi all, To be clear, I support that document. Thanks for writing it. I have some comments, mostly asking for even more of this/such document. (although I expect that some comments will trigger a discussion ;-) ) §3.1 "Any codes in a received PDU that are not recognised shall be

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

2018-10-05 Thread bruno.decraene
Les, V18 addresses all my comments. Thank you, Les, for the discussion and for reflecting the outcome in the draft. --Bruno From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Friday, October 05, 2018 2:14 AM To: DECRAENE Bruno IMT/OLN; Acee Lindem (acee); MEURIC Julien IMT/OLN;

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

2018-10-04 Thread bruno.decraene
Les, Thanks for the proposed text. It’s crystal clear. It works for me. --Bruno From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Wednesday, October 03, 2018 11:27 PM To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN Cc: Routing Directorate;

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

2018-10-03 Thread bruno.decraene
Hi Acee, From: Acee Lindem (acee) [mailto:a...@cisco.com] Hey Bruno, Jeff, Les, Have we agreed on the precise definition of “label imposition”? Thanks for asking. Not so far. We don’t necessarily need to agree on a precision definition of “label imposition”. In my latest email (a few hours

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

2018-10-03 Thread bruno.decraene
Jeff, From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] Sent: Tuesday, October 02, 2018 8:28 PM To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN; Les Ginsberg (ginsberg) Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org; draft-ietf-isis-segment-routing-...@ietf.org

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

2018-10-03 Thread bruno.decraene
Les, From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Tuesday, October 02, 2018 8:20 PM To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org; draft-ietf-isis-segment-routing-...@ietf.org Subject: RE: [RTG-DIR]

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

2018-10-02 Thread bruno.decraene
Les, Thanks for the follow up. Please see inline [Bruno2] From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Friday, September 28, 2018 7:57 PM To: DECRAENE Bruno IMT/OLN; Alvaro Retana; MEURIC Julien IMT/OLN Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org;

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

2018-09-28 Thread bruno.decraene
Les, Alvaro, Jumping in the conversation, please see comments inlined [Bruno] From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg) Sent: Thursday, September 27, 2018 8:45 PM To: Alvaro Retana; MEURIC Julien IMT/OLN Cc: rtg-...@ietf.org; lsr@ietf.org; rtg-...@ietf.org;

Re: [Lsr] Entropy label for SR-MPLS

2018-09-03 Thread bruno.decraene
Speaking as an individual contributor and a service provider, 1) ELC (Entropy Label Capability) I support the ability to use entropy label and hence advertise ELC (Entropy Label Capability) inter-AS and inter-protocol deployments - In Orange we do have both inter-area/level and inter-AS w/

[Lsr] Entropy label for SR-MPLS

2018-09-03 Thread bruno.decraene
Hi SPRING WG, draft-ietf-isis-mpls-elc defines an IS-IS extension to allow the use of MPLS entropy labels in SR-MPLS networks. https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-05 As a reminder, entropy label has been defined in RFC 6790 by the MPLS WG. It improves load-balancing / allows

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

2018-08-02 Thread bruno.decraene
Hi authors, "4. Advertising ELC Using IS-IS One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired) is to be assigned by the IANA for the ELC [RFC6790]." RFC6790 defines ELC capability on a per FEC/LSP egress basis. Please defines what you mean exactly with this per node

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

2018-06-11 Thread bruno.decraene
I’m not aware of non-disclosed IPR. Regards, --Bruno, From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Uma Chunduri Sent: Monday, June 11, 2018 9:18 PM To: lsr@ietf.org Subject: [Lsr] IPR Poll on draft-ietf-isis-segment-routing-extensions-16 (Shepherd write-up) Dear All, Are you aware of

Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

2018-04-17 Thread bruno.decraene
+1 (I guess you meant :s/LSR/SR ;-) ) Thanks --Bruno From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Tuesday, April 17, 2018 5:24 PM To: lsr@ietf.org Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts Speaking as WG member, I support