From nobody Tue Nov 10 05:51:22 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F003A0E5D for ; Tue, 10 Nov 2020 05:51:20 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypGnIdSNFF1E for ; Tue, 10 Nov 2020 05:51:18 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796603A0E5E for ; Tue, 10 Nov 2020 05:51:18 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id y9so4961352ilb.0 for ; Tue, 10 Nov 2020 05:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0Ri1gmCCEaLiFTxy3xqOKj3d6lyQfcbpTPRRu7A0500=; b=qm7xOnFFHMow7dj0rlmt1ca8baLYmYN+aDK7WNcRDIZKoe+KZpgZU2jm/mT3MyKieX tRK1jsMH0nwq9bQM1CRHa9fuk99I2KntKYvw1wKynvEu/L2IRssnlLs0VzsxcfoNAahg WihHzzO2z3+R8gyL6z+AvJeiyTgObqdUbOsiI8Rst4XGIeVNjreq7EW9rUjslm2GmMnM 9mosVcm1sp5OhXtMSZoumKWTfZOKKHaDQviduaSR90MPAe4yA8Fm4hZhdj3rTRkFI4OP IjXVIHisJM493+WPUw2ikfjHNgw7vDfoMNYlnTysvqdJU0Kv77xRr29YSbXkA2rhRibn YgIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0Ri1gmCCEaLiFTxy3xqOKj3d6lyQfcbpTPRRu7A0500=; b=occ5rz6a642eCGRVLHKG/tsi78Yp52bO7S74BWy8l3959Suq9zuvnwIcYyAEcJ1N+W 2Gi/Ty/S8691lE6mTpqUGBCKMce2r5EhJkDhd9n6K46ehPGfuWDdUxeNhHqh3xn0NBO/ 5v3l3XEZOg5Q0pM4e1vyofOIE3IIX7wPr1O23/a0PywyN++WhYZMGoAoh0GxxgDehl2N 1YJMFza8+OJNeaxHTvlte5yVfLyJlJnE6iP02qU6oYjmhwy4zKTvLMRGtETVCgV3rdzX aIbHntOaZA7F4uyXd8hvJQp0etQgL1ESORsviInDfGbEsHP3YX1wskje/WytGRswSX2N FQeQ== X-Gm-Message-State: AOAM5317KKiylJzNixi/3xoEghO4wGKeNPLUP0AF+D1RCw9yfLnhBWXW Ms4dgKNcftLesVOgkRjYcYuJ1vwKhKqXWpYXWDzKy9SgK1/x4ueq X-Google-Smtp-Source: ABdhPJw0ZC9HBYSXQnZBlem1DbMCI8Oh6/3OqJSJQMcdS6RPBl9j4MpwvATyUcUgcREEu26vbaWxgjYPSGryQu8xNbs= X-Received: by 2002:a92:cc52:: with SMTP id t18mr5015673ilq.124.1605016277587; Tue, 10 Nov 2020 05:51:17 -0800 (PST) MIME-Version: 1.0 References: <045d01d6b0c7$c5eb4900$51c1db00$@ndzh.com> In-Reply-To: From: Dhruv Dhody Date: Tue, 10 Nov 2020 19:20:41 +0530 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: Susan Hares , idr wg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 13:51:20 -0000 Hi Ketan, Thanks for a quick reply and taking my comments into consideration. On Tue, Nov 10, 2020 at 4:55 PM Ketan Talaulikar (ketant) wrote: > > Hi Dhruv, > > Thanks for your thorough review and feedback/comments. Please check inlin= e below. > > -----Original Message----- > From: Idr On Behalf Of Dhruv Dhody > Sent: 10 November 2020 15:31 > To: Susan Hares > Cc: idr wg > Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-0= 4.txt (11/1/2020 to 11/16/2020) > > Hi Sue, WG, > > The SRv6 work for BGP-LS is important and I support its publication. I do= have some comments which I hope will improve the I-D: > > Major > - Regarding the various flag fields in the I-D. Should we redefine them h= ere or refer to the IGP documents? I see they match with draft-ietf-lsr-isi= s-srv6-extensions. For the SR-MPLS draft (in > draft-ietf-idr-bgp-ls-segment-routing-ext) the approach was to use a refe= rence to the ISIS draft. > [KT] The base RFC7752 has had the odd convention of providing reference t= o ISIS specifications for TLVs even though the information was applicable t= o both IGPs. The draft-ietf-idr-bgp-ls-segment-routing-ext points to the re= spective ISIS, OSPFv2 and OSPFv3 specs for the flags field - it does not po= int alone to ISIS drafts. Traditionally, there have been minor variations b= etween the IGPs causing the flags to be different for each IGPs in BGP-LS. = We've received feedback from the consumer applications of BGP-LS informatio= n to abstract and provide a consistent data across IGPs (where possible). T= hat is the reason why the flags are being defined in the BGP-LS specificati= ons here. If we look at RFC7752, we've had a union of flags for TLVs like N= ode Flags Bits TLV and IGP Flags TLV. > Few Observations - - My main concern is to avoid re-definition and duplication; if you don't want to point to the flag fields as done in draft-ietf-idr-bgp-ls-segment-routing-ext, you can still point to the meaning of each of the flags where they were originally defined (unless there is any change in the context of BGP). - BTW are you making a change in RFC7752bis to handle this concern? Is it right to do this only for SRv6? > - Section 2 provides a good summary; for ease of reader, can you add a fo= rward reference to sections where each of the TLV is defined in this I-D? > [KT] This will result in each line of this summary pointing to at least o= ne or two (if not more) forward references and IMHO will affect readability= . The section headings themselves are organized based on the summary and so= are forward references really necessary? > The new RFC v3 format makes a pretty HTML rendering. Having a forwarding reference allows a reader to use the reference links to jump directly without looking at the ToC. IMHO it is useful, the readability is a concern perhaps in plain text, but even there section numbers help rather than looking for section headings. > - Section 2, 2nd last paragraph, should this be normative regarding the d= ifferent behaviour for underlying IGP and BGP-EPE? > [KT] I am not sure that I understand. Could you please clarify exactly wh= at normative text is required here? > I meant, think of using RFC2119 keywords - MUST/SHOULD etc. > - Section 4.1, need reference for IGP Algorithm Type registry > [KT] The text already points to the IANA IGP Algorithm Type registry wher= e there are references for the spec that is introducing the new algorithm t= ypes. > A reference to RFC8665 is useful, as that is the place where this registry is created. > - Section 4.2, add the tag Neighbor ID in the figure as well to match the= text > [KT] Ack > > - Section 6, we should say Protocol-ID is from RFC 7752, of which the fol= lowing are applicable for SRV6. > [KT] RFC7752 does not introduce BGP - it was introduced by the BGP EPE dr= aft. So perhaps we can just refer to the IANA registry for Protocol IDs ins= tead and remove the list from this section in the draft? > You can say something like -> the Protocol-ID registry was created by [RFC7752] and then extended by other BGP-LS extensions. The following values are valid in SRv6 - > - Various MUST conditions in the draft, but no idea what happens when the= y are not met. Is this the legacy issue with RFC7752 and we need to wait fo= r the RFC7752bis? > [KT] Ack - the fault management clarifications are being introduced in RF= C7752bis. In brief, BGP-LS does not perform semantic validation of the TLVs= ' contents. > Worth adding some text, I am sure directorate/AD reviews might have the same concern. Thanks! Dhruv > Nits > - s/Segment Routing IPv6 (SRv6)/Segment Routing over IPv6 (SRv6)/ > - Expand SR, NLRI, MSD, DR, DIS, on first use. > [KT] Ack - will fix this. > > Thanks, > Ketan > > Thanks! > Dhruv > > On Mon, Nov 2, 2020 at 8:55 AM Susan Hares wrote: > > > > This begins an IPR call and a 2 week WG LC for > > > > draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1 to 11/16/2020) > > > > > > > > You can access the draft at: > > > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/ > > > > > > > > This draft focus on the BGP-LS support for SRv6. > > > > Spring has proposed the SRv6 support in RFC8402 > > > > (see section 3.1.3 for mechanisms and section 8.2 for > > > > Security considerations). > > > > > > > > There are two implementations: Cisco and GoBGP > > > > You can see the implementation report at: > > > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20im > > plementations > > > > > > > > In your responses, please consider the following questions: > > > > a) Is the SRv6 technology ready for deployment or > > > > are there known issues? > > > > > > > > b) Will SRv6 provide valuable support for > > > > deployments of BGP-LS in support of source routing > > > > (aka spring)? > > > > > > > > c) Is this draft ready for publication? > > > > > > > > If you know of additional implementations, please send > > > > a note to the idr chairs with the information or > > > > respond to this email. > > > > > > > > Cheers, Susan Hares > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr