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

"Acee Lindem (acee)" <acee@cisco.com> Tue, 13 February 2018 12:04 UTC

Return-Path: <acee@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 566A41275AB; Tue, 13 Feb 2018 04:04:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.404
X-Spam-Level:
X-Spam-Status: No, score=-13.404 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 gJzJneXLkxow; Tue, 13 Feb 2018 04:04:52 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724E2120454; Tue, 13 Feb 2018 04:04:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=344670; q=dns/txt; s=iport; t=1518523492; x=1519733092; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pfLuao6uejCn5v8DbXP23KT91By9kJn41udDX4V8s2A=; b=O1mSc7EcYTjyvlxeEQl6tKNzywMPsWsCXUec83MXEzUiHJN72MFPXv/n GTqOmWWNeLUh+A/g8WaEb8/mY1Vx74bKAX1rOV/8rhAPZlTN+rhdomQmm e15y6R9uokhn1pl92LPOmqQAcbBLxmeCyh8/2TN4OxN3LdEv5KCeM40ui M=;
X-Files: image001.png : 43632
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CzBABD1IJa/49dJa2mJaFvBAIBAgKBE84J
X-IronPort-AV: E=Sophos;i="5.46,507,1511827200"; d="png'150?scan'150,208,217,150";a="69608157"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2018 12:04:51 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w1DC4p2c002574 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Feb 2018 12:04:51 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Feb 2018 07:04:50 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 13 Feb 2018 07:04:49 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
CC: Tony Przygienda <tonysietf@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "bier@ietf.org" <bier@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Thread-Topic: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
Thread-Index: AQHTodrQmhxalf8idEecM+y86cU2hqOhNBkA//+87oCAAGhmAP//wsOAgABtUACAAAJVgIAADLMAgAAFFgCAAAlYgIAABKUAgACZkoCAAB3rAIAAFyGA///HtoA=
Date: Tue, 13 Feb 2018 12:04:47 +0000
Message-ID: <2E5C55F2-7AA6-4672-AE73-AC337F941D97@cisco.com>
References: <20170721062741.GA3215@faui40p.informatik.uni-erlangen.de> <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> <CA+wi2hNK1WRN89q0uUOF4FLkDHoBBtUZhLxqrceY-q_zu7=8zg@mail.gmail.com> <5A82A9D8.7050606@cisco.com> <366D5764-C195-469C-826A-90DC9F5E6307@cisco.com>
In-Reply-To: <366D5764-C195-469C-826A-90DC9F5E6307@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.195]
Content-Type: multipart/related; boundary="_004_2E5C55F27AA64672AE73AC337F941D97ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/zzr6_mUpM__96w44Kv6m_kmst8E>
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 12:04:59 -0000

Only problem with this is that people don’t normally read all the errata. I’m a WG chair and I don’t even read them for an RFC until I find something I think is broken – then I look for one that is pertinent.

Thanks,
Acee

From: "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>
Date: Tuesday, February 13, 2018 at 5:26 AM
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
Cc: Tony Przygienda <tonysietf@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "bier@ietf.org" <bier@ietf.org>, Acee Lindem <acee@cisco.com>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

+1

But, I’m not yet sure if we’re taking about a errata or a new draft.. I see different ways to interpret the proposed text and Les’s explanation.

Thx,

Ice.


On 13 Feb 2018, at 10:03, Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com>> 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> <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>
   <mailto:ginsberg@cisco.com>>
   *Cc:* Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com> <mailto:acee@cisco.com>>;
   bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org>; Peter Psenak (ppsenak)
   <ppsenak@cisco.com<mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com>>; 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>>
   *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> <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>
       <mailto:ginsberg@cisco.com>>
       Cc: Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com> <mailto:acee@cisco.com>>;
       bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org>; Peter Psenak (ppsenak)
       <ppsenak@cisco.com<mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com>>; 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>>
       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> <mailto:acee@cisco.com>>
       Cc: Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>
       <mailto:tonysietf@gmail.com>>; Les Ginsberg (ginsberg)
       <ginsberg@cisco.com<mailto:ginsberg@cisco.com> <mailto:ginsberg@cisco.com>>; 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> list <isis-wg@ietf.org<mailto:isis-wg@ietf.org>
       <mailto:isis-wg@ietf.org>>; Peter Psenak (ppsenak)
       <ppsenak@cisco.com<mailto: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>
       <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>
       <mailto:tonysietf@gmail.com>>
       Date: Monday, February 12, 2018 at 12:13 PM
       To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com> <mailto:acee@cisco.com>>
       Cc: "Peter Psenak (ppsenak)" <ppsenak@cisco.com<mailto:ppsenak@cisco.com>
       <mailto:ppsenak@cisco.com>>, "Les Ginsberg (ginsberg)"
       <ginsberg@cisco.com<mailto:ginsberg@cisco.com> <mailto:ginsberg@cisco.com>>, "bier@ietf.org<mailto:bier@ietf.org>
       <mailto:bier@ietf.org>" <bier@ietf.org<mailto:bier@ietf.org> <mailto:bier@ietf.org>>,
       "isis-wg@ietf.org<mailto:isis-wg@ietf.org> list <mailto:isis-wg@ietf.org%20list>"
       <isis-wg@ietf.org<mailto: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> <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<mailto:bier-bounces@ietf.org> on behalf of ppsenak@cisco.com<mailto:ppsenak@cisco.com>
       <mailto:bier-bounces@ietf.org%20on%20behalf%20of%C2%A0ppsenak@cisco.com<mailto: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>
       <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
       <mailto:tonysietf@gmail.com%20%3cmailto:tonysietf@gmail.com<http://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>
       <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
       <mailto:tonysietf@gmail.com%20%3cmailto:tonysietf@gmail.com<http://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
       <mailto:gjshep@gmail.com%20%3cmailto:gjshep@gmail.com<http://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>
       <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<http://gmail.com>%3e>]
            >                         *Sent:* Thursday, February 01,
       2018 2:23 AM
            >                         *To:* Toerless Eckert <tte@cs.fau.de<mailto: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>
       <mailto:ginsberg@cisco.com%0b%C2%A0%20>>
       <mailto:ginsberg@cisco.com>>; Tony Przygienda
            >                         <tonysietf@gmail.com<mailto: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
       <mailto:hannes@gredler.at>>)
            >                         <hannes@gredler.at<mailto:hannes@gredler.at>
       <mailto:hannes@gredler.at
       <mailto:hannes@gredler.at%20%3cmailto:hannes@gredler.at<http://gredler.at>>>>;
            > bier@ietf.org<mailto: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
       <mailto:isis-wg@ietf.org>> list
            >                         <isis-wg@ietf.org<mailto:isis-wg@ietf.org>
       <mailto:isis-wg@ietf.org
       <mailto:isis-wg@ietf.org%20%3cmailto:isis-wg@ietf.org<mailto:wg@ietf.org>>>>;
            >                         Christian Hopps <chopps@chopps.org<mailto: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
       <mailto:tte@cs.fau.de%20%3cmailto:tte@cs.fau.de<http://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<http://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>
            >                             <mailto:hannes@gredler.at>);
       Greg Shepherd;
            >                              > > bier@ietf.org<mailto: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
       <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->
            >
       <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-
       <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>
       <mailto:bier-bounces@ietf.org<mailto: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<mailto: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> <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
       <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
            >                              > > >
            >                              > > > 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%0b%C2%A0%20>>
       <mailto:tte@cs.fau.de><mailto:tte@cs.fau.de
       <mailto:tte@cs.fau.de%0b%C2%A0%20>>
       <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><mailto:BIER@ietf.org
       <mailto:BIER@ietf.org%0b%C2%A0%20>>
       <mailto:BIER@ietf.org>>
            >                              > > >
            > https://www.ietf.org/mailman/listinfo/bier
       <https://www.ietf.org/mailman/listinfo/bier>
            >
       <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>
       <mailto:tte@cs.fau.de> <mailto:tte@cs.fau.de
       <mailto:tte@cs.fau.de>>____
            >
            >                         __ __
            >
            >
            >
            >
            >
       _______________________________________________
            >                 BIER mailing list
            > BIER@ietf.org<mailto: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>
            >
       <https://www.ietf.org/mailman/listinfo/bier
       <https://www.ietf.org/mailman/listinfo/bier>>
            >
            >
            >
            >
            >
            >
            >
            > _______________________________________________
            > BIER mailing list
            > 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>
            >

            _______________________________________________
            BIER mailing list
       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>



       _______________________________________________
       BIER mailing list
       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>

       <image001.png>

       _______________________________________________
       BIER mailing list
       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>

       <image001.png>____

   __ __

   ____

   __ __


   _______________________________________________
   BIER mailing list
   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>



[cid:6D5DA0C0-E3D6-4998-A2B2-FBE7253DB66D@cisco.com]