Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

On 20/03/2020 11:59, Alvaro Retana wrote: On March 20, 2020 at 6:22:38 AM, Peter Psenak wrote: ... Besides the in-line comments, I want to point out here that this specification is incomplete. It needs to have (1) a formal description of the new MSD-Type (similar to §5/rfc8491), and (2) a

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Hi Alvaro, On 20/03/2020 11:13, Alvaro Retana wrote: On March 20, 2020 at 6:04:41 AM, Peter Psenak wrote: please see inline (##PP2): We're good to go. The only comment from the original review that you didn't reply to is this:    Besides the in-line comments, I want to poin

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Hi Alvaro, please see inline (##PP2): On 19/03/2020 22:48, Alvaro Retana wrote: On March 16, 2020 at 7:52:18 AM, Peter Psenak wrote: Peter: Hi! Let's first close the ISIS ELC draft before starting to work on OSPF one, as many comments are common and will be applicable to both ISI

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Hi Alvaro, thanks for your comments. Let's first close the ISIS ELC draft before starting to work on OSPF one, as many comments are common and will be applicable to both ISIS and OSPF variants. Please see inline (##PP): On 29/02/2020 06:00, Alvaro Retana wrote: Dear authors: This is my re

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

On 12/03/2020 12:33, Christian Hopps wrote: 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 appl

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

tan Talaulikar (ketant) mailto:ket...@cisco.com>> *Cc:* Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org>; SPRING WG List mailto:spr...@ietf.org>>; draft-ietf-spring-srv6-network-programming mailto:draft-ietf-spring-srv6-ne

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

en 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 Message- From: Lsr On Behalf Of Christian Hopps Sent: Tuesday, March 10, 2020 4:51 AM To: Peter

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

On 10/03/2020 12:50, Christian Hopps wrote: Peter Psenak writes: Hi Acee, On 09/03/2020 14:49, Acee Lindem (acee) wrote: Hi Peter, Chris, I agree that a number of IS-IS IANA registries have this level of specification. For example: https://www.iana.org/assignments/isis-tlv-codepoints

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

Chris, On 09/03/2020 13:26, Christian Hopps wrote: 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] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

0, 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. >> The registr

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

tate Routing WG of the IETF. Title : IS-IS Extension to Support Segment Routing over IPv6 Dataplane Authors : Peter Psenak Clarence Filsfils Ahmed Bashandy

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

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. The registry could be cross-referenced by and to "SRv6 Endpoint Behaviors" for each protocol carrying these

Re: [Lsr] Implementation section of draft-ietf-lsr-isis-srv6-extensions

Hi Chris, sure, will update the draft accordingly. thanks, Peter On 02/03/2020 19:20, Chris Bowers wrote: LSR, I would like to update the implementation section of draft-ietf-lsr-isis-srv6-extensions to read: 11.3.Juniper Juniper's ISIS SRv6 implementation supports the following funct

Re: [Lsr] IETF 107 LSR Presentation Slot Requests

Hi Yingzhen, I would like to give a 10 mins update on ietf-lsr-flex-algo. thanks, Peter On 28/02/2020 20:56, Yingzhen Qu wrote: Hi all, We're now accepting agenda request for the LSR Working Grouping meeting IETF 107. Please send your requests to lsr-cha...@ietf.org

Re: [Lsr] Questions about draft-ietf-lsr-flex-algo-06

Hi Peng, On 29/02/2020 07:41, peng.sha...@zte.com.cn wrote: Hi Peter Please see the difference rules of TE metric in Flex-algo draft and RFC5305. For  the link without TE metric attribute, in Flex-algo draft it will be excluded from FA plane that configured TE metric type, but in RFC5305 t

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

Hi Chris, On 27/02/2020 17:54, Chris Bowers wrote: LSR WG, Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6 SID Structure Sub-Sub-TLV. In particular, it defines encoding for the locator block length and the locator node length.  The text refers to [I-D.ietf-spring-srv6-n

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

Tony, On 19/02/2020 20:25, tony...@tony.li wrote: Peter, I'm not scared of polynomial evaluation, but the fact that my IGP implementation is dependent on the PD specifics, which are not generally available and need to be custom built for each PD specifically. I always thought a good IGP imp

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

Tony, On 19/02/2020 11:37, Tony Li wrote: Peter, I'm aware of the PD layer and that is not the issue. The problem is that there is no common value to report across different PD layers, as each architecture may have different number of queues involved, etc. Trying to find a common value to r

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

Tony, On 19/02/2020 10:47, Tony Li wrote: Peter, Given many different hardware architectures one may run a single IGP implementation on, this becomes impractical and complex as each hardware architecture has its own specifics. One would rather keep the IGP implementation hardware agnostic,

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

Tony, On 19/02/2020 10:30, Tony Li wrote: Peter, above is nowhere close to what the reality is, especially in the distributed system. In such system, packets traverses via multiple queues on both LC and RP and application like IGP has no visibility to these queues. As you may recall, I w

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

Tony, On 19/02/2020 08:52, tony...@tony.li wrote: Les, Overall, I think you are making  general statements and not providing needed specifics. I’m sorry it’s not specific enough for you.  I’m not sure that I can help to your satisfaction. Maybe it’s obvious to you how a receiver based

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

State Routing WG of the IETF. Title : IS-IS Extension to Support Segment Routing over IPv6 Dataplane Authors : Peter Psenak Clarence Filsfils Ahmed Bashandy Bruno Dec

Re: [Lsr] feedback on draft-ietf-lsr-isis-srv6-extensions-04 related to algorithms

Hi Chris, On 14/02/2020 17:54, Chris Bowers wrote: All, The current text from Section 5 (below) doesn't specify if locators associated with algorithms with values 1-126 SHOULD or SHOULD NOT be advertised in Prefix Reachability TLVs. In particular, it seems like the text should specify the ex

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

above, it's obvious. thanks, Peter Thanks, Chris On Tue, Feb 4, 2020 at 2:44 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote: Hi Chris, On 03/02/2020 14:39, Peter Psenak wrote: >> I think a reasonable solution would be to remove the restriction >>

Re: [Lsr] more feedback on draft-ietf-lsr-isis-srv6-extensions-04

Hi Chris, On 05/02/2020 00:27, Chris Bowers wrote: LSR, I have some more feedback on draft-ietf-lsr-isis-srv6-extensions-04 that I am putting in a separate thread so as not to confuse the other thread related to N and A flags. === The end of Section 5 points out several issues that can

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

Hi Chris, On 03/02/2020 14:39, Peter Psenak wrote: I think a reasonable solution would be to remove the restriction on the N-flag to allow it to be used for non-/128 prefixes/locators.  This would allow the three possible prefix-SIDs states to be easily represented. ##PP right, that could be

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

Hi Jie, please see inline (##PP): On 03/02/2020 15:36, Dongjie (Jimmy) wrote: Hi Peter, Thanks for your reply. Please see inline: -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Monday, February 3, 2020 5:08 PM To: Dongjie (Jimmy) ; Acee Lindem (acee) ; Ketan

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

e N=0, A=0 case is preferable because it preserves backwards compatibility. Thanks, Chris On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote: Hi Chris, please see inline (##PP) On 29/01/2020 17:25, Chris Bowers wrote: > I woul

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

Hi Jie, please see inline: On 01/02/2020 13:53, Dongjie (Jimmy) wrote: Hi Peter, Please see some comments inline: -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak Sent: Friday, January 31, 2020 1:24 AM To: Acee Lindem (acee) ; Ketan Talaulikar

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

Hi Acee, On 30/01/2020 18:12, Acee Lindem (acee) wrote: Hi Peter, On 1/30/20, 11:36 AM, "Peter Psenak" wrote: Hi Acee, On 30/01/2020 17:11, Acee Lindem (acee) wrote: > Hi Ketan, > > In that case, it doesn’t make sense to incl

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

Hi Acee, On 30/01/2020 17:11, Acee Lindem (acee) wrote: Hi Ketan, In that case, it doesn’t make sense to include it in the End.X advertisement since you need to look it up to check it anyway. I don’t see any benefit here. The benefit is to make sure that the END.X SID that was configured for

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

Hi Chris, please see inline (##PP) On 29/01/2020 17:25, Chris Bowers wrote: I would like to proposed the following text to make section 6 more clear. Thanks, Chris  (existing text) 6.  Advertising Anycast Property    Both prefixes and SRv6 Locators may be configured

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

accordingly. thanks, Peter Thank you --Bruno -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Monday, January 27, 2020 1:43 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

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

Hi Bruno, please see inline (##PP): On 24/01/2020 16:24, bruno.decra...@orange.com wrote: 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

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

Hi Chris, Acee, as a coauthor, I support the WG adoption of this document. I'm not aware of any undisclosed IPRs. thanks, Peter On 23/01/2020 21:24, Christian Hopps wrote: Hi LSR WG and Draft Authors, The authors originally requested adoption back @ 105; however, some comments were receiv

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

Hi Chris, On 22/01/2020 01:14, Christian Hopps wrote: 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 wha

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

.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IS-IS Extension to Support Segment Routing over IPv6 Dataplane Authors : Pe

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

I support this document adoption as a co-author and I am not aware of any IPR associated with it. thanks, Peter On 13/12/2019 12:54, Christian Hopps wrote: Hi LSR WG and Draft Authors, This begins a 2 week WG adoption poll for the following draft: https://datatracker.ietf.org/doc/draft-ke

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

I am not aware of any IPR associated with it. thanks, Peter On 13/12/2019 12:48, Peter Psenak wrote: Hi Chris, as coauthor, I support the WG adoption of this document. thanks, Peter On 13/12/2019 12:28, Christian Hopps wrote: Hi LSR WG and Draft Authors, This begins a 2 week WG adoption

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

Hi Chris, as coauthor, I support the WG adoption of this document. thanks, Peter On 13/12/2019 12:28, Christian Hopps wrote: 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/

Re: [Lsr] IETF 106 LSR Presentation Slot Requests

Hi Yingzhen, can I get 15 mins to cover below two drafts please. - draft-ietf-lsr-isis-srv6-extensions - 5 mins - draft-ietf-lsr-flex-algo - 10 mins thanks, Peter On 22/10/2019 21:45, Yingzhen Qu wrote: Hi, We're now accepting agenda request for the LSR Working Grouping meeting IETF 106.

Re: [Lsr] IPR Call for New Co-authors of draft-ietf-isis-mpls-elc-10.txt - "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" (Corrected)

Hi Acee, I'm not aware of any undisclosed IPRs related to the draft-ietf-isis-mpls-elc-10.txt thanks, Peter On 21/10/2019 16:39, Acee Lindem (acee) wrote: New Author and Contributors, Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-11? If so, has this IPR been disclose

Re: [Lsr] Rtgdir early review of draft-ietf-isis-mpls-elc-08

Hi Dhruv, please see inline (##PP): On 12/09/2019 12:06, Dhruv Dhody via Datatracker wrote: Reviewer: Dhruv Dhody Review result: Has Issues Subject: RtgDir Early review: draft-ietf-isis-mpls-elc-08 Hello I have been selected to do a routing directorate “early” review of this draft. ​https:/

Re: [Lsr] Rtgdir early review of draft-ietf-ospf-mpls-elc-09

Hi Dhruv, On 03/10/2019 16:48, Peter Psenak wrote: (3) Section 3, Add reference to draft-ietf-mpls-spring-entropy-label for the definition and usage of ERLD ##PP The Introduction section has: "This capability, referred to as Entropy Readable Label Depth (ERLD) as defined in[I-D.ietf

Re: [Lsr] Rtgdir early review of draft-ietf-ospf-mpls-elc-09

Hi Dhruv, On 03/10/2019 16:14, Dhruv Dhody wrote: Hi Peter, Snipping to open points... (1) Please use updated requirement language text as per RFC 8174, as you do have a mix of upper-case and lower-case terms in your I-D. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL

Re: [Lsr] Rtgdir early review of draft-ietf-ospf-mpls-elc-09

Hi Dhruv, please see inline (##PP) On 12/09/2019 12:11, Dhruv Dhody via Datatracker wrote: Reviewer: Dhruv Dhody Review result: Has Issues Subject: RtgDir Early review: draft-ietf-ospf-mpls-elc-09 Hello I have been selected to do a routing directorate “early” review of this draft. ​https:/

Re: [Lsr] RtgDir review: draft-ietf-ospf-te-link-attr-reuse-08

Hi Daniele, please see inline: On 18/09/2019 11:01, Daniele Ceccarelli wrote: Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and

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

Hi Bruno, On 02/09/2019 11:59, bruno.decra...@orange.com wrote: 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 De

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

Hi Acee, support as co-author. thanks, Peter On 30/08/2019 21:42, Acee Lindem (acee) wrote: We’ve gone through a number of iterations with these ELC drafts and I believe they are ready and meets all the use case requirements. Note that “Entropy Label for Spring tunnels” – draft-ietf-mpls-sp

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

Hi Acee, support as co-author. thanks, Peter On 30/08/2019 21:44, Acee Lindem (acee) wrote: We’ve gone through a number of iterations with these ELC drafts and I believe they are ready and meets all the use case requirements. Note that “Entropy Label for Spring tunnels” – draft-ietf-mpls-sp

Re: [Lsr] IPR Poll for "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS" - draft-ietf-isis-mpls-elc-07

Hi Acee, I'm not aware of any IPR. thanks, Peter On 30/08/2019 21:11, Acee Lindem (acee) wrote: Authors, Are you aware of any IPR that applies to draft-ietf-isis-mpls-elc-07? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more de

Re: [Lsr] "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF" - draft-ietf-ospf-mpls-elc-08

Hi Acee, I'm not aware of any IPR. thanks, Peter On 30/08/2019 21:06, Acee Lindem (acee) wrote: Authors, Are you aware of any IPR that applies to draft-ietf-ospf-mpls-elc-08? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more de

[Lsr] A-flag move

Hi Folks, following on what has been mentioned during the ISIS SRv6 draft update earlier today. A-flag has been defined as a bit in the Flags field of the SRv6 Locator TLV. We would like to move this bit to the IPv4/IPv6 Extended Reachability Attribute Flags sub-TLV, which can be advertised

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

Hi Chris, I support the WG adoption of draft-ginsberg-lsr-isis-invalid-tlv. thanks, Peter On 12/06/2019 14:04, Christian Hopps wrote: This begins a 2 week WG adoption call for draft-ginsberg-lsr-isis-invalid-tlv. https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv/ Please e

Re: [Lsr] draft-ietf-lsr-isis-srv6-extensions-00

Hi Acee, I will fix it in the next revision. thanks, Peter On 01/06/2019 01:44, Acee Lindem (acee) wrote: Authors, Now that this is a WG document, can we fix the draft title? Thanks, Acee *From: *Lsr on behalf of Robert Raszuk *Date: *Friday, May 31, 2019 at 6:18 PM *To: *Paul Mattes

Re: [Lsr] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"

Hi Robert, On 29/05/2019 10:31, Robert Raszuk wrote: Hey Peter, > Is it more efficient that only one area leader indicates(according to the command from NMS) explicitly then the network will be back to normal flooding? yes and we have that in the draft: "When the Area Lea

Re: [Lsr] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"

plies whether the Area Leader intends to operate in centralized mode or in distributed mode." For the number of candidate area leaders, I support we should have more than one for consideration of redundancy. sure. thanks, Peter -邮件原件- 发件人: Peter Psenak [mailto:ppse...@cisco.com] 发

Re: [Lsr] 答复: Option B from "Migration between normal flooding and flooding reduction"

Aijun, On 28/05/2019 08:15, Aijun Wang wrote: Hi, Tony: How the receiver judge the leader has stopped advertising the Area Leader sub-TLV? Do you need some timers? no timer needed, all event driven. Area Leader sub-TLV is removed from the LSP. thanks, Peter From the current discussion,

Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt

Olivier, please see inline: On 27/05/2019 16:50, olivier.dug...@orange.com wrote: Peter, Please see below my answers. Le 24/05/2019 à 12:02, Peter Psenak a écrit : Olivier, please see inline: On 23/05/2019 11:56 , olivier.dug...@orange.com wrote: Dear all As there is no more exchange

Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt

Olivier, please see inline: On 23/05/2019 11:56 , olivier.dug...@orange.com wrote: Dear all As there is no more exchange about the two mentioned drafts since 3 weeks, I'll try to summarize the exchange and the requested modifications. The drafts proposed to extended IS-IS respectively OSPF t

Re: [Lsr] Enhancements on encoding of router IDs and DR IDs

Hi Huaimo, thanks for the suggestion, I think it's good one to include. One side effect of your proposal is that when the new ID or DR ID is inserted, it may cause other IDs/DR IDs to change their index, as you can not assume you can simply add to the end of the list anymore. thanks, Peter

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

Hi Acee, I’m not aware of any non-disclosed IPRs. thanks, Peter Regards,On 09/05/2019 16:23 , Acee Lindem (acee) wrote: Authors, Are you aware of any IPR that applies to draft-bashandy-isis-srv6-extensions-05.txt? If so, has this IPR been disclosed in compliance with IETF IPR rules (

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

I support the adoption of draft-bashandy-isis-srv6-extensions as WG item. thanks, Peter On 09/05/2019 15:49 , Acee Lindem (acee) wrote: We been holding off WG adoption until the base SRv6 draft was adopted in SPRING. Now that https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-prog

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

Hi Olivier, On 02/05/2019 16:01 , olivier.dug...@orange.com wrote: Hello Peter, Le 15/04/2019 à 13:05, Peter Psenak a écrit : Robert, On 15/04/2019 11:21 , Robert Raszuk wrote: Peter, IMO what Olivier has indicated is a practical and operational aspect. The theoretical aspects of protocol

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

answer how for a given link of RTT 20 ms - you could send different value per each application ? Or do you mean that on any given link mpls RTT != IPv4 RTT != IPv6 RTT ? Kind regards, R. On Mon, Apr 15, 2019 at 10:49 AM Peter Psenak mailto:ppse...@cisco.com>> wrote: Hi Olivier, On 12/0

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

ed to maintain both system old and new, during a long period. we want multiple different values of link attribute to be advertised. That is not a duplication. thanks, Peter A bit more Inline. *From:*olivier.dug...@orange.com *Sent:* Friday, April 12, 2019 7:26 AM *To:* Peter Psen

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

n what you measure. thanks, Peter Kind regards, R. On Mon, Apr 15, 2019 at 10:49 AM Peter Psenak mailto:ppse...@cisco.com>> wrote: Hi Olivier, On 12/04/2019 16:26 , olivier.dug...@orange.com <mailto:olivier.dug...@orange.com> wrote: > Hello Peter, > &

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

Hi Olivier, On 12/04/2019 16:26 , olivier.dug...@orange.com wrote: Hello Peter, Le 12/04/2019 à 15:27, Peter Psenak a écrit : Hi Oliver, There are two major purposes served by the drafts: 1)Support of incongruent topologies for different applications Don't understand. What do you

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

Hi Oliver, There are two major purposes served by the drafts: 1)Support of incongruent topologies for different applications 2)Advertisement of application specific values even on links that are in use by multiple applications These issues are clearly articulated in the Introductions of both d

Re: [Lsr] IPR Poll for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

Hi Acee, I'm not aware of any relevant IPR. thanks, Peter On 11/04/2019 18:09 , Acee Lindem (acee) wrote: Authors, Contributors, Are you aware of any IPR that applies to draft-ietf-ospf-te-link-attr-reuse-07? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RF

Re: [Lsr] IPR Poll for "IS-IS TE Attributes per application" - draft-ietf-isis-te-app-06.txt (adding contributors)

I am not aware of any relevant IPR. Peter On 10/04/2019 23:35 , Acee Lindem (acee) wrote: Authors, Contributors, Are you aware of any IPR that applies to draft-ietf-isis-te-app-06.txt? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 537

Re: [Lsr] Flooding Path Direction

at any LSP received on a link that is not part of the FT is flooded on all links on the FT. In a centralized mode, the encoding of the FT would have to be extended to support unidirectional flooding. For distributed mode, no changes are required IMHO. thanks, Peter On 05/04/2019 09:28 , Peter

Re: [Lsr] Flooding Path Direction

: lsr@ietf.org; Jakob Heitz (jheitz) ; Peter Psenak (ppsenak) Subject: RE: [Lsr] Flooding Path Direction Dave - IGP flooding on a link is by specification bidirectional. It is OK if A arbitrarily decides not to initiate flooding an LSP to neighbor B, but the meaning of unidirectional flooding

Re: [Lsr] Flooding Path Direction

interfaces. To achieve 2 out with bidirectional, you need 3 in, 3 out, because the ins and outs are the same. Regards, Jakob. -Original Message- From: Peter Psenak Sent: Thursday, April 4, 2019 12:28 AM To: Jakob Heitz (jheitz) ; tony...@tony.li Cc: lsr@ietf.org Subject: Re: [Lsr

Re: [Lsr] Flooding Path Direction

Jakob, given that there is a single flooding topology calculated for an area, I don't see how this can be unidirectional, considering that flooding topology is used to flood in any direction. thanks, Peter On 04/04/2019 08:26 , Jakob Heitz (jheitz) wrote: I mean flooding in one direction o

Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding

ded. That should provide bi-connectivity again, if available. Temporary flooding is only triggered when node itself or its neighbor becomes isolated. thanks, Peter Many thx, R. On Tue, Mar 12, 2019 at 7:45 AM Peter Psenak mailto:ppse...@cisco.com>> wrote: Hi Robert, On 11

Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding

Hi Robert, On 11/03/2019 22:28 , Robert Raszuk wrote: Hi, As of now at the event of failure of any of the FT enabled link additional links are being added in more or less random fashion by nodes directly connected to the failed links. above statement is incorrect. It is absolutely NOT TRUE th

Re: [Lsr] Multiple failures in Dynamic Flooding

Hi Huaimo, On 11/03/2019 18:08 , Huaimo Chen wrote: Hi Tony, In summary for multiple failures, two issues below in draft-li-lsr-dynamyic-flooding are discussed: 1) how to determine the current flooding topology is split; and there is no need to do that. The recovery mechanism will

Re: [Lsr] Open issues with Dynamic Flooding

On 07/03/2019 18:16 , tony...@tony.li wrote: On Mar 5, 2019, at 1:31 PM, tony...@tony.li wrote: Let me propose that we add something to sections 6.7.5, 6.7.9, and 6.7.11 like: Addition of temporary flooding should be done with caution, as the addition of excessive co

Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes

spec does not define any algorithm, not much can be said on top of that. thanks, Peter But spec seems quite silent on such deployment model hence the post. Thx, R. On Thu, Mar 7, 2019 at 12:11 PM Peter Psenak mailto:ppse...@cisco.com>> wrote: Hi Robert, On 07/03/2019 12:00

Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes

Hi Robert, On 07/03/2019 12:00 , Robert Raszuk wrote: Hi, My reading of draft-ietf-lsr-dynamic-flooding indicates that said document in number of places rather assumes that entire topology (entire instance) supports dynamic flooding (perhaps other then bootstrap phase). Let's observe that ther

Re: [Lsr] Open issues with Dynamic Flooding

optimization. And if you are worried that you loose *wisely selected* all 4 paths before you manage to distribute new flooding topology you can always flood over 6 :) we want to limit the flooding to minimum, which is 2. thanks, Peter Best, R. On Tue, Mar 5, 2019 at 9:17 PM Peter Psenak

Re: [Lsr] Open issues with Dynamic Flooding

Hi Tony, On 05/03/2019 21:47 , tony...@tony.li wrote: LS topologies can have a very large number of adjacencies as well, typically with multiple spines, so for a new spine, all of the of the links may be unnecessary. ok, we talked bout the balance before - adding one link at a time to the FT

Re: [Lsr] Open issues with Dynamic Flooding

Hi Tony, On 05/03/2019 17:47 , tony...@tony.li wrote: Hi Peter, Adding all links on a single node to the flooding topology is not going to cause issues to flooding IMHO. Could you (or John) please explain your rationale behind that? It seems counter-intuitive. it's limited to the links o

Re: [Lsr] Open issues with Dynamic Flooding

uggest to agree whether you use dense mesh (DC) case or sparse mesh (WAN) case or "every topology imaginable" since that drives lots design trade-offs. my 2.71828182 cents ;-) --- tony On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak mailto:ppse...@cisco.com>> wro

Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs

: alexander.vainsht...@ecitele.com -Original Message- From: Peter Psenak Sent: Tuesday, March 5, 2019 5:28 PM To: Alexander Vainshtein Cc: lsr@ietf.org; spr...@ietf.org; draft-ietf-isis-segment-routing-extensions@ietf.org Subject: Re: [spring] FlexAlgo and Global Adj-SIDs Hi Sasha, On 02/03/2019 18

Re: [Lsr] Open issues with Dynamic Flooding

Hi Tony, On 05/03/2019 17:16 , tony...@tony.li wrote: Peter, (a) Temporarily add all of the links that would appear to remedy the partition. This has the advantage that it is very likely to heal the partition and will do so in the minimal amount of convergence time. I prefer (a) becaus

Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs

Sasha Vainshtein *From:* Peter Psenak *Sent:* Thursday, February 28, 2019 9:56:49 PM *To:* Alexander Vainshtein; draft-ietf-isis-segment-routing-extensi...@ietf.org *Cc:* lsr@ietf.org; spr...@ietf.org *Subject:* Re: [spring

Re: [Lsr] Open issues with Dynamic Flooding

Xiaohu, On 05/03/2019 09:48 , 徐小虎(义先) wrote: Given that all links between routers are p2p these days, I would vote for simplicity and make the LAN always part of the FT. Even all links between routers are P2P these days, the network management LAN if available could be leveraged to realize

Re: [Lsr] Open issues with Dynamic Flooding

Hi Tony, On 04/03/2019 18:54 , tony...@tony.li wrote: Hello, There are still two issues that need to be discussed and I was hoping that we could make progress on the mailing list before Prague. 1) Temporary additions to the flooding topology There are several cases where we would like t

Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs

Hi Alexander, On 28/02/2019 19:19 , Alexander Vainshtein wrote: Dear colleagues, I have a question regarding global Adj-SIDs in draft-ietf-isis-segment-routing-extensions. Section 3.4 of RFC 8402 defines definition and handling of global Adj-SIDs. The

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

Huaimo, On 24/02/2019 06:34 , Huaimo Chen wrote: Some issues with draft-li-lsr-dynamic-flooding-02 not fully addressed are briefed below. 1) There is no concrete procedure/method for fault tolerance to multiple failures. When multiple failures happen and split the flooding topology,

Re: [Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

----- 发件人: Peter Psenak [mailto:ppse...@cisco.com] 发送时间: 2019年2月18日 22:02 收件人: Goethals, Dirk (Nokia - BE/Antwerp); Acee Lindem (acee); lsr@ietf.org 主题: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

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

Hi Huaimo, On 18/02/2019 16:28 , Huaimo Chen wrote: Hi Peter, -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, February 14, 2019 2:30 AM To: Huaimo Chen ; Acee Lindem (acee) ; Christian Hopps ; lsr@ietf.org Subject: Re: [Lsr] Moving Forward [Re

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

ABR installed a route. above is exactly right. thanks, Peter Dirk On 2/18/2019 14:15, Peter Psenak wrote: Support as coauthor, although I never really agreed with the usage of the prefix originator for topology construction as described in section 3 and 5. I would prefer that part to be

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

t the prefixes belong to T1? that is exactly what this draft is trying to address. Today there is no way to determine the originator of the prefix in the remote area. We are adding that functionality in this draft. thanks, Peter Dirk On 2/18/2019 14:34, Peter Psenak wrote: Hi Dirk, On 18/02/20

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Hi Dirk, On 18/02/2019 14:27 , Goethals, Dirk (Nokia - BE/Antwerp) wrote: Hi Peter, See inline DG>. Dirk On 2/18/2019 14:18, Peter Psenak wrote: Hi Dirk, On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote: support +1 1 question: When S1 in another area receives such LSA,

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Hi Dirk, On 18/02/2019 09:31 , Goethals, Dirk (Nokia - BE/Antwerp) wrote: support +1 1 question: When S1 in another area receives such LSA, it then can learn that prefix Lt1 is associated with node T1, check the ELC, ERLD, or MSD value according to its necessity, and construct the right

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Support as coauthor, although I never really agreed with the usage of the prefix originator for topology construction as described in section 3 and 5. I would prefer that part to be removed. thanks, Peter On 13/02/2019 14:25 , Acee Lindem (acee) wrote: This begins a two week adoption poll f

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

Hi Huaimo, On 13/02/2019 22:50 , Huaimo Chen wrote: Hi Peter, My explanations/answers are in line below with prefix [HC]. -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Wednesday, February 6, 2019 4:58 AM To: Huaimo Chen ; Acee Lindem (acee) ; Christian

<    2   3   4   5   6   7   8   >