Re: [Last-Call] Opsdir last call review of draft-ietf-lsr-ospf-l2bundles-06

Ketan Talaulikar <> Wed, 28 September 2022 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFC03C15E41C; Wed, 28 Sep 2022 05:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Status: No, score=-7.108 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jfh6HU7WSjgp; Wed, 28 Sep 2022 05:59:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a31]) (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 (Postfix) with ESMTPS id 5B7B2C1524C2; Wed, 28 Sep 2022 05:59:59 -0700 (PDT)
Received: by with SMTP id s12so6365324vkn.11; Wed, 28 Sep 2022 05:59:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=mV+GXCgeV+qtX8mzPgtJrdMRfatoG4knGXh4NvvuG7s=; b=F44yLabkhQ88aJSSkB16zGBHgeSR09IRIU04fOmzZxgrxqaMndjYXDd9vCpl3J4GYD Fq1Qdr36zuAwmOY01p1ZlmodJmxdl1B4sm8NYqVp3ZYy2Pk+7oLHhpJlbIUf1yTXpCCM FMVcCn3cUJjna1vqujLTHOTSkgYtxW6209ofCjyStCKaenpokdApM0Kl6gKIYQGH1/lY 9zGWWihM8vnhoJT8FtnC0/Uoc4pS8iuNxjSpyX03f/0a3tgcwFA6oJCjQRnyFZ13f1vq 8jwGwKww6YhU2YnZ+fExib9au8SRlqtZ7Tn+dqQTwewSF4u8SHFsNYPTpp8JnZPYJpkS TrFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=mV+GXCgeV+qtX8mzPgtJrdMRfatoG4knGXh4NvvuG7s=; b=LxcKQ7apJEZtIJLhlTFiIPObWOgLzjTI/AsmImZA5Rc/lp+0Q1wFEV5t6iYkcif2fX 38zHk9EO3sKQ79oRKd0HzWiYZIJisk9/G8rfkCegsgkmgxZomsaMKXG7FYNfV3eWQI2g ez5SZvcu0+hgd66rs67d3oEL55ZhccBrgWZiby31VfD9asJZgN0EYJ9OaKZlwUNz7im/ fBtfkjphEC3+1Gc8mJuxzWDiP/z2+5OcXvvGYaeBy0ZXiKIBhwGJGujLDaRlmU8CQcos CPcQfN8sDx4lQ8Fd28b43QEtNmj83se//a8s+iXja8AfVdyJs7mr4tEseYtTVFJhFWLg 5gUQ==
X-Gm-Message-State: ACrzQf2H+eWR3+kxBK538btBdExYuXfIa/OMU+50zRzmQlEDy1YWs682 T+aIWGx8KzoiUhJ+d/Y6fXp0fmeQigqxo03yTMRfpqMt
X-Google-Smtp-Source: AMsMyM6w1vn0I8zQJCZv580a30JXgk45d5iTo2Vkpnwib4rwGm2QHK7JIIHJnB/xBWoc2kD662kvnKc8t6fA6vdquGQ=
X-Received: by 2002:ac5:cfdd:0:b0:3a3:449d:7d1f with SMTP id m29-20020ac5cfdd000000b003a3449d7d1fmr14648390vkf.14.1664369998091; Wed, 28 Sep 2022 05:59:58 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ketan Talaulikar <>
Date: Wed, 28 Sep 2022 18:29:46 +0530
Message-ID: <>
To: Dan Romascanu <>
Content-Type: multipart/alternative; boundary="00000000000082d7d105e9bc5630"
Archived-At: <>
Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-lsr-ospf-l2bundles-06
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Sep 2022 13:00:00 -0000

Hi Dan,

Thanks for your review and please check inline below for responses.

On Sat, Sep 24, 2022 at 1:25 PM Dan Romascanu via Datatracker <> wrote:

> Reviewer: Dan Romascanu
> Review result: Has Issues
> Ready with Issues.
> This document defines the protocol extensions for OSPF to advertise the
> link
> attributes of L2 interface bundle members such as instances of a IEEE
> 802.1AX
> Link Aggregation Group (LAG).
> This is a very useful document. It's clear and well-written. Operators that
> deploy OSPF in environments where IEEE 802.1AX or other L2 bundle
> interfaces
> may be present in routers will find this document very relevant.
> My main issue is related to the lack of any operational or management
> considerations. I believe that the following should be mentioned
> explicitly or
> by reference in a short Operational and Manageability Issues section:
> - any backwards compatibility or transition issues at deployment
> - any impact on traffic
> - any configuration parameters and default values
> - management including possible extensions of YANG or MIB modules

KT> These aspects are covered in the introduction section - the last
paragraph and bullet list thereafter. They are not a section in this
document since these aspects are outside the scope of this document. There
are no backward compatibility considerations since this information is
not used for OSPF protocol operations. The configuration of the per member
link attributes may not be even under an OSPF model. Some of them like
link bandwidth may be obtained from the interface model. AFAIR there has
been no requirement or discussion for their inclusion in the IGP models in
the WG even during similar work in ISIS.

> I agree with the issues raised by the Gen-ART reviewer concerning the
> references, with the difference that I believe that [IEEE 802.1AX] should
> remain a Normative Reference. It's a full IEEE 802.1 standard, so
> referencing
> as Normative is fine.

KT> Thanks for the confirmation.

> I would also suggest sending the document for review to the IEEE 802.1 WG
> via
> the IETF-IEEE coordination team.

KT> I am not sure if this is necessary, but I see that John has already
reached out and so we'll wait for feedback on this one.