Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Robert, How about call them different “data plane encapsulations”? Best regards, Jie From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Thursday, April 14, 2022 9:51 PM To: John E Drake Cc: lsr@ietf.org; Ketan Talaulikar ; draft-ietf-lsr-ip-flexa...@ietf.org; Peter

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Thu, Apr 14, 2022 at 1:41 PM Randy Presuhn < randy_pres...@alumni.stanford.edu> wrote: > Hi - > > On 2022-04-14 1:33 PM, Andy Bierman wrote: > > > > > > On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder > > > > wrote: > > > > On Thu, Apr 14,

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi - On 2022-04-14 1:33 PM, Andy Bierman wrote: On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder > wrote: On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote: > The proposal is for a 2 year phase to change modules >

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Thu, Apr 14, 2022 at 1:13 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote: > > > The proposal is for a 2 year phase to change modules > > that really do want a zone index. It is not blindly removing the zone >

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi - On 2022-04-14 1:13 PM, Jürgen Schönwälder wrote: On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote: The proposal is for a 2 year phase to change modules that really do want a zone index. It is not blindly removing the zone index. People not reading type definitions will

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Thu, Apr 14, 2022 at 12:48:18PM -0700, Andy Bierman wrote: > The proposal is for a 2 year phase to change modules > that really do want a zone index. It is not blindly removing the zone > index. People not reading type definitions will also not read a warning signs. This is blindly removing

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Thu, Apr 14, 2022 at 12:38 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote: > On Thu, Apr 14, 2022 at 09:23:38AM -0700, Andy Bierman wrote: > > > > > So is this a correct summary: > > > > - zone index is not used in IPv4 at all > > There are link-local IPv4 addresses, they

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

That does summary below does not match what others have said on this thread. Yours, Joel On 4/14/2022 12:23 PM, Andy Bierman wrote: On Thu, Apr 14, 2022 at 8:01 AM Acee Lindem (acee) mailto:40cisco@dmarc.ietf.org>> wrote: While RFC 4001 really didn't need to extend the zone index

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Thu, Apr 14, 2022 at 09:23:38AM -0700, Andy Bierman wrote: > > > So is this a correct summary: > > - zone index is not used in IPv4 at all There are link-local IPv4 addresses, they are less wide-spread since IPv4 stacks generally do not auto-configure IPv4 link-local addresses. Nobody will

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Me too. Juniper Business Use Only From: Acee Lindem (acee) Sent: Thursday, April 14, 2022 10:55 AM To: Robert Raszuk ; John E Drake Cc: Peter Psenak (ppsenak) ; Ketan Talaulikar ; draft-ietf-lsr-ip-flexa...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] Working Group Last Call for

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi Andy, From: Andy Bierman Date: Thursday, April 14, 2022 at 12:24 PM To: Acee Lindem Cc: Martin Björklund , Juergen Schoenwaelder , "lsr@ietf.org" , "net...@ietf.org" Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt On Thu, Apr 14, 2022 at 8:01 AM

Re: [Lsr] IP address zones in YANG

From: Lsr on behalf of Rob Wilton (rwilton) Sent: 14 April 2022 13:40 To: net...@ietf.org Cc: lsr@ietf.org Subject: [Lsr] IP address zones in YANG Spinning off part of the discussion into a separate thread, but keeping lsr cc’ed on the discussion.

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Thu, Apr 14, 2022 at 8:01 AM Acee Lindem (acee) wrote: > While RFC 4001 really didn't need to extend the zone index to IPv4, the > conversation also pertains to IPv6 address types. At least RFC 4001 got it > right by not making the zone index part of the default types and defining > ipv4z and

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

While RFC 4001 really didn't need to extend the zone index to IPv4, the conversation also pertains to IPv6 address types. At least RFC 4001 got it right by not making the zone index part of the default types and defining ipv4z and ipv6z. Thanks, Acee On 4/14/22, 10:04 AM, "Lsr on behalf of

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Speaking as document shepherd and WG member: I don’t have a problem with “MPLS SR and SRv6 data planes” but wouldn’t be opposed to “MPLS SR and SRv6 logical data planes”. Thanks, Acee From: Robert Raszuk Date: Thursday, April 14, 2022 at 9:51 AM To: John E Drake Cc: "Peter Psenak (ppsenak)"

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

I thought the discussion was only about ipv4? /martin Jürgen Schönwälder wrote: > On Thu, Apr 14, 2022 at 03:23:31PM +0200, Martin Björklund wrote: > > Hi, > > > > First of all, I agree that if we were to design this from scratch, I > > think we should have a type for just an ip address, and

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi John, In the IETF context I have always associated ‘data plane’ with packet > forwarding, > No one disputes that. But the fact that various sub-data-planes are built on top of base physical data planes needs to be clearly distinguished. Kind regards, R.

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Thu, Apr 14, 2022 at 03:23:31PM +0200, Martin Björklund wrote: > Hi, > > First of all, I agree that if we were to design this from scratch, I > think we should have a type for just an ip address, and use a second > leaf for the zone (or interface). > The notation

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi, First of all, I agree that if we were to design this from scratch, I think we should have a type for just an ip address, and use a second leaf for the zone (or interface). "Rob Wilton (rwilton)" wrote: > Hi Martin, > > I have several concerns with this approach: > > (1) I still think that

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi, In the IETF context I have always associated 'data plane' with packet forwarding, so I think Peter's suggestion is fine. Yours Irrespectively, John Juniper Business Use Only From: Lsr On Behalf Of Robert Raszuk Sent: Thursday, April 14, 2022 5:21 AM To: Peter Psenak Cc: Ketan

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

On Wed, Apr 13, 2022 at 10:44:33AM +0200, Martin Björklund wrote: > Jürgen Schönwälder wrote: > > On Tue, Apr 12, 2022 at 04:52:41PM +0200, Martin Björklund wrote: > > > Jürgen Schönwälder wrote: > > > > > > [...] > > > > > > > For me, the only sensible option (other than accepting that types

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Hi Martin, I have several concerns with this approach: (1) I still think that the ip-address type name still ends up being non-intuitive (especially for zoned IPv4 addresses - I would be surprised to find that there is any deployment for these at all). I.e., the evidence seems to suggest

[Lsr] IP address zones in YANG

Spinning off part of the discussion into a separate thread, but keeping lsr cc'ed on the discussion. I'm trying to get a better understand of how and where zoned IP addresses should be used in YANG data models. RFC 4007 defines zones for IPv6 addresses, but not for IPv4. Even though RFC

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hey Peter, It seems that we have double layer of confusion here. First layer is what you are referring as applications in context of ASLA: RSVP-TE FRR (ex: LFA) Flex-Algo My suggestion about custom/logical topology/dataplane was in reference to the above. Then apparently we have more nested

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Ketan: I agree with you. IGP MT is a good precedent. If IPv4 and IPv6 use the same MT, the IPv4 and IPv6 topologies must be the same. The same MT does not define separate topologies or path computation for different data planes. If IPv4 and IPv6 data plane has different topologies, different

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Robert, On 14/04/2022 11:21, Robert Raszuk wrote: Hi Peter, Term "data-plane" usually means physical resources links, switch fabric, ASIC etc ... so I am afraid it will also generate confusion with default data plane. How about two alternatives: - custom/logical topology -

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Peter, Term "data-plane" usually means physical resources links, switch fabric, ASIC etc ... so I am afraid it will also generate confusion with default data plane. How about two alternatives: - custom/logical topology - logical-data-plane Thx, Robert. On Thu, Apr 14, 2022 at 9:27 AM

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Ketan, On 13/04/2022 15:56, Ketan Talaulikar wrote: Hi Peter, I would still reiterate the need to clarify the usage of "application" terminology in the base FlexAlgo spec. We don't need to call it "data-plane", I was suggesting "forwarding mechanism" or it can be something else as well.

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Les Thanks for the clarification. The Any versus All was confusing to me in the presentation, and your examples at the beginning of this thread have cleared up my confusion regarding ASLA and what Any bit brings to the table. Responses in-line On Thu, Apr 14, 2022 at 2:21 AM Les Ginsberg

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

Hi Gyan, Thanks for your review and feedback. Please check inline below. On Thu, Apr 14, 2022 at 11:47 AM Gyan Mishra wrote: > Hi Ketan > > I reviewed the draft and support publication. > > Can you add the two use cases in ISIS RM RFC 8500 about LDP IGP > synchronization and the DC lead to

Re: [Lsr] IETF13: Comments on The Application Specific Link Attribute (ASLA) Any Application Bit

Gyan – With respect, your post has several misunderstandings/inaccurate statements. I hope you have read my earlier post: https://mailarchive.ietf.org/arch/msg/lsr/JuV6frOi7LD5ybsr2iPTCgTph2w/ Let me try to correct your statements – please see inline. From: Gyan Mishra Sent: Wednesday, April

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

Hi Ketan I reviewed the draft and support publication. Can you add the two use cases in ISIS RM RFC 8500 about LDP IGP synchronization and the DC lead to spine scenario where the spine had links down or congestion. Kind Regards Gyan On Thu, Apr 14, 2022 at 1:10 AM Ketan Talaulikar wrote: >