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

Tony Przygienda <tonysietf@gmail.com> Tue, 13 February 2018 17:37 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 2484E12D86C; Tue, 13 Feb 2018 09:37:56 -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 CBpZVsFq5phR; Tue, 13 Feb 2018 09:37:51 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7DA12D86A; Tue, 13 Feb 2018 09:37:50 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id a84so6254205wmi.5; Tue, 13 Feb 2018 09:37:50 -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=Hu8EGCdAkeL7Cgddd2PlE0e7PxiswF4FM6HQA9vVyag=; b=uT07vbE83hQbWe0O/MH6VGetku5CB7K6QajGqLE1sR7Bb9wldlefqxP2R5aFO8TBP9 z9UjwyXpjOPUVntpjVoD41Ey5o9E2E3e/LRFoK+Q/0aJL98r4eYh9S+cMBiBkTZQlPm/ 8pZdLxwvp+u/+W4UDxP++voNvQNpvtZh/SSuOJaGp+mL0cSwMVMJ6dM57dD3+nLcT1fO CPRo/v6OM3v/V8vrMyZHGQuT7bwQNMccCaPOcq68NST3JwOSmsSzvktpM+FftVN3jQhk ZKhu7KzP4dvZK8BYN/CKxDvEtuBlKD3DfgGWphifaOjHZFQVLWm2h16kUMlzJPfyOpkZ nM8w==
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=Hu8EGCdAkeL7Cgddd2PlE0e7PxiswF4FM6HQA9vVyag=; b=X7r1YkfuDQUGqnvFVQu88MxlZrurnpIHp5gNPQRiedCTwr6+CbhXVaQl5CaNuaCGnw gBSBh8217JI333Fti4c/6aKpAuS3HEYEKXshx9S1IUcmGQQTFLclDaYg4uWWAurumLHY lHrJ/DqNVk24P/ozi5XQdoYPQJS1wUTCqP1pe3k23ShKx9/JXtDNTiwpy8p0t105X/Ob JAYul8cbsVOKktL5QPo7C5BT4PYAfo6Drwg4u8vvOePbLNkwKjfZqtthXcEN1abp4DxT C4IzDoobGbro0gjhNThiAn8I81OZFVSNR4+HoxHyCQ1Jz68z+UzhansTdhRbEOAIimfg ozDA==
X-Gm-Message-State: APf1xPDXfJpFQEMYg6A/B5eQAbPZ4Kgr7RifCzjHMQN2+zKV8NEUzRnt riHhf8dOHez3e2xmyvs5yauP2uqyLPDrdKxcW6k=
X-Google-Smtp-Source: AH8x224llr9cD8WhyEuy+ku4hQt1Xf9fFW83fBrJmPzmN6DMoX/1F3jsUDrmSbptquvmpDuD8D475GP50Y5PpFiBqa0=
X-Received: by 10.80.155.90 with SMTP id a26mr3169886edj.290.1518543468377; Tue, 13 Feb 2018 09:37:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.231.7 with HTTP; Tue, 13 Feb 2018 09:37:07 -0800 (PST)
In-Reply-To: <198ac8de09334551978f6069714270ab@XCH-ALN-001.cisco.com>
References: <20170721062741.GA3215@faui40p.informatik.uni-erlangen.de> <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> <CA+wi2hNK1WRN89q0uUOF4FLkDHoBBtUZhLxqrceY-q_zu7=8zg@mail.gmail.com> <5A82A9D8.7050606@cisco.com> <5153704a-843f-10de-eb74-c9c3a3ad722e@juniper.net> <CA+wi2hON6E7rdhELLg14ZFKQxyoz_moknhdrbm50BH_Jnopsuw@mail.gmail.com> <0d900502826d41bbb656c343575222ba@XCH-ALN-001.cisco.com> <CA+wi2hPXdZP9RE87MhNmgG0veMO+Gt+qdmCdQQXEFEYeX=ufpw@mail.gmail.com> <198ac8de09334551978f6069714270ab@XCH-ALN-001.cisco.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Tue, 13 Feb 2018 09:37:07 -0800
Message-ID: <CA+wi2hO_x3DyBn1vveg=KfiMGBqMQKRhiCwZ846UPwX2wZPEHw@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Eric C Rosen <erosen@juniper.net>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, "bier@ietf.org" <bier@ietf.org>, "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1af462023b6905651b742d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/N9bbEXw1rNEmY9x53bJcxg90Qtk>
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 17:37:56 -0000

As I said, if we think it's more complex than what we wrote for the ISIS
draft then I'm fine with a simple "here be dragons" disclaimer on the
drafts as long we don't leave it as an unmentioned minefield for the
developers.  And then we start a draft standardizing, I foresee a BIER, eeh
beer session @ the bar in London ;-)

--- tony

On Tue, Feb 13, 2018 at 9:06 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com
> wrote:

> Tony –
>
>
>
> I think the issues around supporting multiple encap types and how one
> might map one encap to another if your outgoing neighbor did not support
> the incoming encap are much more complex than the simple statement we have
> in the IS-IS draft.
>
> I do think it would be better if we did not make a statement which
> suggests there is a way to support something – but the actual details of
> how to support are still TBD. Better to put that in a draft that has the
> context to completely define such a solution. What is currently in the
> IS-IS isn’t useful w/o the additional detail.
>
>
>
> The new text we have is better than the old text – but I do agree with
> others that it really doesn’t belong in the IGP drafts.
>
>
>
>     Les
>
>
>
>
>
> *From:* Tony Przygienda [mailto:tonysietf@gmail.com]
> *Sent:* Tuesday, February 13, 2018 8:17 AM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> *Cc:* Eric C Rosen <erosen@juniper.net>et>; Peter Psenak (ppsenak) <
> ppsenak@cisco.com>gt;; Acee Lindem (acee) <acee@cisco.com>om>; bier@ietf.org;
> IJsbrand Wijnands (iwijnand) <ice@cisco.com>om>; isis-wg@ietf.org list <
> isis-wg@ietf.org>
> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
>
>
> Yes, it's one possible interpretation ;-) albeit I would be more
> comfortable to deliver draft(s) that can be looked @ and implemented as
> they are written and published ;-)
>
> So let's say, if we can all agree that there is one correct interpretation
> (and I suggest of course what we both agreed on but have no vested stake)
> then I prefer to have the drafts put it in as part of IETF LC comments. If
> we cannot agree, be it, let us put in a sentence to the tune  of "issue of
> multiple encapsulations on the same <MT,SD,BML> combination is undefined in
> this RFC" which basically reads "here be dragons" which is inifintely
> better than having looping implementations because no'one knew what the
> score was. And in such case I would recommend to immediately follow up with
> a draft  about how multiple encapsulations are to be treated and discuss it
> out since we all know the issue will likely show up in the field.
>
> sounds fair?
>
> I'm sorry again I missed it writing the ISIS draft (or rather wrote a
> section that we realized only on last fine read seemed overly restrictive)
> ...
>
>
>
> -- tony
>
>
>
> On Tue, Feb 13, 2018 at 8:09 AM, Les Ginsberg (ginsberg) <
> ginsberg@cisco.com> wrote:
>
> Tony –
>
>
>
> Can I interpret this as meaning you are OK with removing the text about
> multiple encapsulations from the IS-IS draft?
>
>
>
>    Les
>
>
>
>
>
> *From:* Tony Przygienda [mailto:tonysietf@gmail.com]
> *Sent:* Tuesday, February 13, 2018 7:56 AM
> *To:* Eric C Rosen <erosen@juniper.net>
> *Cc:* Peter Psenak (ppsenak) <ppsenak@cisco.com>om>; Les Ginsberg (ginsberg)
> <ginsberg@cisco.com>om>; Acee Lindem (acee) <acee@cisco.com>om>; bier@ietf.org;
> IJsbrand Wijnands (iwijnand) <ice@cisco.com>om>; isis-wg@ietf.org list <
> isis-wg@ietf.org>
> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
>
>
> +1 Eric's take ... I don't see how we can interpret it/standardize it in
> many ways unless we want it to be overly restrictive but in any case I
> think a new draft is a good thing. And sigh, we didn't pay enough attention
> since the issue seemed "ephemeral" (and arguably, there were many things
> more worth aruging to be argued then ;-) but with ether it needs
> clarification.  The way it slipped me was that while writing the ISIS draft
> originally and using the <MT,SD,BML> I thought briefly based on my UML that
> it's really  <MT,SD,ENC,BML> but then I was thinking "gosh, this is getting
> deep and people will probably roll their eyes" ;-)   Another principle
> slipped, another lesson learned albeit I think this one is pretty harmless.
>
>
>
> Question more being: are we ready with the OSPF draft if we leave that
> completely open. If I'd be an implementer (or maybe I am ;-) I would have
> no issue implementing the ISIS draft in a clear way when computing, without
> any ENC explanation I would say @ this point in computaiton "hmm, am I
> supposed ignore the TLV because I see encaps I don't understand/support on
> this link" or do I install in fast-path just any encapsulation we both
> agree on?  (Or we could think about e.g. is MPLS preferred over anything
> else, i.e. have a predictable ordering which may play a role if someone
> wants to debug the network). Or otherwise, yes, we could sya, more than ONE
> encap on the link is illegal (but that's not what my UML based on
> architecture doc/discussion says ;-)
>
>
>
> yes, it's finely carved, yes, IGPs always are ...
>
>
>
> --- tony
>
>
>
> On Tue, Feb 13, 2018 at 5:11 AM, Eric C Rosen <erosen@juniper.net> wrote:
>
> If some folks think that there needs to be a correction or addition to the
> architecture, the best thing to do would be to write a new draft and post
> it for discussion.
>
> This appears to be a substantive technical issue, which is not appropriate
> for an erratum.  It also doesn't seem appropriate for the IGP drafts.
>
>
>
> On 2/13/2018 4:03 AM, Peter Psenak wrote:
>
> Hi Folks,
>
> can we add an errata to RFC 8279, instead of adding the text to both IGP
> drafts that does not really belong there.
>
>
> thanks,
> Peter
>
> On 13/02/18 08:16 , Tony Przygienda wrote:
>
> +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 <mailto: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
>     <mailto:ginsberg@cisco.com>>
>     *Cc:* Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com>>;
>     bier@ietf.org <mailto:bier@ietf.org>; Peter Psenak (ppsenak)
>     <ppsenak@cisco.com <mailto:ppsenak@cisco.com>>; isis-wg@ietf.org
>     <mailto:isis-wg@ietf.org> list <isis-wg@ietf.org
>     <mailto: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 <mailto:ginsberg@cisco.com>> wrote:
>
>         Ice -
>
>         From: IJsbrand Wijnands (iwijnand)
>         Sent: Monday, February 12, 2018 12:58 PM
>         To: Les Ginsberg (ginsberg) <ginsberg@cisco.com
>         <mailto:ginsberg@cisco.com>>
>         Cc: Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com>>;
>         bier@ietf.org <mailto:bier@ietf.org>; Peter Psenak (ppsenak)
>         <ppsenak@cisco.com <mailto:ppsenak@cisco.com>>; isis-wg@ietf.org
>         <mailto:isis-wg@ietf.org> list <isis-wg@ietf.org
>         <mailto: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 <mailto:acee@cisco.com>>
>         Cc: Tony Przygienda <tonysietf@gmail.com
>         <mailto:tonysietf@gmail.com>>; Les Ginsberg (ginsberg)
>         <ginsberg@cisco.com <mailto:ginsberg@cisco.com>>; 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>>; Peter Psenak (ppsenak)
>         <ppsenak@cisco.com <mailto: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
>         <mailto: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
>         <mailto:tonysietf@gmail.com>>
>         Date: Monday, February 12, 2018 at 12:13 PM
>         To: Acee Lindem <acee@cisco.com <mailto:acee@cisco.com>>
>         Cc: "Peter Psenak (ppsenak)" <ppsenak@cisco.com
>         <mailto:ppsenak@cisco.com>>, "Les Ginsberg (ginsberg)"
>         <ginsberg@cisco.com <mailto:ginsberg@cisco.com>>, "bier@ietf.org
>         <mailto:bier@ietf.org>" <bier@ietf.org <mailto:bier@ietf.org>>,
>         "isis-wg@ietf.org list <mailto:isis-wg@ietf.org%20list>"
>         <isis-wg@ietf.org <mailto: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 <mailto: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
> <mailto:bier-bounces@ietf.org%20on%20behalf%20of%C2%A0ppsenak@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%0b%C2%A0%20>>
>         <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
> <mailto:tonysietf@gmail.com%20%3cmailto: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%0b%C2%A0%20>>
>         <mailto:akatlas@gmail.com>> wrote:
>              >
>              >             On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
>              >             <tonysietf@gmail.com
>         <mailto:tonysietf@gmail.com
> <mailto:tonysietf@gmail.com%20%3cmailto: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
> <mailto:gjshep@gmail.com%20%3cmailto: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%0b%C2%A0%20>>
>         <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>
> <mailto: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
>         <mailto:tte@cs.fau.de%0b%C2%A0%20>>
>         <mailto:tte@cs.fau.de>>
>              >                         *Cc:* Les Ginsberg (ginsberg)
>              >                         <ginsberg@cisco.com
>         <mailto:ginsberg@cisco.com%0b%C2%A0%20>>
>         <mailto:ginsberg@cisco.com>>; Tony Przygienda
>              > <tonysietf@gmail.com
>         <mailto:tonysietf@gmail.com%0b%C2%A0%20>>
>            <mailto:tonysietf@gmail.com>>; Hannes Gredler
>              >                         (hannes@gredler.at
>         <mailto:hannes@gredler.at> <mailto:hannes@gredler.at
>         <mailto:hannes@gredler.at>>)
>              >                         <hannes@gredler.at
>         <mailto:hannes@gredler.at
> <mailto:hannes@gredler.at%20%3cmailto:hannes@gredler.at>>>;
>              > bier@ietf.org
>         <mailto:bier@ietf.org> <mailto:bier@ietf.org
>         <mailto:bier@ietf.org>>;
>              > isis-wg@ietf.org
>         <mailto:isis-wg@ietf.org> <mailto:isis-wg@ietf.org
>         <mailto:isis-wg@ietf.org>> list
>              >                         <isis-wg@ietf.org
>         <mailto:isis-wg@ietf.org
> <mailto:isis-wg@ietf.org%20%3cmailto:isis-wg@ietf.org>>>;
>              >                         Christian Hopps <chopps@chopps.org
>         <mailto:chopps@chopps.org%0b%C2%A0%20>>
>         <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
> <mailto:tte@cs.fau.de%20%3cmailto: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>
> <mailto: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>
>              > <mailto:hannes@gredler.at>);
>         Greg Shepherd;
>              >                              > > bier@ietf.org
>         <mailto:bier@ietf.org> <mailto:bier@ietf.org
>         <mailto:bier@ietf.org>>;
>              > isis-wg@ietf.org
>         <mailto:isis-wg@ietf.org> <mailto: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
>
>
> ...
>
> [Message clipped]
>
>
>
>
>