Re: [Isis-wg] [Bier] early AD review of draft-ietf-bier-isis-extensions-05

Alia Atlas <akatlas@gmail.com> Thu, 30 November 2017 17:27 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427B6128896; Thu, 30 Nov 2017 09:27:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Dpx9Ptx5UBBs; Thu, 30 Nov 2017 09:27:19 -0800 (PST)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 5C7D8120727; Thu, 30 Nov 2017 09:27:19 -0800 (PST)
Received: by mail-oi0-x230.google.com with SMTP id s9so5335537oie.5; Thu, 30 Nov 2017 09:27:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tN25NUCejbugm4vKioH7kgWgjIuagF5Cr2i8R8l17nM=; b=sVXuW2P9zKzbc0e9a8SpuA/M4ajVndRJ/WcgtCw92vq5k5ypLLencLNnsuAybfAG9F k+/9jrrOrhE6K06iCeXjDzdBbqTXZHIigOFYb2xpqySPRWL+W6f7oeYkc/9Pl6QT8LNH eQ5C8lvtYGyGsRiq/JUekcntSYBE//JKnmZk44j9cLvq5GHXZ+FdHX/7tJDeTrzAg6cy yRywgsGndGgmlBypBASJXKbHV+S6TlWZkBsj1V+LmVve8Fz0msUH2XumiCF9YFEh3cxl uj7637pD/d4zjjIIuK/7tus/wkc3oXl5CeNRKXGvAIsE7C3LpTs0GWCRqulkKmEYm7oG xSWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tN25NUCejbugm4vKioH7kgWgjIuagF5Cr2i8R8l17nM=; b=MF4fsm3Yo41ti9n4dJI8VDVXGWZmdqAT5J9zqzMI6Syzb0r7OnNyvcoxxRqn/Oi+6z +nAq3ZqJ/VEXjk6Ut6d/tSeSPg5Mrc3pcVO+6Uq9hQ2yK4+O1tGETg5tejSEbGiJFEaN /+iTvV6nCh4ZTkI1rMBEtk/W/YbApNb2yvM9zddv/iMw6mQ/oI/Xw2LHHYZN8zibomLt 8ilAYgf1VfKQGmVyOq2nk7EZS9yDRFbB2hhfd7JkdBPQFb3IwXncvMZJ/gdS84ZSFLmG mxvsK5hQXESIBByI62m1WA4KszJr4AgLStd9twHI1QdvBPykF7taN1nlFNXf2z91OAAR 6UDw==
X-Gm-Message-State: AJaThX4bg+MSzcKuRXZjLPAaXSlVk/F3fCwjHKccaA+LKEpakmORbgOu 0LskLK2JJpQ/fvrV4bRyyI5WLNW/tRWLbDjdSUA=
X-Google-Smtp-Source: AGs4zMZBcqfHEnJi7i7EAElAKtfdvxzgyrZJuB4BkN9cEQj2rHAUbW/hCB+wAgH8Zso0NyVrEd3uxUQRMhGuTOnyGtk=
X-Received: by 10.202.85.210 with SMTP id j201mr4921051oib.5.1512062838498; Thu, 30 Nov 2017 09:27:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.0.143 with HTTP; Thu, 30 Nov 2017 09:27:17 -0800 (PST)
In-Reply-To: <CABFReBo_A6=XJwi6jd3WrKy-kGBZhn4sOTaqz32vGTzi7=tOEg@mail.gmail.com>
References: <CAG4d1rcBQDVQBYJ3nu8S4t_u_90UaCBR_KYVErO=dwz=3KRFzQ@mail.gmail.com> <897c30c09e00424a8fcced735162bf97@XCH-ALN-001.cisco.com> <FC1A013B-967C-4075-8607-8552F9579719@juniper.net> <CABFReBo_A6=XJwi6jd3WrKy-kGBZhn4sOTaqz32vGTzi7=tOEg@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Thu, 30 Nov 2017 12:27:17 -0500
Message-ID: <CAG4d1rc9hGWUq+Mun2VFUBBw4c=d1YOFK1-4bB0rO8H+NZssNA@mail.gmail.com>
To: Greg Shepherd <gjshep@gmail.com>
Cc: Antoni Przygienda <prz@juniper.net>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "bier@ietf.org" <bier@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-bier-isis-extensions@ietf.org" <draft-ietf-bier-isis-extensions@ietf.org>
Content-Type: multipart/alternative; boundary="001a113de9765dee13055f369094"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/fQT3jSBNowKWNAibK6bz7t1W6wg>
Subject: Re: [Isis-wg] [Bier] early AD review of draft-ietf-bier-isis-extensions-05
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Nov 2017 17:27:22 -0000

Sounds good to me.

Regards,
Alia

On Thu, Nov 30, 2017 at 12:24 PM, Greg Shepherd <gjshep@gmail.com> wrote:

> I believe we are at a point of agreement for draft-ietf-bier-isis-extensions,
> and should be ready for WGLC. Do we have agreement here?
>
> Thanks,
> Greg
>
> On Sun, Oct 22, 2017 at 9:24 AM, Antoni Przygienda <prz@juniper.net>
> wrote:
>
>> Les, thanks for the work.
>>
>>
>>
>> Alia, given some of the changes is a 7 days limited (i.e. only pertaining
>> to changes introduced) WG LC appropriate?
>>
>>
>>
>> --- tony
>>
>>
>>
>>
>>
>> <ginsberg@cisco.com> spake:
>>
>>
>>
>> Alia –
>>
>>
>>
>> A new version of the draft has been posted which addresses your comments.
>>
>>
>>
>> Sorry this was  not completed as quickly as you hoped, but reviewing the
>> comments/changes led to some lively discussion among the co-authors – it
>> took us a while to reach consensus on the changes.
>>
>>
>>
>> Some responses inline.
>>
>>
>>
>> *From:* Alia Atlas [mailto:akatlas@gmail.com]
>> *Sent:* Tuesday, September 26, 2017 4:09 PM
>> *To:* bier@ietf.org; isis-wg@ietf.org; draft-ietf-bier-isis-extension
>> s@ietf.org
>> *Subject:* early AD review of draft-ietf-bier-isis-extensions-05
>>
>>
>>
>> I have done an early AD review of draft-ietf-bier-isis-extensions-05 in
>> preparation for receiving a request to publish it. First, I would like to
>> thank the authors - Les, Tony, Sam and Jeffrey - for their work on this
>> document.
>>
>>
>>
>> In my ideal timing, this draft would be updated and ready for IETF Last
>> Call by Oct 5 so that it could reach the IESG telechat on Oct 26
>> with draft-ietf-bier-mpls-encapsulation and draft-ietf-bier-ospf-bier-extensions.
>> It would be great to have 4 drafts approved for RFC publication - or even
>> some RFCs!  If we can't make this timeline, then it'll add at least a month
>> or more.
>>
>>
>>
>> I do see a number of issues to be addressed.
>>
>>
>>
>> Major:
>>
>>
>>
>> 1) Sec 4.1: "At present, IS-IS support for a given BIER domain/sub-domain
>> is
>>    limited to a single area - or to the IS-IS L2 sub-domain."
>>
>>    Why is there this limitation?  Having just reviewed the ospf draft,
>> the detail needed to handle inter-area seems straightforward there.  It'd
>> be a pity to have different support in ISIS and OSPF...
>>
>> I didn't see anything about such a limitation in the bier-architecture or
>> bier-mpls-encapsulation drafts, so I'm startled to see it here.
>>
>>
>>
>> At the very least, some explanation of why IS-IS can't handle inter-area
>> and the implications for deployments is needed.
>>
>>
>>
>> In Sec 4.2, this is enforced by "BIER sub-TLVs MUST NOT be included when
>> a prefix reachability
>>       advertisement is leaked between levels." but I don't see any
>> reasoning for why the BIER sub-TLVs couldn't be included...
>>
>>
>>
>> *[Les:] We have removed the restriction.*
>>
>>
>>
>> 2) Sec 5.1: This section has concern about restricting the advertisement
>> of BIER information in IS-IS for scalability - but it doesn't discuss at
>> all when a router would stop advertising the BIER sub-TLVs.  It feels like
>> the section is hunting for a bit of a manageability or operational
>> considerations section.  I'm not comfortable with the interoperability
>> issues posed by not indicating what triggers should cause advertisements or
>> withdrawals.   Receiving an advertisement from a BFER seems like a
>> reasonable trigger to me, since it indicates an active receiver for the
>> <MT, SD>.
>>
>>
>>
>> *[Les:] This section has been removed.*
>>
>>
>>
>> 3) Sec 5.5 contradicts the last paragraph in Sec 2.1.1.1 in
>> draft-ietf-bier-mpls-encapsulation-08 which says" Note that in practice,
>> labels only have to be assigned if they are
>>    going to be used.  If a particular BIER domain supports BSLs 256 and
>>    512, but some SD, say SD 1, only uses BSL 256, then it is not
>>    necessary to assign labels that correspond to the combination of SD 1
>>    and BSL 512."
>>
>>
>>
>> *[Les:] I believe this comment was resolved in the exchange between you
>> and Tony.*
>>
>>
>>
>> 4) Sec 5.6: "A valid BFR-id MUST be unique within the flooding scope of
>> the BIER advertisments."  This doesn't leave scope for expanding to
>> inter-area in the future because the issue is not the flooding scope but
>> rather the distribution.
>>
>>
>>
>> *[Les:] Similarly, this was resolved in the email thread.*
>>
>>
>>
>> 5) Sec 6.1: " The sub-TLV advertises a single <MT,SD> combination
>> followed by
>>    optional sub-sub-TLVs as described in the following sections."
>>
>> The figure and field descriptions do not include the MT-ID.  There is
>> clearly the reserved octet intended for that??
>>
>>
>>
>> *[Les:] Tony has already pointed out that the parent TLV has the MTID.*
>>
>>
>>
>> 6) Sec 6.2:  This section needs to clearly define the relationship
>> between the labels and the Set Index in the specified <MT, SD>.  It's also
>> unclear whether it is better to advertise all the labels ever needed or be
>> able to advertise only labels for a particular sequential number of SIs.
>>  The restriction that only one sub-sub-TLV with the same BitStringLength
>> makes that impossible (but so does the lack of explicit starting SI).
>>
>>
>>
>> *[Les:] Some clarifying text has been added.*
>>
>>
>>
>> 7) Sec 6.3: The values for the Length & Tree Type field need to be
>> clearer after the figure.  Also, is Tree Type an IANA-managed field??  I
>> don't see it in the IANA considerations.  Ca it be different between IS-IS
>> and OSPF?
>>
>>
>>
>> *[Les:]  As you will see, we have deleted the tree type sub-TLV
>> altogether. In its place we inserted a BIER Algorithm (BAR) octet in the
>> BIER Info sub-TLV (replacing the “Reserved” field).  Equivalent changes
>> will be forthcoming in the OSPF draft so the two drafts will remain
>> aligned.*
>>
>>
>>
>> Minor:
>>
>>
>>
>> a) Sec 2: "Invalid BFR-id: Unassigned BFR-id, consisting of all 0s."
>>
>> A clearer definition might be "Invalid BFR-ID: The special value of 0 -
>> used to indicate that there is not a valid BFR-ID"  The same comment
>> applies to "Invalid BMP".
>>
>>
>>
>> *[Les:] Done.*
>>
>>
>>
>> b) Sec 5.7:  Please add some text about dampening the reports of
>> misconfiguration - as usual.
>>
>>
>>
>> *[Les:] Done*
>>
>>
>>
>> Nits:
>>
>>
>>
>> i) Sec 5.1: "supported bitstring lengths MLs "  All the other BIER drafts
>> use the acronym  BSL (BitStringLength).  Consistency is frequently useful
>> for clarity.
>>
>>
>>
>> *[Les:] As this section was removed the issue no longer exists.*
>>
>>
>>
>> ii) Sec 6.2: "Length: 1 octet."   Please specify the value!
>>
>>
>>
>> *[Les:] This sub-TLV was removed, so again the comment no longer applies.*
>>
>>
>>
>> *   Les*
>>
>>
>>
>> Regards,
>>
>> Alia
>>
>> _______________________________________________
>> BIER mailing list
>> BIER@ietf.org
>> https://www.ietf.org/mailman/listinfo/bier
>>
>>
>