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

Tony Przygienda <tonysietf@gmail.com> Fri, 09 February 2018 19:05 UTC

Return-Path: <tonysietf@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 002A812D7EB; Fri, 9 Feb 2018 11:05:40 -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 P1LvdKr1ngBb; Fri, 9 Feb 2018 11:05:37 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 4C41412D7E9; Fri, 9 Feb 2018 11:05:36 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id f71so17139477wmf.0; Fri, 09 Feb 2018 11:05:36 -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=J314miT6Ow+IUkU5TMlZFMBWCLK20YhhNOwXRmZZL+8=; b=rN9oHiIw2YCQmDyoKsSnHLBo5YbQ3iZkcAtZC4fPuR2UEtu0yTxdRfAiSKjxtpgqd9 1LcZiZXXhnU3vfEwUlLUtqfAMclXxQfJBdEIwWIIDmTfWRFyVJvssRpUcbFzM0bOiFKf /7vUzBPNiNy8GQVNAcsAsbZGms25LSQbRGayWld7dcxibw6ktNJT9419tKchM/5Nyfje 4fo+7m26RkPEBDDzoKU8bX/ef3M+eyDhvsBsOWdd6PQ9ned9awc0RpNxOwHA/SYP5lm6 ZyRoeOvVb6nzAo8dy/UumSPRZYjFLtIx8BqVVLiaRkKhGuJQaaqcREhERuxwpP4avpzD PCmg==
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=J314miT6Ow+IUkU5TMlZFMBWCLK20YhhNOwXRmZZL+8=; b=UBt/C8sDL/poP45KDM7rGeyGf4dR6Rdmb3nrAQ3uvth2KZnZdE34eCo7dlCPO0RtY4 oElWFu1kIRblAVBD+3WuTr6Nt/BDb1LlrTcFH4E/Ycg4W3Hp8gHputqb/+B/GgWArvCF z+4vloaPk18VySiJXkOMkWEHCSGNREJhKgwdkyDF4g7cN9pPd4eV8I5ZHW4Vw4e4y8XL rHbx4pD0ra1BBmftixiZSfou/KzMBBqgqcpcNP1Hdc5qP69vz6U7EEDK8NYjC+Ws7Su9 dQPdSS5JmQAou7weg1UzirJ4+E1usZ4e2flBpiI0/KcD0hb3bPls+4GKyDdpiQzZLHzz 0j8w==
X-Gm-Message-State: APf1xPBSukz1LSTFfxnkSsJXtZh6T8K7lA5fFd6z9XIqoEVKx4VZPibo 8bpkLx+jsZxZhftnGXJ/d5ys/xsLzXGlzqw0ngg=
X-Google-Smtp-Source: AH8x224706JQ0pePTrgQYsyynNCZJ+Nk80HcirXdN6KyB8mCAOjDaZ0E3+tWBqrybUjwTfsE0h/i7xJy+vym1Sv67wI=
X-Received: by 10.80.206.88 with SMTP id k24mr5132747edj.153.1518203134804; Fri, 09 Feb 2018 11:05:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.182.239 with HTTP; Fri, 9 Feb 2018 11:04:54 -0800 (PST)
In-Reply-To: <CAG4d1rcZnZmbfU3AnLgfCJmOz-dJ0uv8VUZE+BQ9Qq3B=7DgZg@mail.gmail.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> <CA+wi2hNOf=UZja29OVDGWJMvULoyJP7Uj_OnZYVakNiX0-59Aw@mail.gmail.com> <CAG4d1rcZnZmbfU3AnLgfCJmOz-dJ0uv8VUZE+BQ9Qq3B=7DgZg@mail.gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Fri, 9 Feb 2018 11:04:54 -0800
Message-ID: <CA+wi2hNrQV+gyQS_ts-38w2OWYOkTXUy-Q3b0FAGKaztE8D+QQ@mail.gmail.com>
To: Alia Atlas <akatlas@gmail.com>
Cc: Greg Shepherd <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="94eb2c1b26d48c087f0564cc36e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/Z8gpKjJWi_6I45qxEaEbfTC4ql0>
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 19:05:41 -0000

Les has the diff, I'd expect him to publish any minute to the list ... The
encaps was a real defect, the rest is just tightening down the
language/spec where it was too loose/too strict.

OSPF still needs update with conversion TLV removed, same paragraph on
encaps could be useful. I hope Greg pinged Peter ...

thanks

tony

On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas <akatlas@gmail.com> wrote:

> On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda <tonysietf@gmail.com>
> wrote:
>
>> Went last nits with Les, we found one issue (encaps section was wrong,
>> need to look @ OSPF as well) and basically tightened language in few places.
>>
>
> K - please get that  out with the details of changes to the list.  I did
> my AD review back in Oct and looked at the differences before issuing
> IETF Last Call.
>
> I look forward to reviewing the minor changes.
>
> Regards,
> Alia
>
>
>> tony
>>
>> 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
>>
>>
>