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

Tony Przygienda <tonysietf@gmail.com> Tue, 13 February 2018 07:17 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 68F1B126CC4; Mon, 12 Feb 2018 23:17:04 -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 vJUVXbQa9YZ1; Mon, 12 Feb 2018 23:16:59 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 3FDE5126CD6; Mon, 12 Feb 2018 23:16:58 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id x4so11935287wmc.0; Mon, 12 Feb 2018 23:16:58 -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=HFuPALqFNcpKkrUZJ27ibkc+uCSEex5nrGyamwSlq1M=; b=JYb5aU76Nrmnrgfs8FqgXGYNSmiBJ83wwJ0soRiJPj4fNLrzCKTDww2964FZm7t4ss nCqupns4BTYvNInflQZQZDjwVECyJR/h/UsRupzqybdAdMorechbeSBlFTLCFR8+XIrj peXsyC92FlupfWrRm6nB+AjV7N8CFUHXGUqEZ8GEEySdc3hb8mQAdLQpm0kAVKNuadVJ bp0UW39RuvByDc5O8/vyunWJYSDbpsZCy9VK3vZLOD0MG8MymqXU3YCvCZzi7WfP55f6 SuXt+knnpHnfmhXog/I0GmbAUUBnoo+3oMqfq8a8wMxv+kJoLsUTyAln8dD2s8RN9HtC f5Sg==
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=HFuPALqFNcpKkrUZJ27ibkc+uCSEex5nrGyamwSlq1M=; b=qoLvz8fo8n1kGWKRBRJLfltt7NCF7SAG43z8zrZoiM3NQk90VAo46uXM8tB8Tam9aZ a8g63T3I+00DbHcLRKltAw+vDfERwuPUhd7vWmMN44gG6WEFBuZQ0mlJy7xTiEjjiY/W bKs+RE4m7dkKVfLA5HoD2GvrZw+CRxg/wc0WCx/DJgURj306JfT18Y42LRSUZbNrYxwk kTB6BUYTDOGkgRpP7DOpBcx4a3q1/+TjHqawWJ07LQ/Jhzmez82nA1kTVDU8ymUlPl4y jDS/JYOL3Jy+qIWlaRCbOwU8Fd8KoEVErBaFChhxKtHmpFdK5W0bIMlq9AJ/957L/OtZ 6pSQ==
X-Gm-Message-State: APf1xPDT+7a9OrzuaDSkuqTDKN7SpsGIVR9pAOr+9WRkXsSyr/l/cWNH etBu8TG5WGY+zebh1LA2jRiuLtCcJOgY5iB2sdU=
X-Google-Smtp-Source: AH8x224pb0NTYKz80sJHKCo2eaTdNK85peTEXGt+5NdRohB7EtQ/kJL9sRWaoHoagB56/c80D/n7ts9AnCq9+mWr5+o=
X-Received: by 10.80.155.90 with SMTP id a26mr860210edj.290.1518506216473; Mon, 12 Feb 2018 23:16:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.231.7 with HTTP; Mon, 12 Feb 2018 23:16:15 -0800 (PST)
In-Reply-To: <07df09dda97e4dad9450a4a9799ae8c7@XCH-ALN-001.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+wi2hO0ZPS=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> <CC1CC82E-E134-4931-9735-07A0D0E64997@cisco.com> <e1ce91bb9d28485fbaad63252e1e0e3c@XCH-ALN-001.cisco.com> <E35F158F-2F97-47FD-8272-497B68ABDD1B@cisco.com> <07df09dda97e4dad9450a4a9799ae8c7@XCH-ALN-001.cisco.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Mon, 12 Feb 2018 23:16:15 -0800
Message-ID: <CA+wi2hNK1WRN89q0uUOF4FLkDHoBBtUZhLxqrceY-q_zu7=8zg@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>, "bier@ietf.org" <bier@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, "isis-wg@ietf.org list" <isis-wg@ietf.org>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
Content-Type: multipart/related; boundary="94eb2c1af4629f6498056512c7ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/MlesZcFl-sZJp7Ud3pzs2el5shc>
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: Tue, 13 Feb 2018 07:17:04 -0000

+1 what Les says as my understanding of the problem we're tackling here ...

--- tony

On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com
> wrote:

> Ice –
>
>
>
> MY understanding is that – in the future – there may be additional encaps
> defined for BIER. When that happens, a given BFR may support multiple
> encaps. In such a case, it is OK if other BFRs supporting the same <MT,SD>
> only support one of the set of encaps – so long as we have one encap in
> common we can successfully forward. I believe that is the case the text
> change is trying to address – not encap vs no encap. The original text
> would have required identical sets of encaps to be supported by all BFRs
> for a give <MT,SD> - which is unnecessarily restrictive.
>
>
>
> Make sense?
>
>
>
>   Les
>
>
>
>
>
> *From:* IJsbrand Wijnands (iwijnand)
> *Sent:* Monday, February 12, 2018 1:50 PM
>
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> *Cc:* Acee Lindem (acee) <acee@cisco.com>om>; bier@ietf.org; Peter Psenak
> (ppsenak) <ppsenak@cisco.com>om>; isis-wg@ietf.org list <isis-wg@ietf.org>
> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
>
>
> Les,
>
>
>
> (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.)
>
>
>
> It says, if MPLS encapsulation is used, there is a Label for the {SD,
> BSL}. So, if there is non-MPLS (ether) only, there will not be a Label and
> the compatibility check will fail. Is that not the same a router that does
> not support MPLS BIER, and treated as a non-BIER router?
>
>
>
> [Les:] I don’t see how this text can be used to mean “multiple encap types
> can be supported on the same BFR for a given <MT,SD>”.
> ???
>
>
>
> Are these not like ships in the night? Like an Prefix can be reachable
> over MPLS and IP on the same interface? I do assume you want to stay with
> the encapsulation that you where provisioned in and not move from MPLS into
> non-MPLS. Why do you need to say you can support both?
>
>
>
> Thx,
>
>
>
> Ice.
>
>
>
>
>
> On 12 Feb 2018, at 22:16, Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> wrote:
>
> Ice -
>
> From: IJsbrand Wijnands (iwijnand)
> Sent: Monday, February 12, 2018 12:58 PM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Cc: Acee Lindem (acee) <acee@cisco.com>om>; bier@ietf.org; Peter Psenak
> (ppsenak) <ppsenak@cisco.com>om>; isis-wg@ietf.org list <isis-wg@ietf.org>
> Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
> 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.
> ****
>
> [Les:] I don’t see how this text can be used to mean “multiple encap types
> can be supported on the same BFR for a given <MT,SD>”.
> ???
>
>    Les
>
>
> 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>om>; Les Ginsberg (ginsberg) <
> ginsberg@cisco.com>gt;; bier@ietf.org; isis-wg@ietf.org list <
> isis-wg@ietf.org>gt;; 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>om>, "Les Ginsberg
> (ginsberg)" <ginsberg@cisco.com>om>, "bier@ietf.org" <bier@ietf.org>rg>, "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
>      <gjshep@gmail.com%0b%C2%A0%20>> <mailto:gjshep@gmail.com
> <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
>      <akatlas@gmail.com%0b%C2%A0%20>>         <mailto:akatlas@gmail.com
> <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
>      <ginsberg@cisco.com%0b%C2%A0%20>>                     <
> mailto:ginsberg@cisco.com <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>
> <gjshep@gmail.com%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:gjshep@gmail.com%3e>
> ]
>     >                         *Sent:* Thursday, February 01, 2018 2:23 AM
>     >                         *To:* Toerless Eckert <tte@cs.fau.de
>      <tte@cs.fau.de%0b%C2%A0%20>>                         <
> mailto:tte@cs.fau.de <tte@cs.fau.de>>>
>     >                         *Cc:* Les Ginsberg (ginsberg)
>     >                         <ginsberg@cisco.com
>      <ginsberg@cisco.com%0b%C2%A0%20>>                         <
> mailto:ginsberg@cisco.com <ginsberg@cisco.com>>>>>>; Tony Przygienda
>     >                         <tonysietf@gmail.com
>      <tonysietf@gmail.com%0b%C2%A0%20>>                         <
> mailto:tonysietf@gmail.com <tonysietf@gmail.com>>>>>>; Hannes Gredler
>     >                         (hannes@gredler.at <mailto:hannes@gredler.at
> <hannes@gredler.at>>)
>     >                         <hannes@gredler.at <mailto:hannes@gredler.at
> >>;
>     >                         bier@ietf.org <mailto:bier@ietf.org
> <bier@ietf.org>>g>>;
>     >                         isis-wg@ietf.org <mailto:isis-wg@ietf.org
> <isis-wg@ietf.org>> list
>     >                         <isis-wg@ietf.org <mailto:isis-wg@ietf.org
> >>;
>     >                         Christian Hopps <chopps@chopps.org
>      <chopps@chopps.org%0b%C2%A0%20>>                         <
> mailto:chopps@chopps.org <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> <tte@cs.fau.de%20%3cmailto:tte@cs.fau.de%3e>]
>     >                              > > Sent: Saturday, July 22, 2017 6:34
> AM
>     >                              > > To: Les Ginsberg (ginsberg)
>     >                              > > Cc: Tony Przygienda; Hannes Gredler
>     >                             (hannes@gredler.at
>     >                             <mailto:hannes@gredler.at
> <hannes@gredler.at>>)>>); Greg Shepherd;
>     >                              > > bier@ietf.org <mailto:bier@ietf.org
> <bier@ietf.org>>g>>;
>     >                             isis-wg@ietf.org <mailto:
> isis-wg@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-
>     >                             <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-%0b%C2%A0%20>>
>           <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>
> <bier-bounces@ietf.org%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:bier-bounces@ietf.org%3e>]
> 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
> <hannes@gredler.at>>)>>); Greg Shepherd;
>     >                             bier@ietf.org <mailto:bier@ietf.org
> <bier@ietf.org>>g>>;
>     >                              > > > isis-wg@ietf.org
>     >                             <mailto:isis-wg@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
>      <tte@cs.fau.de%0b%C2%A0%20>>                             <
> mailto:tte@cs.fau.de <tte@cs.fau.de>><mailto:tte@cs.fau.de
>      <tte@cs.fau.de%0b%C2%A0%20>>                             <
> mailto:tte@cs.fau.de <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 <BIER@ietf.org>><
> mailto:BIER@ietf.org
>      <BIER@ietf.org%0b%C2%A0%20>>                             <
> mailto:BIER@ietf.org <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
> <tte@cs.fau.de>>____
>     >
>     >                         __ __
>     >
>     >
>     >
>     >
>     >                 _______________________________________________
>     >                 BIER mailing list
>     >                 BIER@ietf.org <mailto:BIER@ietf.org <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
>
> <image001.png>
>
>
>
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>