Re: Rtgdir last call review of draft-ietf-rtgwg-yang-rib-extend-16

Acee Lindem <acee.ietf@gmail.com> Wed, 10 May 2023 12:20 UTC

Return-Path: <acee.ietf@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B4EC13AE3D; Wed, 10 May 2023 05:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Crd0HqbQLccP; Wed, 10 May 2023 05:20:20 -0700 (PDT)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6312C13AE3C; Wed, 10 May 2023 05:20:20 -0700 (PDT)
Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-61b5b4df8baso58457396d6.1; Wed, 10 May 2023 05:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683721219; x=1686313219; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=t6eMkcR2Su9/0zVMbxLRDwYMEAJyvlslJre2Dg9wNfU=; b=Ro6AJfrXJ0/5D76+dltWpNPf/JEOfoNhGZhUpqjTzruVKrt7SR2NieDyZtY+SIsjva OdAAAgxfxPSjKOhAi2g1OizUUE/HmCJUPXWfMfcoU0OA5DgS5uYGj3lend5FXfet6Dkr Zl6uPk1G5ompo3byO7gxyKQPx72pD9Z+3pQLPjMruNOv/WpJ6YTZU+wLBHHq/GnnXLo4 mbzIzj+uX71YYf3Yn2wA9Fgv2K606vqp2+tC6dvhEipUF7h/IUPfy7tVHXLJtCXSC+6h 9NiJqqAZcaRuivmms3jF5aVExmHnLC0TYJFLKOxbmyi4/5I5v7V769/8ilqpVLcrVU0h cRdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683721219; x=1686313219; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=t6eMkcR2Su9/0zVMbxLRDwYMEAJyvlslJre2Dg9wNfU=; b=OeLalRjW1Osvux1aJ998y3BkgbG7Hggvc4LG9IkC1aYE/TAyKk80XUDWDD+ezP2CqB UqFwd58SaSo/RonExqVyfXKxL6qjspIWHSk3+dY5Dav4tYrONGbifHsVC0aDgG973XLI bE7rMLpHHHxCkQ3Bfq9cWSknrgZoW818DNsGVnv6nRnP7DuxB/1Bg38u3hTY8DISmL1E 7KecSIKK1F/9Q617ppDPY2NWIQHJO9zmGKgFjIaCCVXY4aGoKIe5R8aJEAlTT5GM4FaE 6qLOCLNfyZzUpSOpcYeCwFAz5SP/IUs1L1Piy381Vf3vI9rREqakaQMSlc69vXx4jVD8 ZGEQ==
X-Gm-Message-State: AC+VfDwDL1KvEMmifyQODAo875m/iILPoXbMYMjFAPClNAjFaLDu7YFM BwhlUn1mymgDswkXf11Lqv5S3MKmcUM=
X-Google-Smtp-Source: ACHHUZ6FhiQmX5uxV4xtagq5w7BIEwwT8prbynONsqTKrW0Um7tNAbbeRFrZJ58+NMNgdg+LZCOK/g==
X-Received: by 2002:ad4:5cae:0:b0:61b:5dd6:1f26 with SMTP id q14-20020ad45cae000000b0061b5dd61f26mr24912306qvh.28.1683721219017; Wed, 10 May 2023 05:20:19 -0700 (PDT)
Received: from smtpclient.apple ([136.56.20.4]) by smtp.gmail.com with ESMTPSA id d11-20020a0cb2cb000000b006215cdc1966sm1266qvf.2.2023.05.10.05.20.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2023 05:20:18 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
Subject: Re: Rtgdir last call review of draft-ietf-rtgwg-yang-rib-extend-16
From: Acee Lindem <acee.ietf@gmail.com>
In-Reply-To: <BL0PR05MB56525C3EC4B437B05C350604D4769@BL0PR05MB5652.namprd05.prod.outlook.com>
Date: Wed, 10 May 2023 08:20:07 -0400
Cc: Yingzhen Qu <yingzhen.ietf@gmail.com>, Routing Directorate <rtg-dir@ietf.org>, "draft-ietf-rtgwg-yang-rib-extend.all@ietf.org" <draft-ietf-rtgwg-yang-rib-extend.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6B900AA-01C4-48AC-A2E3-3A13BDA0C428@gmail.com>
References: <168296662458.49135.11152971610183102502@ietfa.amsl.com> <CABY-gOMerNd0=P2zwdt4b=y0_wHUsWqYAi+Q0He38EiYPz0Qeg@mail.gmail.com> <BL0PR05MB56522903F5682207980F1908D46E9@BL0PR05MB5652.namprd05.prod.outlook.com> <CABY-gOPy6kuCeL80USyLtNxZPNeFdStfZ94_n4NHXjH8M2CaKQ@mail.gmail.com> <BL0PR05MB5652FC89143B3977BDB79124D46E9@BL0PR05MB5652.namprd05.prod.outlook.com> <E2D82A4B-407C-4A78-9665-2A7FAB46B7C0@gmail.com> <BL0PR05MB56525C3EC4B437B05C350604D4769@BL0PR05MB5652.namprd05.prod.outlook.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/ZPdrywP3GQ8tQCRxcW-GddbnLp8>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 May 2023 12:20:22 -0000

Hi Jeffrey, 

> On May 9, 2023, at 17:15, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> wrote:
> 
> 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?

The static route definition is read-write so this would need to be supported as a feature since I don’t know anyone who supports this. If someone really wants this, they can do it with a separate augmentation model. There are other static options that are more widely implemented that we haven’t included in the base model. 

I don’t see a requirement given that backup next-hops can be defined via higher preference. I know that you are arguing that this backup isn’t “next-hop specific”. However, if you have ECMP, normally an IGP would use the ECMP as a back up as well (though, I’m aware that options have been implemented to override this). 

Thanks,
Acee



> 
> Thanks.
> Jeffrey
> 
> -----Original Message-----
> From: Acee Lindem <acee.ietf@gmail.com>
> Sent: Thursday, May 4, 2023 10:51 AM
> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> Cc: Yingzhen Qu <yingzhen.ietf@gmail.com>; Routing Directorate <rtg-dir@ietf.org>; draft-ietf-rtgwg-yang-rib-extend.all@ietf.org; last-call@ietf.org; rtgwg@ietf.org
> 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@juniper.net> 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@gmail.com>
>> Sent: Monday, May 1, 2023 5:01 PM
>> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
>> Cc: rtg-dir@ietf.org; draft-ietf-rtgwg-yang-rib-extend.all@ietf.org;
>> last-call@ietf.org; rtgwg@ietf.org
>> 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@juniper.net> wrote:
>> Hi Yingzhen,
>> From: Yingzhen Qu <yingzhen.ietf@gmail.com>
>> Sent: Monday, May 1, 2023 4:46 PM
>> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
>> Cc: rtg-dir@ietf.org; draft-ietf-rtgwg-yang-rib-extend.all@ietf.org;
>> last-call@ietf.org; rtgwg@ietf.org
>> 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@ietf.org> 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