Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04
IJsbrand Wijnands <ice@cisco.com> Mon, 12 February 2018 20:58 UTC
Return-Path: <ice@cisco.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 56A58126FDC; Mon, 12 Feb 2018 12:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.8
X-Spam-Level:
X-Spam-Status: No, score=-6.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=cisco.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 04Hb5ezKfu9F; Mon, 12 Feb 2018 12:58:19 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EEA126B6E; Mon, 12 Feb 2018 12:58:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=182889; q=dns/txt; s=iport; t=1518469098; x=1519678698; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=iKLnWPSsm0h+dmtwR5Ny44pgxEK03BW1RETXMI0SAec=; b=c9RiZYIiBIId8BznyhLKWG0WanhXQvOa7eBP9P/Mlcef3CPsHj3OuilQ sKL81Y5lfDOdXQkU2ADJ/HlmJgyNn3K9xYJgGYfLUavm+XW2Mw5nevx2p dMwR5u/y2c92vH2kJlbQ4C8wdnqAoc76Cpm07+cIvtjpVe0OGihvqgqtv k=;
X-Files: PastedGraphic-6.png : 43631
X-IronPort-AV: E=Sophos;i="5.46,503,1511827200"; d="png'150?scan'150,208,217,150";a="1980224"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2018 20:58:16 +0000
Received: from ams-iwijnand-8813.cisco.com (ams-iwijnand-8813.cisco.com [10.60.202.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1CKwGIv018486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Feb 2018 20:58:16 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_39532C7C-18B1-4952-AE83-4C1DC072F60D"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: IJsbrand Wijnands <ice@cisco.com>
In-Reply-To: <771dbad8841b42ac8ea3012dc73ef33b@XCH-ALN-001.cisco.com>
Date: Mon, 12 Feb 2018 21:58:20 +0100
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "bier@ietf.org" <bier@ietf.org>, Peter Psenak <ppsenak@cisco.com>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Message-Id: <CC1CC82E-E134-4931-9735-07A0D0E64997@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> <CA+wi2hNOf=UZja29OVDGWJMvULoyJP7Uj_OnZYVakNiX0-59Aw@mail.gmail.com> <CAG4d1rcZnZmbfU3AnLgfCJmOz-dJ0uv8VUZE+BQ9Qq3B=7DgZg@mail.gmail.com> <CA+wi2hNrQV+gyQS_ts-38w2OWYOkTXUy-Q3b0FAGKaztE8D+QQ@mail.gmail.com> <CABFReBoWZeQxnOCERr9EVykE5dY8p04KQT=JsDqk2eN2Q9p_2g@mail.gmail.com> <CA+wi2hPtxa_Z7VS6Hnj5Y4iQG3RUx7GP6exkf9o4ZcQr2eU_ig@mail.gmail.com> <5A81ABAC.107@cisco.com> <69EEC1F9-3077-4260-BB7A-66F0AEB3357D@cisco.com> <CA+wi2hO0Z PS=3aNY_Et1ChRhzQVJvr1dPiB-ugiC6iGDNpfyfA@mail.gmail.com> <DC7DFF2A-C986-4EA3-A701-6C80C867560B@cisco.com> <CDCE115D-C3AD-47DA-9993-6AC0BD88ED2D@cisco.com> <771dbad8841b42ac8ea3012dc73ef33b@XCH-ALN-001.cisco.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/C2QZDF3UBYKwx_oeM94Y_LBzWJg>
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: Mon, 12 Feb 2018 20:58:23 -0000
Les,
> Perhaps the thread is too long and you have gotten confused. J
Maybe :-), but...
> The point being discussed now is support for multiple encapsulation types (BSL conversion was mentioned in the thread – but it is NOT the subject being discussed at the moment).
I got that, it was removed after a long debate sometime back.
>
> In latest IS-IS BIER draft we changed:
>
> > All routers in the flooding scope of the BIER TLVs MUST advertise the
> > same encapsulation for a given <MT,SD>. A router discovering
> > encapsulation advertised that is different from its own MUST report a
> > misconfiguration of a specific <MT,SD>. All received BIER
> > advertisements associated with the conflicting <MT, SD> pair MUST be
> > ignored.
> >
> > "
> >
> > to
> >
> > "
> >
> > Multiple encapsulations MAY be advertised/supported for a given
> > <MT,SD>. Clearly, however, there MUST be at least one encapsulation
> > type in common in order for a BIER encapsulated packet to be
> > successfully forwarded between two BFRs.
> >
>
> Point has been made that this really belongs in the architecture RFC, but since it isn’t there it may make sense for the IGP drafts to mention it.
Below is taken from "6.10.1. BitStringLength Compatibility Check” RFC 8279, does this not cover it?
****
The combination of sub-domain S and Imposition BitStringLength L
passes the BitStringLength Compatibility Check if and only if the
following condition holds:
Every BFR that has advertised its membership in sub-domain S has
also advertised that it is using Disposition BitStringLength L
(and possibly other BitStringLengths as well) in that sub-domain.
(If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
being used, this means that every BFR that is advertising a label
for sub-domain S is advertising a label for the combination of
sub-domain S and Disposition BitStringLength L.)
If a BFIR has been provisioned to use a particular Imposition
BitStringLength and a particular sub-domain for some set of packets,
and if that combination of Imposition BitStringLength and sub-domain
does not pass the BitStringLength Compatibility Check, the BFIR
SHOULD log this fact as an error.
****
Thx,
Ice.
>
> In the case of IS-IS, because earlier versions of the draft had an explicit statement which we now consider too limiting, it made sense to make an explicit statement of the more flexible behavior.
>
> In the case of OSPF, the overly restrictive text was never present, so it is more debatable as to whether the clarifying statement is needed – but doing so keeps the drafts in sync.
>
> Still, the “right solution” would be to have the statement in RFC 8279 – but a bit late for that.
>
> Les
>
>
> From: IJsbrand Wijnands (iwijnand)
> Sent: Monday, February 12, 2018 12:05 PM
> To: Acee Lindem (acee) <acee@cisco.com>
> Cc: Tony Przygienda <tonysietf@gmail.com>; Les Ginsberg (ginsberg) <ginsberg@cisco.com>; bier@ietf.org; isis-wg@ietf.org list <isis-wg@ietf.org>; Peter Psenak (ppsenak) <ppsenak@cisco.com>
> Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
> Folks,
>
> I would say its wrong to try and fix the BIER architecture by adding this into the IGP drafts. The IGP is a pass-through for the BIER information, and adding this text seems to imply that the IGP now needs to become BIER aware in order to detect and trigger notifications of encapsulation incompatibilities.
>
> The BIER architecture RFC 8279 has section 6.10 "Use of Different BitStringLengths within a Domain”, what is missing in that section that would justify the IGP to become aware of BitStringLength differences? IMO everything is covered.
>
> Thx,
>
> Ice.
>
>
> On 12 Feb 2018, at 19:33, Acee Lindem (acee) <acee@cisco.com> wrote:
>
> Hi Tony,
> I agree that since architecture has been published, it would not hurt to add the 5.2 text to the IGP documents.
> Thanks,
> Acee
>
> From: Tony Przygienda <tonysietf@gmail.com>
> Date: Monday, February 12, 2018 at 12:13 PM
> To: Acee Lindem <acee@cisco.com>
> Cc: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "bier@ietf.org" <bier@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
> Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
> Peter, Acee, agree that this was missed in architecture and we should have talked about multiple encaps on a link there (just like we mentioned the BSL conversion). Alas, it was theoretical then and we missed. It was just a suggestion here to put it into IGP draft as we did in ISIS. I'm fine whichever way you guys feel it's better and a clarification draft can be always published later after more experience in the field albeit it seems that the issue is straight fwd' for most old hands, it's a link local decision so just use any matching encaps to transfer, however the computation has to agree to prevent blackholes ...
>
> Otherwise went through the important sections on -11 and looks good to me, no further comments. Thanks for the work
>
> --- tony
>
> On Mon, Feb 12, 2018 at 7:58 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
> With respect to the text in section 5.2, I agree with Peter.
>
> Thanks
> Acee
>
> On 2/12/18, 9:59 AM, "BIER on behalf of Peter Psenak (ppsenak)" <bier-bounces@ietf.org on behalf of ppsenak@cisco.com> wrote:
>
> Hi Tony,
>
> OSPF does not have the original text, so it does not need the new one.
>
> IMHO, the text in section 5 of ISIS BIER draft suits better to the BIER
> architecture draft than to the IGP extension draft.
>
> thanks,
> Peter
>
>
> On 09/02/18 20:17 , Tony Przygienda wrote:
> > Sure ;-) let me ping Peter @ the bottom then ... I don't think any of
> > the stuff applies to OSPF (was ISIS nits) except we can consider an
> > encaps paragraph. We basically suggest both to replace in ISIS the
> > encaps section like this
> >
> > before:
> >
> > "
> > All routers in the flooding scope of the BIER TLVs MUST advertise the
> > same encapsulation for a given <MT,SD>. A router discovering
> > encapsulation advertised that is different from its own MUST report a
> > misconfiguration of a specific <MT,SD>. All received BIER
> > advertisements associated with the conflicting <MT, SD> pair MUST be
> > ignored.
> >
> > "
> >
> > now
> >
> > "
> >
> > Multiple encapsulations MAY be advertised/supported for a given
> > <MT,SD>. Clearly, however, there MUST be at least one encapsulation
> > type in common in order for a BIER encapsulated packet to be
> > successfully forwarded between two BFRs.
> >
> > "
> >
> > I do think that OSPF would benefit from adding this section to clarify
> > the issue which is not theoretical now that we have Ethernet.
> >
> >
> > So Peter, any ETA on outstanding OSPF nits now that we're tying up the
> > IETF LC?
> >
> > thanks
> >
> > --- tony
> >
> >
> > On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd <gjshep@gmail.com
> > <mailto:gjshep@gmail.com>> wrote:
> >
> > No I didn't. Why would I? These are the changes you and Les worked
> > out. I assumed you'd share them as needed. If for some reason you're
> > uncomfortable engaging with the OSPF draft thread and authors with
> > your proposed changes, let me know and I'll broker the conversation.
> >
> > Greg
> >
> > On Fri, Feb 9, 2018 at 11:04 AM, Tony Przygienda
> > <tonysietf@gmail.com <mailto:tonysietf@gmail.com>> wrote:
> >
> > 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
> > <mailto:akatlas@gmail.com>> wrote:
> >
> > On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
> > <tonysietf@gmail.com <mailto: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 <mailto: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
> > <mailto: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
> > <mailto:gjshep@gmail.com>]
> > *Sent:* Thursday, February 01, 2018 2:23 AM
> > *To:* Toerless Eckert <tte@cs.fau.de
> > <mailto:tte@cs.fau.de>>
> > *Cc:* Les Ginsberg (ginsberg)
> > <ginsberg@cisco.com
> > <mailto:ginsberg@cisco.com>>; Tony Przygienda
> > <tonysietf@gmail.com
> > <mailto:tonysietf@gmail.com>>; Hannes Gredler
> > (hannes@gredler.at <mailto:hannes@gredler.at>)
> > <hannes@gredler.at <mailto:hannes@gredler.at>>;
> > bier@ietf.org <mailto:bier@ietf.org>;
> > isis-wg@ietf.org <mailto:isis-wg@ietf.org> list
> > <isis-wg@ietf.org <mailto:isis-wg@ietf.org>>;
> > Christian Hopps <chopps@chopps.org
> > <mailto: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 <mailto: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 <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
> > <mailto:hannes@gredler.at>); Greg Shepherd;
> > > > bier@ietf.org <mailto:bier@ietf.org>;
> > isis-wg@ietf.org <mailto: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-
> > <https://www.ietf.org/id/draft-ietf-bier->
> > > > ospf-bier-extensions-07.txt Section
> > 2.5<https://www.ietf.org/id/draft-ietf-
> > <https://www.ietf.org/id/draft-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
> > <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
> > <mailto:hannes@gredler.at>); Greg Shepherd;
> > bier@ietf.org <mailto:bier@ietf.org>;
> > > > > isis-wg@ietf.org
> > <mailto: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><mailto: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><mailto:BIER@ietf.org
> > <mailto:BIER@ietf.org>>
> > > > >
> > https://www.ietf.org/mailman/listinfo/bier
> > <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 <mailto:tte@cs.fau.de>____
> >
> > __ __
> >
> >
> >
> >
> > _______________________________________________
> > BIER mailing list
> > BIER@ietf.org <mailto:BIER@ietf.org>
> > https://www.ietf.org/mailman/listinfo/bier
> > <https://www.ietf.org/mailman/listinfo/bier>
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
>
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
> <image001.png>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
- [Isis-wg] WGLC: draft-ietf-bier-isis-extensions-04 Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Toerless Eckert
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Toerless Eckert
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Toerless Eckert
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands (iwijnand)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Alia Atlas
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Alia Atlas
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Peter Psenak
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Peter Psenak
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Acee Lindem (acee)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Acee Lindem (acee)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Peter Psenak
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Acee Lindem (acee)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Eric C Rosen
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Xiejingrong