Hi Acee,
Thanks a lot for your detailed review and your suggestions. We will be
incorporating them in the next update.
Please also check inline below for further responses.
On Wed, Apr 13, 2022 at 10:39 PM Acee Lindem (acee) wrote:
> Speaking as WG member and document shepherd:
>
>
>
> I
Hi Jeffrey,
Thanks for confirming that we are ok with this draft's relationship with
RFC8042.
Thanks,
Ketan
On Thu, Apr 14, 2022 at 12:13 AM Jeffrey (Zhaohui) Zhang
wrote:
> Hi Ketan,
>
>
>
> My fault. When I initially grepped for it, I used “8402” instead of “8042”
> and did not find it
On Apr 13, 2022, at 3:02 PM, Acee Lindem (acee)
mailto:acee=40cisco@dmarc.ietf.org>> wrote:
From: netmod mailto:netmod-boun...@ietf.org>> on
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Wednesday, April 13, 2022 at 12:43 PM
To: tom petch mailto:ie...@btconnect.com>>
Cc:
From: netmod on behalf of Andy Bierman
Date: Wednesday, April 13, 2022 at 12:43 PM
To: tom petch
Cc: "lsr@ietf.org" , "net...@ietf.org" , "Rob
Wilton (rwilton)"
Subject: Re: [netmod] [Lsr] I-D Action:
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
On Wed, Apr 13, 2022 at 2:22 AM tom
All
I support Shraddha’s Any bit draft as I think of the change as am
optimization of existing ASLA RFC 8918 and 8919 taking into account
practical deployment considerations when the application specific attribute
differs and having to set the SABM / UDABM bit mask on every link on the
network.
Hi Ketan,
My fault. When I initially grepped for it, I used “8402” instead of “8042” and
did not find it hence the comment ☹
Sorry about that.
Jeffrey
Juniper Business Use Only
From: Ketan Talaulikar
Sent: Wednesday, April 13, 2022 10:06 AM
To: Jeffrey (Zhaohui) Zhang
Cc: Acee Lindem
On Wed, Apr 13, 2022 at 2:22 AM tom petch wrote:
> From: netmod on behalf of Rob Wilton (rwilton)
>
> Sent: 11 April 2022 18:06
>
> Hi all,
>
> Thanks for the comments on this thread so far. It would be nice if we are
> able to come to some sort of rough consensus to a solution.
>
> I think
Hi Jeffrey,
Could you grep for RFC8042 in this draft and then let us know what more is
needed?
Thanks,
Ketan
On Wed, Apr 13, 2022 at 7:18 PM Jeffrey (Zhaohui) Zhang
wrote:
> Hi,
>
>
>
> I just noticed this draft, and I would like to refer to
> https://datatracker.ietf.org/doc/html/rfc8042
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.
Just my 2c
Thanks,
Ketan
On Wed, Apr 13, 2022 at 2:35 PM
Hi,
I just noticed this draft, and I would like to refer to
https://datatracker.ietf.org/doc/html/rfc8042 "OSPF Two-Part Metric".
If this has been discussed before, please point me to an existing email thread.
It seems that in the LAN case, the two-part metric mechanism would work better.
Hi Tom,
Please see inline ...
> -Original Message-
> From: tom petch
> Sent: 13 April 2022 10:22
> To: Rob Wilton (rwilton) ; net...@ietf.org;
> lsr@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-
> yang-10.txt
>
> From: netmod on behalf of Rob
From: netmod on behalf of Rob Wilton (rwilton)
Sent: 11 April 2022 18:06
Hi all,
Thanks for the comments on this thread so far. It would be nice if we are able
to come to some sort of rough consensus to a solution.
I think that there is consensus that the YANG type ip-address (and the
Hi Robert,
Please check inline below with KT4.
On Wed, Apr 13, 2022 at 1:31 PM Robert Raszuk wrote:
> Hi Ketan,
>
> > KT2> I see the primary use case for IP FlexAlgo (or another data plane)
>> > to be that the data plane is used by itself. In the (rare?) case where
>> > multiple data planes
Hi Ketan,
please see inline (##PP4):
On 13/04/2022 10:52, Ketan Talaulikar wrote:
Hi Peter,
I will not press this point further if I am the only one that finds this
complexity without any benefit. :-)
Please check inline below for some clarifications with KT3.
On Wed, Apr 13, 2022 at
Hi Peter,
I will not press this point further if I am the only one that finds this
complexity without any benefit. :-)
Please check inline below for some clarifications with KT3.
On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak wrote:
> Hi Ketan,
>
>
> please see inline (##PP3):
>
> On
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 are
> > > named the way they are) is to introduce ip-address-with-zone and to
>
Hi Ketan,
> KT2> I see the primary use case for IP FlexAlgo (or another data plane)
> > to be that the data plane is used by itself. In the (rare?) case where
> > multiple data planes are required to coexist, it is simpler both from
> > implementation and deployment POV to use different algos. It
Hi Ketan,
please see inline (##PP3):
On 13/04/2022 06:00, Ketan Talaulikar wrote:
Hi Peter,
Please check inline below with KT2. I am trimming everything other than
the one point of continuing debate.
> >
> > 2) The relationship between the algo usage for IP FlexAlgo
18 matches
Mail list logo
