Re: [OSPF] draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.

Mahendra, On 23/02/18 05:48 , Mahendra Singh Negi wrote: Dear Authors, Amidst implementing conflict resolution for OSPF SR ( https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05) we came across this issue. ** ** *Topology:* *Issue:* 1.Prefix conflict occurs at RT1 and RT2.

Re: [OSPF] [IANA #1047782] Protocol Action: 'OSPFv3 LSA Extendibility' to Proposed Standard (draft-ietf-ospf-ospfv3-lsa-extend-23.txt)

Hi Acee, as a next step, can you please ask for a early IANA allocation from the new registries as specified in section 8 of draft-ietf-ospf-ospfv3-segment-routing-extensions-11.txt thanks, Peter On 01/02/18 00:04 , Acee Lindem (acee) wrote: Hi Amanda, This is correct. Thanks Acee On

Re: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-segment-routing-extensions-11.txt

wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP WG of the IETF. Title : OSPFv3 Extensions for Segment Routing Authors : Peter Psenak

Re: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10

Hi Amanda, Jeff, On 15/12/17 02:34 , Jeff Tantsura wrote: Hi Amanda, Please note, in the draft-ietf-ospf-segment-routing-msd regretfully, the authors have requested an allocation from OSPFv2 Extended Link Opaque LSA TLVs while it should have been from OSPFv2 Extended Link TLV Sub-TLVs

Re: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT)

Hi Alexey, thanks for your comments. I have addressed them all except the one on the byte ordering, because as Acee has mentioned already all encodings are always in Network-Byte order. Please see the updated version at:

Re: [OSPF] Suresh Krishnan's No Objection on draft-ietf-ospf-segment-routing-extensions-23: (with COMMENT)

Hi Suresh, please see inline: On 13/12/17 22:15 , Suresh Krishnan wrote: Suresh Krishnan has entered the following ballot position for draft-ietf-ospf-segment-routing-extensions-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in

Re: [OSPF] Ben Campbell's No Objection on draft-ietf-ospf-segment-routing-extensions-23: (with COMMENT)

Hi Ben, please see inline: On 14/12/17 03:43 , Ben Campbell wrote: Ben Campbell has entered the following ballot position for draft-ietf-ospf-segment-routing-extensions-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To

Re: [OSPF] FW: Publication has been requested for draft-ietf-ospf-link-overload-10

Hi Acee, On 14/12/17 01:39 , Acee Lindem (acee) wrote: Please provide allocations for the code points in draft-ietf-ospf-link-overload-10.txt: OSPF Extended Link TLVs Registry more precisely, these should be allocated from "OSPFv2 Extended Link TLV Sub-TLVs" registry. The text in the

Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-22.txt

This draft is a work item of the Open Shortest Path First IGP WG of the IETF. Title : OSPF Extensions for Segment Routing Authors : Peter Psenak Stefano Previdi Clarence Filsfils

[OSPF] Request for Early IANA allocation for draft-ietf-ospf-lls-interface-id

Hi OSPF WG Chairs, authors of draft-ietf-ospf-lls-interface-id would like to request early code-point allocation from IANA as follows: Registry: Link Local Signalling TLV Identifiers Value: 18 Description: Local Interface Identifier TLV thanks, Peter

Re: [OSPF] IS-IS and OSPF Call for agenda slots @ IETF-100

Hi Folks, authors of the following drafts would like to request a slot: - draft-ietf-ospf-lls-interface-id-00 - 10 mims - draft-hegdeppsenak-isis-sr-flex-algo-00 - 20 mins thanks, Peter On 19/10/17 15:55 , Christian Hopps wrote: Hi OSPF and IS-IS, The preliminary agenda has been posted:

Re: [OSPF] Genart last call review of draft-ietf-ospf-segment-routing-extensions-19

Hi Dan, please see inline: On 05/10/17 13:05 , Dan Romascanu wrote: Reviewer: Dan Romascanu Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.

Re: [OSPF] early AD review of draft-ietf-bier-ospf-bier-extensions-07

Hi Alia, please see inline: On 02/10/17 16:41 , Alia Atlas wrote: Hi Peter, On Mon, Oct 2, 2017 at 10:05 AM, Peter Psenak <ppse...@cisco.com <mailto:ppse...@cisco.com>> wrote: Hi Alia, please see inline: On 27/09/17 00:12 , Alia Atlas wrote: I have done

Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18

Hi Alia, a new version of th draft-ietf-spring-segment-routing-ldp-interop has been posted, where the PHP behavior for SIDs adverised by SRMS has been clarified. thanks, Peter On 18/09/17 17:47 , Alia Atlas wrote: Hi Peter, On Mon, Aug 14, 2017 at 11:29 AM, Peter Psenak <p

Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18

Hi Alia, thanks for comments, please see inline: On 12/08/17 04:09 , Alia Atlas wrote: As is customary, I have done another AD review of draft-ietf-ospf-segment-routing-extensions-18. I do appreciate the improvements in the draft. I do still see a few minor issues. I would like to see a

Re: [OSPF] 答复: WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

Hi Shraddha, thanks for your comments. I believe all of them can be addressed by editorial changes and I'll be more then happy to work with you on those. More importantly, it looks to me you are not objecting the problem statement and the direction that the draft is taking to address it. Is my

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

On 06/07/17 05:50 , Ketan Talaulikar (ketant) wrote: Hi Shraddha, Thanks for taking care of some of the comments shared previously. Please find below some more that were probably missed or not taken care of. 1) I see that the use of link-local scope RI LSA has still been retained in this

Re: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

Support as co-author. thanks, Peter On 03/07/17 20:37 , Abhay Roy wrote: We would like to kick-off a poll for WG adoption of the following document (per Authors request): https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse Please let us know if you support or have concerns

Re: [OSPF] [spring] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

if the Binding SIDs are removed from the IGP, do they need to be removed from the BGP-LS extensions? [+IDR chairs] Thanks, Regards, --Bruno From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak Sent: Monday, June 12, 2017 10:18 AM > To: OSPF WG List; spr...@ietf.org; isis.

Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

. thanks, Peter On 09/06/17 19:04 , Peter Psenak wrote: Acee, my question is whether we need the whole section 6 and the SID/Label Binding Sub-TLV that it specifies. In OSPF Binding SID is not used for SRMS advertisement like in ISIS. thanks, Peter On 09/06/17 16:45 , Acee Lindem (acee

Re: [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

Acee, my question is whether we need the whole section 6 and the SID/Label Binding Sub-TLV that it specifies. In OSPF Binding SID is not used for SRMS advertisement like in ISIS. thanks, Peter On 09/06/17 16:45 , Acee Lindem (acee) wrote: Corrected IS-IS WG alias – Please reply to this

Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Olivier, On 24/05/17 14:46 , Olivier Dugeon wrote: Peter, Le 24/05/2017 à 13:26, Peter Psenak a écrit : Olivier, On 24/05/17 12:19 , Olivier Dugeon wrote: Hi Peter, Le 24/05/2017 à 11:37, Peter Psenak a écrit : Julien, - I don't know if there is any implementation that uses

Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Julien, On 24/05/17 12:08 , Julien Meuric wrote: Hi Peter, Please be aware that my comment applies beyond the scope of this single I-D. Talking about this one, see [JM] below. Thanks, Julien May. 24, 2017 - ppse...@cisco.com: Julien, - I don't know if there is any implementation that

Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Olivier, On 24/05/17 12:19 , Olivier Dugeon wrote: Hi Peter, Le 24/05/2017 à 11:37, Peter Psenak a écrit : Julien, - I don't know if there is any implementation that uses the solution proposed in RFC 4203. I sent a query to the WG list and so far I have not heard about a single one. I

Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Julien, - I don't know if there is any implementation that uses the solution proposed in RFC 4203. I sent a query to the WG list and so far I have not heard about a single one. - there is not even IANA registry created for the Sub-TLVs of the Link Local TLVs and there is no IANA value

Re: [OSPF] [spring] One question on E-flag of ABR/ASBR in OSPF SR extension

, Chao Fu -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, May 18, 2017 17:47 To: Chao Fu <chao...@ericsson.com>; spr...@ietf.org Subject: Re: [spring] One question on E-flag of ABR/ASBR in OSPF SR extension Hi Chao, On 18/05/17 11:15 , Chao Fu wrot

Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Hi Tony, On 11/05/17 18:37 , prz wrote: So, overall I think we agree on scope of the problem that needs to be addressed so we get a coherent set of standards out so would you agree to make this a WG document? Hey Peter, yes, given the backward compat section addresses all the issues

Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

PHP must not be done for SID coming from SRMS, we need to list all cases, not only one of them. So I would say we either not say anything, or we say: "For all other cases, when SID is coming from SRMS, PHM MUST not be done" thanks, Peter Rgds Shraddha -Original Message- Fro

Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-13.txt

PHP must not be done for SID coming from SRMS, we need to list all cases, not only one of them. So I would say we either not say anything, or we say: "For all other cases, when SID is coming from SRMS, PHM MUST not be done" thanks, Peter Rgds Shraddha -Original Message-

Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Hi Tony, please see inline: On 10/05/17 17:57 , prz wrote: On Tue, 09 May 2017 12:54:08 +0200, Peter Psenak <ppse...@cisco.com> wrote: Hi Tony, let me try to clarify. 1. This draft does not change, nor does it conflict with RFC3630 in any way. Peter, my bad, I got confused forg

Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Hi Tony, let me try to clarify. 1. This draft does not change, nor does it conflict with RFC3630 in any way. 2. This draft does not change anything in RFC4203 either. It provides an alternative and more generic way to exchange Link Local Identifier on the interface. Your are right that in

Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local Interface ID Advertisement"

Support as coauthor. Peter On 04/05/17 20:45 , Acee Lindem (acee) wrote: This draft was presented in Chicago and there was acknowledgment that a solution was needed. The authors have asked for WG adoption and we are now doing a WG adoption poll. Please indicate your support or objection by

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Alex, please see inline: On 21/04/17 14:29 , Alexander Okonnikov wrote: Hi Peter, See my comments inline. Thanks. 21.04.2017 14:17, Peter Psenak пишет: Hi Shraddha, please see inline: On 21/04/17 12:53 , Shraddha Hegde wrote: Hi Peter, Thanks for the detailed review. Pls see inline

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, please see inline: On 21/04/17 12:53 , Shraddha Hegde wrote: Hi Peter, Thanks for the detailed review. Pls see inline.. -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Friday, April 21, 2017 1:38 PM To: Shraddha Hegde <shrad...@juniper.net>

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, please find my comments below: The draft defines two mechanisms: a) signaling the link overload to the neighbor. The purpose is to advertise the link with max-metric from both directions. b) flooding the Link-Overload sub-TLV inside the area. The purpose is to let "LSP ingress

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, please see inline: On 20/04/17 08:46 , Shraddha Hegde wrote: Ketan, Pls see inline.. -Original Message- From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Thursday, April 20, 2017 10:06 AM To: Acee Lindem (acee) ; Acee Lindem

Re: [OSPF] [Adj-SID Flags] Regarding newly added 'P' flag

Hi Veerendranath, On 02/03/17 05:53 , Veerendranatha Reddy Vallem wrote: Dear Authors, As per my understanding ‘P’ flag is used to avoid Adj-SID value change in forwarding plane and during segment routing path calculation by controller for interface flapping or switch over cases. for any

Re: [OSPF] FW: [OSPFv3 IPv6 SR] Regarding prefixes identification for IPv6 Segment Routing

the prefixes not supported segment routing or supporting segment routing. Regards, Veerendranath -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: 27 February 2017 20:32 To: Veerendranatha Reddy Vallem <veerendranath...@huawei.com>; draft-ietf-ospf-ospfv3-lsa-exten

Re: [OSPF] FW: [OSPFv3 IPv6 SR] Regarding prefixes identification for IPv6 Segment Routing

Veerendranath, can you please elaborate on the use case? I'm not sure I understand exactly what you are asking for. thanks, Peter On 20/02/17 10:34 , Veerendranatha Reddy Vallem wrote: Dear Authors, Gentle remainder, We are planning to implement the “identification of IPv6 prefix for

Re: [OSPF] [OSPFv3-SR] Regarding Prefix SID Sub TLV advertisment for IPv6 data plane Segment routing

Veerendranath, On 16/01/17 14:46 , Veerendranatha Reddy Vallem wrote: Dear Authors, I am requesting your clarification regarding prefix-SID sub TLV advertisement for IPv6 data plane. In case of data plane is IPV6 data plane, while advertising IPv6 prefix (Node/Prefix SID) in

Re: [OSPF] Call for WG Adoption "OSPF Routing with Cross-Address Family MPLS Traffic Engineering Tunnels"

Support thanks, Peter On 06/01/17 16:17 , Acee Lindem (acee) wrote: This starts a 2-week call for WG Adoption for the subject draft. The adoption call will conclude on January 21st, 2017. The draft has expired but will be refreshed shortly.

Re: [OSPF] [OSPFv3-SR] Regarding LAN Adj-SID/Label description

Veerendranath, please see inline: On 29/11/16 03:06 , Veerendranatha Reddy Vallem wrote: Dear Authors, As per draft, for LAN SID Sub-TLV, 7.2. LAN Adj-SID Sub-TLV The LAN Adj-SID is an optional Sub-TLV of the Router-Link TLV. It MAY appear multiple times in the Router-Link TLV.

Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-03

Hi Bruno, please see inline (##PP): On 07/11/16 15:35 , bruno.decra...@orange.com wrote: Hi Peter, Many thanks for your replies. Please see inline [Bruno] From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Monday, November 07, 2016 1:23 PM > Hi Bruno, > > tha

Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-03

Hi Bruno, thanks for your comments, please see responses inline. We can work on details as we progress the draft in the WG. What I would like to hear from you at this point is whether you support the idea described in the draft. On 04/11/16 16:50 , bruno.decra...@orange.com wrote: Hi

Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

Chris, draft-hegde-ospf-advertising-te-protocols has following limitations: 1. only solves the problem of RSVP and Segment Routing TE. It does not address any other non-TE applications - e.g. LFA, SPF based on the delay or bandwidth, or anything that may come in the future. 2. it took the

Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

Support adoption as co-author. I am not aware of any IPR related to this draft. Peter On 25/10/16 22:27 , Abhay Roy wrote: Dear WG, Authors of draft-ppsenak-ospf-te-link-attr-reuse would like to poll the WG for adoption of this document as a WG Draft. Please send your opinions / concerns.

Re: [OSPF] WG Adoption Poll for "Signaling MSD (Maximum SID Depth) using OSPF"

Support. Peter On 11/10/16 11:57 , Acee Lindem (acee) wrote: Please indicate your support or objection to OSPF WG Adoption for "Signaling MSD (Maximum SID Depth) using OSPF” before 10/26/2016. For your convenience, here is a URL:

Re: [OSPF] FW: Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement

No support. We should not modify protocol to address possible bugs in the implementation. thanks, Peter On 11/10/16 20:51 , Acee Lindem (acee) wrote: Speaking as WG Co-Chair: We had a quite a lengthy discussion on this problem and whether or it is something the WG should adopt. Please

Re: [OSPF] OSPFv2 SR draft

----- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Monday, August 22, 2016 2:32 AM To: Chris Bowers <cbow...@juniper.net>; OSPF List <ospf@ietf.org> Subject: Re: [OSPF] OSPFv2 SR draft Chris, what about this to be added in the Section 3.1: "A router receiving a Prefix-SID

Re: [OSPF] OSPFv2 SR draft

er On 19/08/16 23:33 , Chris Bowers wrote: Peter, Please share the updated text that you plan to use with the WG, since this is a reasonably significant clarification. Thanks, Chris -Original Message----- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Tuesday, August 16, 2016 10:02 AM

Re: [OSPF] OSPFv2 SR draft

that would require router B to forward traffic using algorithm X. = Thanks, Chris -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Monday, August 15, 2016 6:40 AM To: Chris Bowers <cbow...@juniper.net>; OSPF List <ospf@ietf.org> Subject: Re: [OSP

Re: [OSPF] OSPFv2 SR draft

be forwarded to such a node. thanks, Peter If this is the intention, then it would be better to state is more explicitly. If not, then the intended meaning should be clarified. Thanks, Chris -Original Message- From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak

[OSPF] OSPFv2 SR draft

Hi All, following text has been added in the latest revision of the OSPFv2 SR draft, section 3.1. "If the SR-Algorithm TLV is not advertised by node, such node is considered as not being segment routing capable." Please let us know if there are any concerns regarding this addition.

Re: [OSPF] Working Group Last Call on IPR Update for OSPFv2 Segment Routing Extensions

Support as coauthor. thanks, Peter On 6/20/16 15:40 , Acee Lindem (acee) wrote: We are doing an additional last WGLC due for the IPR update for https://www.ietf.org/id/draft-ietf-ospf-segment-routing-extensions-08.txt Here are links to the previous and current IPR disclosures: Previous:

Re: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-mail)

Hi Acee, I am not aware of any undisclosed IPR on this draft. thanks, Peter On 6/3/16 23:45 , Acee Lindem (acee) wrote: Authors, For the final time, can you confirm whether or not you are aware of any IPR other than? https://datatracker.ietf.org/ipr/2401/

Re: [OSPF] Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-mail)

Support as coauthor. Thanks, Peter On 5/4/16 17:41 , Acee Lindem (acee) wrote: The subject draft is very stable, has multiple interoperable implementations, and many (including myself) have done thorough reviews. I believe we are ready for WG last call for this very important draft. With

Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01

Hi Paul, please see inline: On 4/7/16 22:09 , Paul Mattes (AZURE) wrote: I would like to amplify some of the comments made about this draft at today’s OSPF WG meeting. The draft refers generically to TE when it really means RSVP TE. The draft should use the more-specific term “RSVP TE” or

Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment"

I agree with Les and share the same concerns. Peter On 3/17/16 05:40 , Les Ginsberg (ginsberg) wrote: My opinion of the draft has not changed. It is defining a way to utilize OSPF to send application information - which is not something the protocol should be used to do. Further, it leaves

Re: [OSPF] Comment on draft-ppsenak-ospf-te-link-attr-reuse-01

Hi Julien, please see inline :(##PP) On 2/18/16 16:47 , Julien Meuric wrote: Hi Peter, Feb. 17, 2016 - ppse...@cisco.com: Hi Julien, On 2/16/16 18:24 , Julien Meuric wrote: Hi Pete, I believe the new text in the section 5 of the aforementioned I-D is a nice improvement for the

Re: [OSPF] Comment on draft-ppsenak-ospf-te-link-attr-reuse-01

Hi Julien, On 2/16/16 18:24 , Julien Meuric wrote: Hi Pete, I believe the new text in the section 5 of the aforementioned I-D is a nice improvement for the specification (thank you Chris). However, the current version still says "TE will use the information in the TE Opaque LSA and the non-TE

Re: [OSPF] regarding draft-ppsenak-ospf-te-link-attr-reuse-00

-- Message: 1 Date: Mon, 11 Jan 2016 08:33:12 +0100 From: Peter Psenak <ppse...@cisco.com> To: "xuling (F)" <xuli...@huawei.com>, "ospf@ietf.org" <ospf@ietf.org> Subject: Re: [OSPF] regarding draft-ppsenak-ospf-te-link-attr-reuse-00 Message-ID: <56935

Re: [OSPF] regarding draft-ppsenak-ospf-te-link-attr-reuse-00

Hi Ling, On 1/7/16 03:52 , xuling (F) wrote: Hi Acee, I suggest to advertise SRLG only in the TE opaque LSA, and advertise TE capability to help understand whether node is TE enabled. If node isn’t TE enabled , SRLG shouldn’t be used for TE application; otherwise, SRLG can be used for TE

Re: [OSPF] proposed text for draft-ppsenak-ospf-te-link-attr-reuse

Hi Chris, On 12/4/15 18:32 , Chris Bowers wrote: Draft authors, I would like to suggest the following text for the Backwards Compatibility section of this document. --- Some deployments of LFA and remote LFA currently rely on link attributes (such as SRLG and admin groups) being carried in

Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

Julien, On 11/10/15 17:51 , Julien Meuric wrote: Hi Acee, I think we do not need to agree on the philosophical question whether defining detour path by packet header instead of signaling states brings the feature out of TE... Anyway we agree that consolidating information from 3 separates LSA

Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

Hi Julien, On 11/5/15 09:12 , Julien Meuric wrote: Hi Jeff, Following the WG session yesterday, I'm glad to (lately) join the thread. Please, see my comments below as [JM]. Oct. 26, 2015 - jeff.tants...@ericsson.com: Hi, No hats I'm familiar with at least 2 implementations which have this

Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

Julien, On 11/5/15 09:20 , Julien Meuric wrote: Hi again, One more point below: Oct. 22, 2015 - Peter Psenak: The TE Opaque LSA would be, presumably, required if SPRING is supported which has no implications on whether RSVP-TE is enabled. SPRING does not use TE Opaque LSA. [JM] Just

Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

Julien, On 11/5/15 11:03 , Julien Meuric wrote: Hello Peter, Nov. 05, 2015 - ppse...@cisco.com: Hi Julien, On 11/5/15 09:12 , Julien Meuric wrote: Hi Jeff, Following the WG session yesterday, I'm glad to (lately) join the thread. Please, see my comments below as [JM]. Oct. 26, 2015 -

Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

are orthogonal to each other. TE Opaque LSA is dedicated for traffic engineering and must not be used for anything else. thanks, Peter 1) Some other condition Thanks, Chris -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Wednesday, October 21, 2015 3:24 PM

Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

Hi Chris, On 10/21/15 19:20 , Chris Bowers wrote: In my opinion the backwards compatibility problems introduced by this proposal outweigh potential gains. there is no backwards compatibility problem with the draft. As a concrete example, there is at least one existing implementation of

Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

aving LDP-enabled on a link would qualify as being "TE-enabled" or not. TE-enabled means the link is part of the traffic engineering topology as described by RFC3630. thanks, Peter Thanks, Chris -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: W

Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

Shraddha, On 10/21/15 07:20 , Shraddha Hegde wrote: Hi All, draft-ppsenak-ospf-te-link-attr-reuse-00 proposes moving and/or copying TLVs from the TE Opaque LSA to the Extended Link Opaque LSA. The draft lists the problems that the draft is trying to solve. I have reproduced that list of

Re: [OSPF] draft-ietf-ospf-ospfv3-segment-routing-extensions-03

Anil, there is no support for multi topology in existing OSPFv3 specification. We can not define it in the SR draft. thanks, Peter On 9/22/15 10:02 , Anil Kumar S N (VRP Network BL) wrote: Hi Authors, In OSPFv3 Extensions for Segment Routing I couldn’t find any references to MT-ID

Re: [OSPF] PHP route determination in draft-ietf-ospf-segment-routing-extensions-03

Santanu, If B is not advertising a SID for 20.1.1.0/24, then A will not do PHP. regards, Peter On 4/2/15 08:39 , Santanu Kar wrote: SANTANU Iactually wanted to highlight the non-ABR cases here. Consider the3routers below,in same area. A -10.1.1.0/24- B --20.1.1.0/24 -C In

Re: [OSPF] PHP route determination in draft-ietf-ospf-segment-routing-extensions-03

Santanu, On 4/2/15 13:32 , Santanu Kar wrote: Hi Peter -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, April 02, 2015 3:48 PM To: Santanu Kar; ospf@ietf.org; sprev...@cisco.com; cfils...@cisco.com; han...@juniper.net; rob.sha...@bt.com; wim.henderi

Re: [OSPF] PHP route determination in draft-ietf-ospf-segment-routing-extensions-03

, and give the packet to B, it will drop it, since PHP is enabled by default for all nodes. why would it drop? B will get the packet with the label that corresponds to 20.1.1.0/24. regards, Peter Regards Santanu -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent

Re: [OSPF] PHP route determination in draft-ietf-ospf-segment-routing-extensions-03

Santanu, On 3/31/15 15:20 , Santanu Kar wrote: Hi Authors I think last mail was a bit long to have probably missed the actual point which I was trying to make.Stating it concisely again. The PHP Prefix Segment can be advertised by the neighbor as well as by routers downstream of the neighbor

Re: [OSPF] [spring] draft-psenak-ospf-segment-routing-extensions-05

Anil, Adj-SID is a link attribute. Link is identified the same way as it is identified in the Router LSA - link-type, link-id, link-data. for unnumbered link: link-type = 1 link-id = Neighboring router's Router ID link-data = interface's ifIndex So if RTA wants to use a particular link

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

Shraddha, node-SID is advertised by the router for the prefix that is directly attached to it. Protection for such local prefix does not mean much. thanks, Peter On 12/24/14 11:57 , Shraddha Hegde wrote: Authors, We have a “backup flag” in adjacency sid to indicate whether the label is

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

more relevant to have A means of representing unprotected paths. Would be good to hear from others on this, especially operators. Rgds Shraddha -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Monday, December 29, 2014 1:35 PM To: Shraddha Hegde; draft-ietf-ospf

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

. The applications building the paths will either use prefix-sids with p flag on or off based on the need of the service. Rgds Shraddha -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Monday, December 29, 2014 1:49 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

the knowledge about the local adjacency protection and as such can signal it it it's LSA. thanks, Peter On 12/29/14 09:47 , Shraddha Hegde wrote: Peter, Pls see inline. Rgds Shraddha -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Monday, December 29, 2014 2:02 PM

Re: [OSPF] [Isis-wg] Mail regarding draft-ietf-ospf-segment-routing-extensions

get protection. In fact, you can have the new flag to say NP flag meaning non-protected flag which can be set for the unprotected path. By default it remains off and gives the behavior as it exists today. Rgds Shraddha -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent

Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Sunday, December 14, 2014 4:08 PM To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensi...@tools.ietf.org Cc: OSPF WG List Subject: Re: draft-ietf-ospf-segment-routing-extensions-03 Shraddha, the idea is that you can assign the same Adj-SID

Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

Shraddha, added ISIS WG alias, as this is not specific to OSPF. Please see inline: On 12/17/14 06:43 , Shraddha Hegde wrote: Peter, Please see inline: -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Tuesday, December 16, 2014 11:36 PM To: Shraddha Hegde

Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

will never be used in NSSA area. Keeping the prefix ranges confined within route types would make it much more simple. true, but it will make the deployment harder. thanks, Peter Rgds Shraddha -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent

Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

to have a route type, because it is not advertising a reachability. One can use domain wide flooding for certain external prefix, but use regular inter-area distribution for prefix range that is covering the external prefix. thanks, Peter Rgds Shraddha -Original Message- From: Peter

Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

Shraddha, please see inline: On 12/2/14 17:50 , Shraddha Hegde wrote: Authors, Some comments on the draft. 1. The draft refers to the various use cases in the use case document in I-D.filsfils-rtgwg-segment-routing. It’s useful to mention the section of the use case draft which is

Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

Hi Eric, there are definitely deployments using OSPF as PE-CE. It's typically used for enterprise customers, that use OSPF as their IGP and use L3 VPN service to interconnect their sites. thanks, Peter On 10/8/14 17:45 , Osborne, Eric wrote: I'm not sure this has much value. The vast

Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric

), it may be difficult or may require some out of band mechanism. If the out of band mechanism is available, I would also prefer to do so - and that was indeed in revision -02 as an further optimization. It was removed per Acee's comment. Thanks. Jeffrey -Original Message- From: Peter Psenak

Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric

-Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Monday, July 21, 2014 5:00 PM To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org Cc: vibhor.ju...@l-3com.com; dave.dub...@gdc4s.com; tom.mcmillan@l- 3com.com Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two

Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt

Hi Tony, please see inline: On 9/4/14 21:02 , A. Przygienda wrote: On 09/04/2014 12:24 AM, Peter Psenak wrote: Hi Tony, please see inline: Hey Peter, same On 9/3/14 18:13 , A. Przygienda wrote: It's also wise to add 'if the same extended prefix TLV (i.e. for same prefix) is seen

Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-prefix-link-attr-00.txt

Hi Tony, please see inline: On 9/3/14 18:13 , A. Przygienda wrote: Hey Acee, b) section 2. It may be well writing a sentence or two what should happen if an OSPFv2 Extended Prefix Opaque LSA changes its flooding scope (i.e. 9-11 changes) and what should happen if the same prefix appears in

Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Hi Rob, On 9/3/14 10:08 , Rob Shakir wrote: Hi Peter. On 26 Aug 2014, at 16:43, Peter Psenak ppse...@cisco.com wrote: On 8/26/14 17:32 , Hannes Gredler wrote: operators want to assign node-tags as per router function (ABR, PE, core) and then the LFA-selection becomes much easier

Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Hi Rob, On 9/3/14 10:16 , Rob Shakir wrote: Hi Peter, On 3 Sep 2014, at 09:13, Peter Psenak ppse...@cisco.com wrote: As per the above, I do not think that this mechanism replaces any capability, it just gives an operator a means to be more granular than the binary “supported

Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Hi Bruno, On 9/3/14 12:25 , bruno.decra...@orange.com wrote: Hi Peter, Rob, +1 on Rob's comment regarding the use of admin tag for expressing operator policy (rather than spec/feature capability) 1 point in lined below From: Peter Psenak Sent: Wednesday, September 03, 2014 10:21 AM Hi

Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

to the usage of the admin tags for signaling capabilities for which there is a better existing solution available. thanks, Peter /hannes On 9/3/14 12:32, Peter Psenak wrote: I agree as a general rule. Yet IMHO we should not kill this possibility. In particular for feature allowing incremental

Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

Hi Bruno, On 9/3/14 14:09 , bruno.decra...@orange.com wrote: Hi Peter, From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Wednesday, September 03, 2014 12:32 PM Hi Bruno, On 9/3/14 12:25 , bruno.decra...@orange.com wrote: Hi Peter, Rob, +1 on Rob's comment regarding the use of admin

Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

On 8/25/14 23:18 , Acee Lindem (acee) wrote: There are situations where node level policy is required and an OSPF advertised admin tag simplifies this. For example, advertisement of remote-LFA eligibility. my concern with the generic use of admin tags for signaling capability is that it's

Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

advertisement for popular applications. sure. Just that the draft mentions applications like Controlling Remote LFA tunnel termination, which I'm not sure the node tag is the best approach for. thanks, Peter Thanks, Acee On 8/26/14, 4:05 AM, Peter Psenak (ppsenak) ppse...@cisco.com wrote: On 8/25/14

Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

to tag nodes - that draft aims to fix that. I'm not against tagging nodes as such. What worries me if we end up using node tags for signalling capabilities of node. thanks, Peter HTH, /hannes On Tue, Aug 26, 2014 at 04:30:26PM +0200, Peter Psenak wrote: | Hi Acee, | | On 8/26/14 15:45 , Acee

  1   2   >