Hi Acee,
For argument sake (this is non-blocking), I don't see difference between static routes and protocol-learned routes. Why would protocol-learned routes need to have nexthop-specific backup while static routes don't?
Thanks.
Jeffrey
-----Original Message-----
From: Acee Lindem <acee.ietf@xxxxxxxxx>
Sent: Thursday, May 4, 2023 10:51 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@xxxxxxxxxxx>
Cc: Yingzhen Qu <yingzhen.ietf@xxxxxxxxx>; Routing Directorate <rtg-dir@xxxxxxxx>; draft-ietf-rtgwg-yang-rib-extend.all@xxxxxxxx; last-call@xxxxxxxx; rtgwg@xxxxxxxx
Subject: Re: Rtgdir last call review of draft-ietf-rtgwg-yang-rib-extend-16
[External Email. Be cautious of content]
Hi Jeffrey,
> On May 1, 2023, at 5:05 PM, Jeffrey (Zhaohui) Zhang <zzhang@xxxxxxxxxxx> wrote:
>
> Hi Yingzhen,
> I can go with that if that’s what the authors/WG’s preference, but my preference would be to cover it in the base specification itself. What’s the harm?
> Anyway, this is not a blocking comment.
The way the backup static route use case is handled is by configuring multiple next-hops with different preferences. This is one of the most useful extensions provided by this augmentation.
Thanks,
Acee
> Thanks.
> Jeffrey
> From: Yingzhen Qu <yingzhen.ietf@xxxxxxxxx>
> Sent: Monday, May 1, 2023 5:01 PM
> To: Jeffrey (Zhaohui) Zhang <zzhang@xxxxxxxxxxx>
> Cc: rtg-dir@xxxxxxxx; draft-ietf-rtgwg-yang-rib-extend.all@xxxxxxxx;
> last-call@xxxxxxxx; rtgwg@xxxxxxxx
> Subject: Re: Rtgdir last call review of
> draft-ietf-rtgwg-yang-rib-extend-16
> [External Email. Be cautious of content] Hi Jeffrey, Considering
> this is not commonly used, I'd suggest if someone really needs it they can do an easy augmentation using the grouping defined in this draft.
> Thanks,
> Yingzhen
> On Mon, May 1, 2023 at 1:52 PM Jeffrey (Zhaohui) Zhang <zzhang@xxxxxxxxxxx> wrote:
> Hi Yingzhen,
> From: Yingzhen Qu <yingzhen.ietf@xxxxxxxxx>
> Sent: Monday, May 1, 2023 4:46 PM
> To: Jeffrey (Zhaohui) Zhang <zzhang@xxxxxxxxxxx>
> Cc: rtg-dir@xxxxxxxx; draft-ietf-rtgwg-yang-rib-extend.all@xxxxxxxx;
> last-call@xxxxxxxx; rtgwg@xxxxxxxx
> Subject: Re: Rtgdir last call review of
> draft-ietf-rtgwg-yang-rib-extend-16
> [External Email. Be cautious of content] Hi Jeffrey, Thanks for the
> review, please see my answers below.
> Thanks,
> Yingzhen
> On Mon, May 1, 2023 at 11:43 AM Zhaohui Zhang via Datatracker <noreply@xxxxxxxx> wrote:
> Reviewer: Zhaohui Zhang
> Review result: Has Issues
>
> I have the following one nit comment and one question:
>
> augment "/rt:routing/rt:ribs/rt:rib/"
> + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"
> + "rt:next-hop-list/rt:next-hop-list/rt:next-hop"
> {
> description
> "Augment the multiple next hops with repair path.";
> uses repair-path;
> }
>
> The description is slightly misleading. It is to agument a single
> next-hop in the next-hop-list, not "multiple next hops".
> [Yingzhen] how about: "Augment the next-hop with a repair path."
> Zzh> Good.
> Shouldn't the repair path be applicable to static routes as well?
> [Yingzhen]: Theoretically you can have a repair-path for a static route, but have you seen this in deployment?
> Zzh> Whether anyone implemented/deployed it that way, I think it’s quite reasonable and desired to have it covered in the spec. For example, a static route could be using if1 by default but if2 as backup (in case if1 is down).
> Zzh> Jeffrey
> Juniper Business Use Only
>
> Juniper Business Use Only
Juniper Business Use Only
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
