Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04
IJsbrand Wijnands <ice@cisco.com> Tue, 13 February 2018 10:26 UTC
Return-Path: <ice@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A65120047; Tue, 13 Feb 2018 02:26:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.799
X-Spam-Level:
X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TkXpExlFTsJ; Tue, 13 Feb 2018 02:26:06 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510E21241F5; Tue, 13 Feb 2018 02:26:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=250951; q=dns/txt; s=iport; t=1518517565; x=1519727165; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=Cd09U497L1vQv8RWls1SzdL0Kgfgqi3twzWYCugTRa8=; b=kRdFJPQaup+maHFR8IOiSZkF+f9j0IzJ91ue+pSgrQSaiLKe1EioiLDO +k/aQrqY9M14Vn5JsSGXCeUMJZAmJC2xpMG7nJ/Lxc3T0oNFhGJjkqI4H 3L++/eMHpOTvygeuVMqPyZ2xKVflkw83V23XHeA3XLwtZ2Iz/ZchSgssW 0=;
X-Files: PastedGraphic-6.png : 43631
X-IronPort-AV: E=Sophos;i="5.46,507,1511827200"; d="png'150?scan'150,208,217,150";a="1986413"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2018 10:26:03 +0000
Received: from ams-iwijnand-8813.cisco.com (ams-iwijnand-8813.cisco.com [10.60.202.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1DAQ2aS001210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Feb 2018 10:26:02 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_4040506F-A773-4102-AACB-21822BF05CF6"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: IJsbrand Wijnands <ice@cisco.com>
In-Reply-To: <5A82A9D8.7050606@cisco.com>
Date: Tue, 13 Feb 2018 11:26:07 +0100
Cc: Tony Przygienda <tonysietf@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "bier@ietf.org" <bier@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Message-Id: <366D5764-C195-469C-826A-90DC9F5E6307@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> <5A 82A9D8.7050606@cisco.com>
To: Peter Psenak <ppsenak@cisco.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/Cl0dO2njG2MjvzTICvqWKmWq66U>
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 10:26:11 -0000
+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> 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 >> > > > > 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%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:bier-bounces@ietf.org%3e>] >> On Behalf Of >> > Tony Przygienda >> > > > > Sent: Friday, July 21, >> 2017 5:17 AM >> > > > > To: Toerless Eckert >> > > > > Cc: Hannes Gredler >> (hannes@gredler.at <mailto:hannes@gredler.at> >> > <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> >> 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%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%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>>____ >> > >> > __ __ >> > >> > >> > >> > >> > >> _______________________________________________ >> > BIER mailing list >> > BIER@ietf.org >> <mailto:BIER@ietf.org> <mailto:BIER@ietf.org <mailto:BIER@ietf.org>> >> > https://www.ietf.org/mailman/listinfo/bier >> <https://www.ietf.org/mailman/listinfo/bier> >> > >> <https://www.ietf.org/mailman/listinfo/bier >> <https://www.ietf.org/mailman/listinfo/bier>> >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > BIER mailing list >> > BIER@ietf.org <mailto:BIER@ietf.org> >> > https://www.ietf.org/mailman/listinfo/bier >> <https://www.ietf.org/mailman/listinfo/bier> >> > >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org <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> >> 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> >> 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> >> https://www.ietf.org/mailman/listinfo/bier >> <https://www.ietf.org/mailman/listinfo/bier> >> >> >
- [Isis-wg] WGLC: draft-ietf-bier-isis-extensions-04 Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Toerless Eckert
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Toerless Eckert
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Toerless Eckert
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands (iwijnand)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Alia Atlas
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Alia Atlas
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Greg Shepherd
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Peter Psenak
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Peter Psenak
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Acee Lindem (acee)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Acee Lindem (acee)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Peter Psenak
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… IJsbrand Wijnands
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Acee Lindem (acee)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Eric C Rosen
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Les Ginsberg (ginsberg)
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Tony Przygienda
- Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-e… Xiejingrong