Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04

Alia Atlas <akatlas@gmail.com> Fri, 09 February 2018 18:59 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 E331B12D7FC; Fri, 9 Feb 2018 10:59:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 RerNVy3KnDPC; Fri, 9 Feb 2018 10:59:54 -0800 (PST)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 2D0FC12D7EB; Fri, 9 Feb 2018 10:59:44 -0800 (PST)
Received: by mail-oi0-x22d.google.com with SMTP id t78so6847745oih.4; Fri, 09 Feb 2018 10:59:44 -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=ALb53vYED947SjPrUmmQrL1SuKPZJTHh01Aldz18mmY=; b=saIIiJnxfNbyTCP+LZgyDOQXPriixs/DbUwERZdHBLgn1AyUB1EphZYqAdUnDERomc yPJHNzMLmk/W8gfR1fRPQxVtIE8fn8vuQIXPE3409jsHdUIO2qFJuqQhvZhrnTQfs8lK q5hl+ZNefoH02TT29o7MiwQYvM1Ciq2+rlLNBR0LEd3/M8QvmSYq9MXF1etlXj+toW9k 99WYdQqhYKT3UE8B45TyxzcHxXOjK7ILqz+gQGoBYqc0DQFpLRRclAtB/RkBFjfMD/lc 2O1TkzYRi/J5gol4OCVE40ELyeDUaUo8ms9OtFFStF0jGBHywfp2rpsH6SukiK6brJ57 YqmQ==
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=ALb53vYED947SjPrUmmQrL1SuKPZJTHh01Aldz18mmY=; b=BBky/sBdQB/LbNOtKeS/hVpqxlBz0kaB8c5xtvLr/3XlBXL2bUvQNxvi5/9cieeonF he+uT7RhBwk4PMeZjjeavyVpsvbTc66QHKyHKXu4WgxWCAyhltSiSu9KMmfMJjx4/Z9e 8JEgOKqZPjpMtxLNB5WOy6a9iCvkdyBRKZDUgWGJnwyJFS4Z8uZxYeIzvlc0Ah3BtMsz GvqV4/ejHgtkQCLQX78qTLqzLsDNZFGO38tgY4JazyyYvhxzx1tSp+0OQUkO2gDDxHyf TqCDjKU25z9tdg7kjn1TYFUTZq10XHxJ9daJ27EDYzOJr60KA9TAjP/DrGBokTIfEbcu w/YQ==
X-Gm-Message-State: APf1xPCpaXGWozb0Um2oPqTWMqSETeY5HtcNq2w2qmg6vWT2DJet+Kpt HlTzt9SDsUwjPS7gwMQ2p2OCuW58OLjv5csuerw=
X-Google-Smtp-Source: AH8x225llqEIuMG13naD/lb5RXIQbBrPSD6+xThp1KTsObIUlR1FDDTkG5F/4zJGgwPO/OaHJFMur1hSdmrEFrbXJBo=
X-Received: by 10.202.212.70 with SMTP id l67mr2346043oig.43.1518202783342; Fri, 09 Feb 2018 10:59:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.40.246 with HTTP; Fri, 9 Feb 2018 10:59:42 -0800 (PST)
In-Reply-To: <E66A4C2B-7450-4040-9D13-53ACA2B03572@cisco.com>
References: <20170721062741.GA3215@faui40p.informatik.uni-erlangen.de> <CA+wi2hOCZkLeuqnqr-waNMtaex+Pjq3rXzH-HVqJhLkWQUgj_Q@mail.gmail.com> <567fdbe4992c4207b54c77b1ec8cd0cd@XCH-ALN-001.cisco.com> <20170722133419.GA18218@faui40p.informatik.uni-erlangen.de> <37e324dc58454778b70c72255066536f@XCH-RCD-001.cisco.com> <20170725195211.GA7411@faui40p.informatik.uni-erlangen.de> <CABFReBpt088=SC3eBcfFbJ24e_+GkDmvKh05AaQtUmCoaKEG3w@mail.gmail.com> <cd2bcf2853684097a3d21fd20742d4ed@XCH-ALN-001.cisco.com> <CABFReBqEJu5nBMdJm0cmBuUYhatD+JRCpn7TppC-hgV4HGZ3sQ@mail.gmail.com> <CABFReBoBXn-Fc5B+Y9VdfEWC+sY=bLdmDUz3NqO6XXeDgbeW_g@mail.gmail.com> <E66A4C2B-7450-4040-9D13-53ACA2B03572@cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 9 Feb 2018 13:59:42 -0500
Message-ID: <CAG4d1rfu-iUoX4uh+wE2xLjMWidq-JSknb38jsfsP_946fBmWw@mail.gmail.com>
To: "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>
Cc: "gjshep@gmail.com" <gjshep@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "bier@ietf.org" <bier@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>, Toerless Eckert <tte@cs.fau.de>, Christian Hopps <chopps@chopps.org>, "Hannes Gredler (hannes@gredler.at)" <hannes@gredler.at>
Content-Type: multipart/alternative; boundary="001a113deff49926c70564cc2185"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/3woiL-ExNa64Q3hXioPlSEQTiiE>
Subject: Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04
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: Fri, 09 Feb 2018 18:59:59 -0000

Ice,

The draft is in IETF Last Call.
What is your technical objection to having it go forward as it is?

Regards,
Alia

On Fri, Feb 9, 2018 at 12:13 PM, IJsbrand Wijnands (iwijnand) <ice@cisco.com
> wrote:

> Greg,
>
> I think there is a confusion here, there is no consensus to remove BAR! We
> want to keep it, but might change the format a little...
>
> Sent from my iPhone
>
> On 9 Feb 2018, at 17:49, Greg Shepherd <gjshep@gmail.com> wrote:
>
> Les,
> draft-ietf-bier-isis-extensions still mentions BAR. Is this intentional?
> Then consensus on the thread was to remove BAR.
>
> Greg
>
> On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd <gjshep@gmail.com> wrote:
>
>> Thanks Les.
>>
>> Any other feedback? Looks like the concerns have been addressed. Speak
>> now.
>>
>> Cheers,
>> Greg
>>
>> On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) <
>> ginsberg@cisco.com> wrote:
>>
>>> Greg –
>>>
>>>
>>>
>>> This thread is outdated.
>>>
>>> In V6 of the draft we removed the restriction to limit IS-IS BIER
>>> support to area boundaries – so Toerless’s comment (and my proposed text)
>>> are no longer relevant.
>>>
>>>
>>>
>>> Specifically:
>>>
>>>
>>>
>>> Section 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.”
>>>
>>>
>>>
>>> The above text was removed.
>>>
>>>
>>>
>>> Section 4.2
>>>
>>>
>>>
>>> o  BIER sub-TLVs MUST NOT be included when a prefix reachability
>>>
>>>       advertisement is leaked between levels.
>>>
>>>
>>>
>>> Was changed to
>>>
>>>
>>>
>>> o  BIER sub-TLVs MUST be included when a prefix reachability
>>>
>>>       advertisement is leaked between levels.
>>>
>>>
>>>
>>> This aligns IS-IS and OSPF drafts in this regard.
>>>
>>>
>>>
>>>     Les
>>>
>>>
>>>
>>> *From:* Greg Shepherd [mailto:gjshep@gmail.com]
>>> *Sent:* Thursday, February 01, 2018 2:23 AM
>>> *To:* Toerless Eckert <tte@cs.fau.de>
>>> *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; Tony Przygienda <
>>> tonysietf@gmail.com>gt;; Hannes Gredler (hannes@gredler.at) <
>>> hannes@gredler.at>gt;; bier@ietf.org; isis-wg@ietf.org list <
>>> isis-wg@ietf.org>gt;; Christian Hopps <chopps@chopps.org>
>>>
>>> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>>>
>>>
>>>
>>> Have these changes been reflected in the draft? We're in WGLC but this
>>> discussion needs to come to a conclusion so we can progress.
>>>
>>>
>>>
>>> Greg
>>>
>>>
>>>
>>> On Tue, Jul 25, 2017 at 12:52 PM, Toerless Eckert <tte@cs.fau.de> wrote:
>>>
>>> Thanks, Less, that would be lovely!
>>>
>>> I didn't check the OSPF draft, if its similar state, explanatory text
>>> wold equally be appreciated.
>>>
>>>
>>> On Sun, Jul 23, 2017 at 11:28:08PM +0000, Les Ginsberg (ginsberg) wrote:
>>> > Toerless -
>>> >
>>> > I am thinking to add a statement in Section 4.1 - something like:
>>> >
>>> > "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."
>>> >
>>> > If you believe this would be helpful I will spin a new version
>>> (subject to review/agreement from my co-authors).
>>> >
>>> >    Les
>>> >
>>> >
>>> > > -----Original Message-----
>>> > > From: Toerless Eckert [mailto:tte@cs.fau.de]
>>> > > Sent: Saturday, July 22, 2017 6:34 AM
>>> > > To: Les Ginsberg (ginsberg)
>>> > > Cc: Tony Przygienda; Hannes Gredler (hannes@gredler.at); Greg
>>> Shepherd;
>>> > > bier@ietf.org; isis-wg@ietf.org list; Christian Hopps
>>> > > Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>>> > >
>>> > > Thanks Les
>>> > >
>>> > > When searching various terms in the doc to figure out what happens i
>>> am not
>>> > > sure why i missed this one.
>>> > >
>>> > > But: IMHO, RFCs can not only be the minimum number of words to get a
>>> > > running implementation. It also needs to specify what this
>>> implementation
>>> > > intends to achieve. Otherwise its not possible to do a useful review:
>>> > > The reviewer can to verify whether the spec will achieve what it
>>> claims to
>>> > > achieve is there no definitionn of what it claims to achieve.
>>> > >
>>> > > If i understand ISIS correctly, my reverse engineering of the intent
>>> is:
>>> > >
>>> > > - BIER TLVs stay within single ISIS areas. BFIR and BFER must
>>> therefore be
>>> > >   in the same ISIS area: There is no inter-area BIER traffic possible
>>> > >   with this specification. This is also true for ISIS area 0.
>>> > >
>>> > > - The same BIER sub-domain identifiers can be re-used
>>> > >   across different ISIS areas without any current impact. If these
>>> BFR-IDs
>>> > >   are non-overlapping, then this would allow in the future to create
>>> a single
>>> > >   cross ISIS area BIER sub-domain by leaking TLVs for such a BIER
>>> sub-domain
>>> > >   across ISIS levels. Leakage is outside the scope of this
>>> specificication.
>>> > >
>>> > > I actually even would like to do the following:
>>> > >
>>> > > - If BIER sub-domains are made to span multiple ISIS areas and
>>> BFR-ids
>>> > > assignemtns
>>> > >   are made such that all BFR-ids with the same SI are in the same
>>> ISIS ara,
>>> > >   then it should be in the future reasonably easy to create
>>> inter-area BIER
>>> > >   not by leaking of the BIER TLV but by having BFIR MPLS unicastBIER
>>> packets
>>> > >   for different SIs to an appropriate L2L1 BFIR that is part of the
>>> destination
>>> > > area/SI.
>>> > >   (if you would use SI number that are the same as ISIS area numbers
>>> then
>>> > >    you could probably do this without any new signaling. Not quite
>>> sure if
>>> > >    you can today easily find L1L2 border router for another area via
>>> existing
>>> > >    TLVs).
>>> > >
>>> > >   Alas, this idea will probably be killed because of the BIER
>>> architecture
>>> > >   intent not to engineer SI assignments in geographical fashions to
>>> > >   minimize traffic duplication in the presence of multiple SIs.
>>> > >
>>> > > Cheers
>>> > >     Toerless
>>> > >
>>> > > On Sat, Jul 22, 2017 at 06:03:53AM +0000, Les Ginsberg (ginsberg)
>>> wrote:
>>> > > > Tony/Toerless ???
>>> > > >
>>> > > > There is an explicit statement as to scope:
>>> > > >
>>> > > > <snip>
>>> > > > Section 4.2
>>> > > > ???
>>> > > >    o  BIER sub-TLVs MUST NOT be included when a prefix reachability
>>> > > >       advertisement is leaked between levels.
>>> > > > <end snip>
>>> > > >
>>> > > > Tony seems to have forgotten that we had a discussion about how
>>> BIER
>>> > > might be supported across areas and the conclusion was we did not
>>> know
>>> > > how to do that yet.
>>> > > > (Sorry Tony)
>>> > > >
>>> > > > Note this is ???consistent??? with https://www.ietf.org/id/draft-
>>> ietf-bier-
>>> > > ospf-bier-extensions-07.txt Section 2.5<https://www.ietf.org/id/dr
>>> aft-ietf-
>>> > > bier-ospf-bier-extensions-07.txt%20Section%202.5> - which limits the
>>> > > flooding scope of BIER information to a single area unless it can be
>>> validated
>>> > > that the best path to the prefix with BIER info can be validated to
>>> be to a
>>> > > router which itself advertised the BIER info. This is not something
>>> IS-IS can do
>>> > > since a single IS-IS instance only supports one area and therefore
>>> does not
>>> > > have the Level-1 advertisements of the originating router when that
>>> router is
>>> > > in another area.
>>> > > >
>>> > > > A few more responses inline.
>>> > > >
>>> > > > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Tony
>>> Przygienda
>>> > > > Sent: Friday, July 21, 2017 5:17 AM
>>> > > > To: Toerless Eckert
>>> > > > Cc: Hannes Gredler (hannes@gredler.at); Greg Shepherd;
>>> bier@ietf.org;
>>> > > > isis-wg@ietf.org list; Christian Hopps
>>> > > > Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>>> > > >
>>> > > > Terminology is a bit nits  IMO since the doc is reading clear
>>> enough for
>>> > > someone who read BIER & ISIS. I can reread it or Les can comment
>>> whether
>>> > > we should tighten glossary ...
>>> > > >
>>> > > > With the scope I agree, that got lost and the doc should be
>>> possibly rev'ed
>>> > > before closing LC. Yes, we flood AD wide was the agreement but
>>> something
>>> > > mentioning that this could change in the future is good so we are
>>> forced to
>>> > > give it some thought how that would transition ...
>>> > > >
>>> > > > Thinking further though, in ISIS we have a clean document really.
>>> The  BIER
>>> > > sub-TLVs go into well defined TLVs in terms of flooding scope.
>>> Normal L1-L2
>>> > > redistribution can be used to get the info to all needed places
>>> AFAIS. So
>>> > > maybe nothing needs to be written. I wait for Les to chime in.
>>> > > >
>>> > > > OSPF I would have to look @ scopes again & think whether we need to
>>> > > write something or maybe Peter can comment ...
>>> > > >
>>> > > > --- tony
>>> > > >
>>> > > >
>>> > > >
>>> > > > On Fri, Jul 21, 2017 at 8:27 AM, Toerless Eckert
>>> > > <tte@cs.fau.de<mailto:tte@cs.fau.de>> wrote:
>>> > > > Sorry, past the two weeks, but hopefully  benign textual comments:
>>> > > >
>>> > > > We tried to find an explicit statement about the scope of BIER
>>> TLVs - eg:
>>> > > > are they meant to stay within an area, have some redistribution
>>> across
>>> > > > areas/levels or not.
>>> > > >
>>> > > > Tony said WG agreement was to have these TLV be flooded across the
>>> > > > whole ISIS domain for now (this draft). So an explicit statement
>>> to that
>>> > > effect would
>>> > > > be great (All BIER sub-domains TLVs are flooded across all ISIS
>>> areas/levels,
>>> > > so they span the whole ISIS domain).
>>> > > >
>>> > > > Also, if future work may/should could improve on that maybe some
>>> > > > sentence about that (i guess one could just have ISIS intra-area
>>> BIER sub-
>>> > > domains ?).
>>> > > >
>>> > > > Also: Do a check about possible ambiguity of any generic terms like
>>> > > sub-domain, level, area, topology so that reader that don't know the
>>> > > terminology ofall protocols (ISIS, BIER) by heart can easily know
>>> which
>>> > > protocol is referred to.
>>> > > >
>>> > > > [Les:] There is no mention of ???level??? in the document.
>>> > > > The use of ???sub-domain??? is clearly always associated with
>>> ???BIER???.
>>> > > > ???topology??? is always used as an RFC 5120 topology ??? therefore
>>> > > clearly an IS-IS topology.
>>> > > > There is only one use of the term ???area??? (in Section 5.1).
>>> That text
>>> > > might deserve a bit of clarification given this might be either a
>>> Level 1 area or
>>> > > the Level2 sub-domain. I???ll take a pass at it.
>>> > > > (BTW ??? I am talking about IS-IS area/L2sub-domain Toerless. ???)
>>> > > >
>>> > > > I don???t see that any other clarification is needed ??? but
>>> Toerless ??? if
>>> > > you can point to any specific sentences/paragraphs which you find
>>> confusing
>>> > > - I???ll take a second look.
>>> > > >
>>> > > >    Les
>>> > > >
>>> > > >
>>> > > > I guess there are no BIER level, area or topologies, but still
>>> makes
>>> > > > reading easier if the doc would say "ISIS level", "ISIS area", or
>>> at
>>> > > > least have them in the Terminology section. And probably in
>>> > > > terminology say "domain -> in the context of this document the BIER
>>> > > domain which is also the same as the ISIS domain"
>>> > > > (which i hope is the correct statement, see above).
>>> > > >
>>> > > > Cheers
>>> > > >     Toerless
>>> > > >
>>> > > > _______________________________________________
>>> > > > BIER mailing list
>>> > > > BIER@ietf.org<mailto:BIER@ietf.org>
>>> > > > https://www.ietf.org/mailman/listinfo/bier
>>> > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > We???ve heard that a million monkeys at a million keyboards could
>>> > > produce the complete works of Shakespeare; now, thanks to the
>>> Internet,
>>> > > we know that is not true.
>>> > > > ???Robert Wilensky
>>> > >
>>> > > --
>>> > > ---
>>> > > tte@cs.fau.de
>>>
>>>
>>>
>>
>>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>