Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
Tony Przygienda <tonysietf@gmail.com> Tue, 13 February 2018 07:17 UTC
Return-Path: <tonysietf@gmail.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F1B126CC4; Mon, 12 Feb 2018 23:17:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJUVXbQa9YZ1; Mon, 12 Feb 2018 23:16:59 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDE5126CD6; Mon, 12 Feb 2018 23:16:58 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id x4so11935287wmc.0; Mon, 12 Feb 2018 23:16:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HFuPALqFNcpKkrUZJ27ibkc+uCSEex5nrGyamwSlq1M=; b=JYb5aU76Nrmnrgfs8FqgXGYNSmiBJ83wwJ0soRiJPj4fNLrzCKTDww2964FZm7t4ss nCqupns4BTYvNInflQZQZDjwVECyJR/h/UsRupzqybdAdMorechbeSBlFTLCFR8+XIrj peXsyC92FlupfWrRm6nB+AjV7N8CFUHXGUqEZ8GEEySdc3hb8mQAdLQpm0kAVKNuadVJ bp0UW39RuvByDc5O8/vyunWJYSDbpsZCy9VK3vZLOD0MG8MymqXU3YCvCZzi7WfP55f6 SuXt+knnpHnfmhXog/I0GmbAUUBnoo+3oMqfq8a8wMxv+kJoLsUTyAln8dD2s8RN9HtC f5Sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HFuPALqFNcpKkrUZJ27ibkc+uCSEex5nrGyamwSlq1M=; b=qoLvz8fo8n1kGWKRBRJLfltt7NCF7SAG43z8zrZoiM3NQk90VAo46uXM8tB8Tam9aZ a8g63T3I+00DbHcLRKltAw+vDfERwuPUhd7vWmMN44gG6WEFBuZQ0mlJy7xTiEjjiY/W bKs+RE4m7dkKVfLA5HoD2GvrZw+CRxg/wc0WCx/DJgURj306JfT18Y42LRSUZbNrYxwk kTB6BUYTDOGkgRpP7DOpBcx4a3q1/+TjHqawWJ07LQ/Jhzmez82nA1kTVDU8ymUlPl4y jDS/JYOL3Jy+qIWlaRCbOwU8Fd8KoEVErBaFChhxKtHmpFdK5W0bIMlq9AJ/957L/OtZ 6pSQ==
X-Gm-Message-State: APf1xPDT+7a9OrzuaDSkuqTDKN7SpsGIVR9pAOr+9WRkXsSyr/l/cWNH etBu8TG5WGY+zebh1LA2jRiuLtCcJOgY5iB2sdU=
X-Google-Smtp-Source: AH8x224pb0NTYKz80sJHKCo2eaTdNK85peTEXGt+5NdRohB7EtQ/kJL9sRWaoHoagB56/c80D/n7ts9AnCq9+mWr5+o=
X-Received: by 10.80.155.90 with SMTP id a26mr860210edj.290.1518506216473; Mon, 12 Feb 2018 23:16:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.231.7 with HTTP; Mon, 12 Feb 2018 23:16:15 -0800 (PST)
In-Reply-To: <07df09dda97e4dad9450a4a9799ae8c7@XCH-ALN-001.cisco.com>
References: <20170721062741.GA3215@faui40p.informatik.uni-erlangen.de> <CA+wi2hOCZkLeuqnqr-waNMtaex+Pjq3rXzH-HVqJhLkWQUgj_Q@mail.gmail.com> <567fdbe4992c4207b54c77b1ec8cd0cd@XCH-ALN-001.cisco.com> <20170722133419.GA18218@faui40p.informatik.uni-erlangen.de> <37e324dc58454778b70c72255066536f@XCH-RCD-001.cisco.com> <20170725195211.GA7411@faui40p.informatik.uni-erlangen.de> <CABFReBpt088=SC3eBcfFbJ24e_+GkDmvKh05AaQtUmCoaKEG3w@mail.gmail.com> <cd2bcf2853684097a3d21fd20742d4ed@XCH-ALN-001.cisco.com> <CABFReBqEJu5nBMdJm0cmBuUYhatD+JRCpn7TppC-hgV4HGZ3sQ@mail.gmail.com> <CA+wi2hNOf=UZja29OVDGWJMvULoyJP7Uj_OnZYVakNiX0-59Aw@mail.gmail.com> <CAG4d1rcZnZmbfU3AnLgfCJmOz-dJ0uv8VUZE+BQ9Qq3B=7DgZg@mail.gmail.com> <CA+wi2hNrQV+gyQS_ts-38w2OWYOkTXUy-Q3b0FAGKaztE8D+QQ@mail.gmail.com> <CABFReBoWZeQxnOCERr9EVykE5dY8p04KQT=JsDqk2eN2Q9p_2g@mail.gmail.com> <CA+wi2hPtxa_Z7VS6Hnj5Y4iQG3RUx7GP6exkf9o4ZcQr2eU_ig@mail.gmail.com> <5A81ABAC.107@cisco.com> <69EEC1F9-3077-4260-BB7A-66F0AEB3357D@cisco.com> <CA+wi2hO0ZPS=3aNY_Et1ChRhzQVJvr1dPiB-ugiC6iGDNpfyfA@mail.gmail.com> <DC7DFF2A-C986-4EA3-A701-6C80C867560B@cisco.com> <CDCE115D-C3AD-47DA-9993-6AC0BD88ED2D@cisco.com> <771dbad8841b42ac8ea3012dc73ef33b@XCH-ALN-001.cisco.com> <CC1CC82E-E134-4931-9735-07A0D0E64997@cisco.com> <e1ce91bb9d28485fbaad63252e1e0e3c@XCH-ALN-001.cisco.com> <E35F158F-2F97-47FD-8272-497B68ABDD1B@cisco.com> <07df09dda97e4dad9450a4a9799ae8c7@XCH-ALN-001.cisco.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Mon, 12 Feb 2018 23:16:15 -0800
Message-ID: <CA+wi2hNK1WRN89q0uUOF4FLkDHoBBtUZhLxqrceY-q_zu7=8zg@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "IJsbrand Wijnands (iwijnand)" <ice@cisco.com>, "bier@ietf.org" <bier@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, "isis-wg@ietf.org list" <isis-wg@ietf.org>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
Content-Type: multipart/related; boundary="94eb2c1af4629f6498056512c7ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/Bh0YorcRSbfleKXyLcfhDjoO_Pg>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Feb 2018 07:17:04 -0000
+1 what Les says as my understanding of the problem we're tackling here ... --- tony On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com > wrote: > Ice – > > > > MY understanding is that – in the future – there may be additional encaps > defined for BIER. When that happens, a given BFR may support multiple > encaps. In such a case, it is OK if other BFRs supporting the same <MT,SD> > only support one of the set of encaps – so long as we have one encap in > common we can successfully forward. I believe that is the case the text > change is trying to address – not encap vs no encap. The original text > would have required identical sets of encaps to be supported by all BFRs > for a give <MT,SD> - which is unnecessarily restrictive. > > > > Make sense? > > > > Les > > > > > > *From:* IJsbrand Wijnands (iwijnand) > *Sent:* Monday, February 12, 2018 1:50 PM > > *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com> > *Cc:* Acee Lindem (acee) <acee@cisco.com>; bier@ietf.org; Peter Psenak > (ppsenak) <ppsenak@cisco.com>; isis-wg@ietf.org list <isis-wg@ietf.org> > *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 > > > > Les, > > > > (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is > being used, this means that every BFR that is advertising a label > for sub-domain S is advertising a label for the combination of > sub-domain S and Disposition BitStringLength L.) > > > > It says, if MPLS encapsulation is used, there is a Label for the {SD, > BSL}. So, if there is non-MPLS (ether) only, there will not be a Label and > the compatibility check will fail. Is that not the same a router that does > not support MPLS BIER, and treated as a non-BIER router? > > > > [Les:] I don’t see how this text can be used to mean “multiple encap types > can be supported on the same BFR for a given <MT,SD>”. > ??? > > > > Are these not like ships in the night? Like an Prefix can be reachable > over MPLS and IP on the same interface? I do assume you want to stay with > the encapsulation that you where provisioned in and not move from MPLS into > non-MPLS. Why do you need to say you can support both? > > > > Thx, > > > > Ice. > > > > > > On 12 Feb 2018, at 22:16, Les Ginsberg (ginsberg) <ginsberg@cisco.com> > wrote: > > Ice - > > From: IJsbrand Wijnands (iwijnand) > Sent: Monday, February 12, 2018 12:58 PM > To: Les Ginsberg (ginsberg) <ginsberg@cisco.com> > Cc: Acee Lindem (acee) <acee@cisco.com>; bier@ietf.org; Peter Psenak > (ppsenak) <ppsenak@cisco.com>; isis-wg@ietf.org list <isis-wg@ietf.org> > Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 > > Les, > > > Perhaps the thread is too long and you have gotten confused. J > > Maybe :-), but... > > > The point being discussed now is support for multiple encapsulation types > (BSL conversion was mentioned in the thread – but it is NOT the subject > being discussed at the moment). > > I got that, it was removed after a long debate sometime back. > > > > In latest IS-IS BIER draft we changed: > > > All routers in the flooding scope of the BIER TLVs MUST > advertise the > > same encapsulation for a given <MT,SD>. A router discovering > > encapsulation advertised that is different from its own MUST > report a > > misconfiguration of a specific <MT,SD>. All received BIER > > advertisements associated with the conflicting <MT, SD> pair > MUST be > > ignored. > > > > " > > > > to > > > > " > > > > Multiple encapsulations MAY be advertised/supported for a given > > <MT,SD>. Clearly, however, there MUST be at least one > encapsulation > > type in common in order for a BIER encapsulated packet to be > > successfully forwarded between two BFRs. > > > > Point has been made that this really belongs in the architecture RFC, but > since it isn’t there it may make sense for the IGP drafts to mention it. > > Below is taken from "6.10.1. BitStringLength Compatibility Check” RFC > 8279, does this not cover it? > > **** > The combination of sub-domain S and Imposition BitStringLength L > passes the BitStringLength Compatibility Check if and only if the > following condition holds: > > Every BFR that has advertised its membership in sub-domain S has > also advertised that it is using Disposition BitStringLength L > (and possibly other BitStringLengths as well) in that sub-domain. > (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is > being used, this means that every BFR that is advertising a label > for sub-domain S is advertising a label for the combination of > sub-domain S and Disposition BitStringLength L.) > > If a BFIR has been provisioned to use a particular Imposition > BitStringLength and a particular sub-domain for some set of packets, > and if that combination of Imposition BitStringLength and sub-domain > does not pass the BitStringLength Compatibility Check, the BFIR > SHOULD log this fact as an error. > **** > > [Les:] I don’t see how this text can be used to mean “multiple encap types > can be supported on the same BFR for a given <MT,SD>”. > ??? > > Les > > > Thx, > > Ice. > > > > In the case of IS-IS, because earlier versions of the draft had an > explicit statement which we now consider too limiting, it made sense to > make an explicit statement of the more flexible behavior. > > In the case of OSPF, the overly restrictive text was never present, so it > is more debatable as to whether the clarifying statement is needed – but > doing so keeps the drafts in sync. > > Still, the “right solution” would be to have the statement in RFC 8279 – > but a bit late for that. > > Les > > > From: IJsbrand Wijnands (iwijnand) > Sent: Monday, February 12, 2018 12:05 PM > To: Acee Lindem (acee) <acee@cisco.com> > Cc: Tony Przygienda <tonysietf@gmail.com>; Les Ginsberg (ginsberg) < > ginsberg@cisco.com>; bier@ietf.org; isis-wg@ietf.org list < > isis-wg@ietf.org>; Peter Psenak (ppsenak) <ppsenak@cisco.com> > Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 > > Folks, > > I would say its wrong to try and fix the BIER architecture by adding this > into the IGP drafts. The IGP is a pass-through for the BIER information, > and adding this text seems to imply that the IGP now needs to become > BIER aware in order to detect and trigger notifications of encapsulation > incompatibilities. > > The BIER architecture RFC 8279 has section 6.10 "Use of Different > BitStringLengths within a Domain”, what is missing in that section that > would justify the IGP to become aware of BitStringLength differences? IMO > everything is covered. > > Thx, > > Ice. > > > On 12 Feb 2018, at 19:33, Acee Lindem (acee) <acee@cisco.com> wrote: > > Hi Tony, > I agree that since architecture has been published, it would not hurt to > add the 5.2 text to the IGP documents. > Thanks, > Acee > > From: Tony Przygienda <tonysietf@gmail.com> > Date: Monday, February 12, 2018 at 12:13 PM > To: Acee Lindem <acee@cisco.com> > Cc: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "Les Ginsberg > (ginsberg)" <ginsberg@cisco.com>, "bier@ietf.org" <bier@ietf.org>, "isis-wg@ietf.org > list" <isis-wg@ietf.org> > Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04 > > Peter, Acee, agree that this was missed in architecture and we should have > talked about multiple encaps on a link there (just like we mentioned the > BSL conversion). Alas, it was theoretical then and we missed. It was just > a suggestion here to put it into IGP draft as we did in ISIS. I'm fine > whichever way you guys feel it's better and a clarification draft can be > always published later after more experience in the field albeit it seems > that the issue is straight fwd' for most old hands, it's a link local > decision so just use any matching encaps to transfer, however > the computation has to agree to prevent blackholes ... > > Otherwise went through the important sections on -11 and looks good to me, > no further comments. Thanks for the work > > --- tony > > On Mon, Feb 12, 2018 at 7:58 AM, Acee Lindem (acee) <acee@cisco.com> > wrote: > With respect to the text in section 5.2, I agree with Peter. > > Thanks > Acee > > On 2/12/18, 9:59 AM, "BIER on behalf of Peter Psenak (ppsenak)" <bier-bounces@ietf.org > on behalf of ppsenak@cisco.com> wrote: > > Hi Tony, > > OSPF does not have the original text, so it does not need the new one. > > IMHO, the text in section 5 of ISIS BIER draft suits better to the BIER > architecture draft than to the IGP extension draft. > > thanks, > Peter > > > On 09/02/18 20:17 , Tony Przygienda wrote: > > Sure ;-) let me ping Peter @ the bottom then ... I don't think any > of > > the stuff applies to OSPF (was ISIS nits) except we can consider an > > encaps paragraph. We basically suggest both to replace in ISIS the > > encaps section like this > > > > before: > > > > " > > All routers in the flooding scope of the BIER TLVs MUST > advertise the > > same encapsulation for a given <MT,SD>. A router discovering > > encapsulation advertised that is different from its own MUST > report a > > misconfiguration of a specific <MT,SD>. All received BIER > > advertisements associated with the conflicting <MT, SD> pair > MUST be > > ignored. > > > > " > > > > now > > > > " > > > > Multiple encapsulations MAY be advertised/supported for a given > > <MT,SD>. Clearly, however, there MUST be at least one > encapsulation > > type in common in order for a BIER encapsulated packet to be > > successfully forwarded between two BFRs. > > > > " > > > > I do think that OSPF would benefit from adding this section to > clarify > > the issue which is not theoretical now that we have Ethernet. > > > > > > So Peter, any ETA on outstanding OSPF nits now that we're tying up > the > > IETF LC? > > > > thanks > > > > --- tony > > > > > > On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd <gjshep@gmail.com > <gjshep@gmail.com%0b%C2%A0%20>> <mailto:gjshep@gmail.com > <gjshep@gmail.com>>> wrote: > > > > No I didn't. Why would I? These are the changes you and Les > worked > > out. I assumed you'd share them as needed. If for some reason > you're > > uncomfortable engaging with the OSPF draft thread and authors > with > > your proposed changes, let me know and I'll broker the > conversation. > > > > Greg > > > > On Fri, Feb 9, 2018 at 11:04 AM, Tony Przygienda > > <tonysietf@gmail.com <mailto:tonysietf@gmail.com>> wrote: > > > > Les has the diff, I'd expect him to publish any minute to the > > list ... The encaps was a real defect, the rest is just > > tightening down the language/spec where it was too loose/too > > strict. > > > > OSPF still needs update with conversion TLV removed, same > > paragraph on encaps could be useful. I hope Greg pinged > Peter ... > > > > thanks > > > > tony > > > > On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas < > akatlas@gmail.com > <akatlas@gmail.com%0b%C2%A0%20>> <mailto:akatlas@gmail.com > <akatlas@gmail.com>>> wrote: > > > > On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda > > <tonysietf@gmail.com <mailto:tonysietf@gmail.com>> > wrote: > > > > Went last nits with Les, we found one issue (encaps > > section was wrong, need to look @ OSPF as well) and > > basically tightened language in few places. > > > > > > K - please get that out with the details of changes to > the > > list. I did my AD review back in Oct and looked at the > > differences before issuing > > IETF Last Call. > > > > I look forward to reviewing the minor changes. > > > > Regards, > > Alia > > > > tony > > > > On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd > > <gjshep@gmail.com <mailto:gjshep@gmail.com>> wrote: > > > > Thanks Les. > > > > Any other feedback? Looks like the concerns have > > been addressed. Speak now. > > > > Cheers, > > Greg > > > > On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg > > (ginsberg) <ginsberg@cisco.com > <ginsberg@cisco.com%0b%C2%A0%20>> < > mailto:ginsberg@cisco.com <ginsberg@cisco.com>>> wrote: > > > > Greg –____ > > > > __ __ > > > > This thread is outdated.____ > > > > In V6 of the draft we removed the > restriction to > > limit IS-IS BIER support to area boundaries > – so > > Toerless’s comment (and my proposed text) > are no > > longer relevant.____ > > > > __ __ > > > > Specifically:____ > > > > __ __ > > > > Section 4.1:____ > > > > __ __ > > > > “At present, IS-IS support for a given BIER > > domain/sub-domain is ____ > > > > limited to a single area > - > > or to the IS-IS L2 sub-domain.”____ > > > > __ __ > > > > The above text was removed.____ > > > > __ __ > > > > Section 4.2____ > > > > __ __ > > > > o BIER sub-TLVs MUST NOT be included when a > > prefix reachability____ > > > > advertisement is leaked between > levels.____ > > > > __ __ > > > > Was changed to____ > > > > __ __ > > > > o BIER sub-TLVs MUST be included when a > prefix > > reachability____ > > > > advertisement is leaked between > levels.____ > > > > __ __ > > > > This aligns IS-IS and OSPF drafts in this > > regard.____ > > > > __ __ > > > > Les____ > > > > __ __ > > > > *From:*Greg Shepherd [ > mailto:gjshep@gmail.com > > <mailto:gjshep@gmail.com> > <gjshep@gmail.com%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:gjshep@gmail.com%3e> > ] > > *Sent:* Thursday, February 01, 2018 2:23 AM > > *To:* Toerless Eckert <tte@cs.fau.de > <tte@cs.fau.de%0b%C2%A0%20>> < > mailto:tte@cs.fau.de <tte@cs.fau.de>>> > > *Cc:* Les Ginsberg (ginsberg) > > <ginsberg@cisco.com > <ginsberg@cisco.com%0b%C2%A0%20>> < > mailto:ginsberg@cisco.com <ginsberg@cisco.com>>>; Tony Przygienda > > <tonysietf@gmail.com > <tonysietf@gmail.com%0b%C2%A0%20>> < > mailto:tonysietf@gmail.com <tonysietf@gmail.com>>>; Hannes Gredler > > (hannes@gredler.at <mailto:hannes@gredler.at > <hannes@gredler.at>>) > > <hannes@gredler.at <mailto:hannes@gredler.at > >>; > > bier@ietf.org <mailto:bier@ietf.org > <bier@ietf.org>>; > > isis-wg@ietf.org <mailto:isis-wg@ietf.org > <isis-wg@ietf.org>> list > > <isis-wg@ietf.org <mailto:isis-wg@ietf.org > >>; > > Christian Hopps <chopps@chopps.org > <chopps@chopps.org%0b%C2%A0%20>> < > mailto:chopps@chopps.org <chopps@chopps.org>>> > > > > > > *Subject:* Re: [Bier] WGLC: > > draft-ietf-bier-isis-extensions-04____ > > > > __ __ > > > > Have these changes been reflected in the > draft? > > We're in WGLC but this discussion needs to > come > > to a conclusion so we can progress. ____ > > > > __ __ > > > > Greg____ > > > > __ __ > > > > On Tue, Jul 25, 2017 at 12:52 PM, Toerless > > Eckert <tte@cs.fau.de <mailto:tte@cs.fau.de > >> > > wrote:____ > > > > Thanks, Less, that would be lovely! > > > > I didn't check the OSPF draft, if its > > similar state, explanatory text wold > equally > > be appreciated.____ > > > > > > On Sun, Jul 23, 2017 at 11:28:08PM +0000, > > Les Ginsberg (ginsberg) wrote: > > > Toerless - > > > > > > I am thinking to add a statement in > > Section 4.1 - something like: > > > > > > "At present, IS-IS support for a given > > BIER domain/sub-domain is limited to a > > single area - or to the IS-IS L2 > sub-domain." > > > > > > If you believe this would be helpful I > > will spin a new version (subject to > > review/agreement from my co-authors). > > > > > > Les > > > > > > > > > > -----Original Message----- > > > > From: Toerless Eckert > > [mailto:tte@cs.fau.de > <mailto:tte@cs.fau.de> <tte@cs.fau.de%20%3cmailto:tte@cs.fau.de%3e>] > > > > Sent: Saturday, July 22, 2017 6:34 > AM > > > > To: Les Ginsberg (ginsberg) > > > > Cc: Tony Przygienda; Hannes Gredler > > (hannes@gredler.at > > <mailto:hannes@gredler.at > <hannes@gredler.at>>); Greg Shepherd; > > > > bier@ietf.org <mailto:bier@ietf.org > <bier@ietf.org>>; > > isis-wg@ietf.org <mailto: > isis-wg@ietf.org <isis-wg@ietf.org>> > > list; Christian Hopps > > > > Subject: Re: [Bier] WGLC: > > draft-ietf-bier-isis-extensions-04 > > > > > > > > Thanks Les > > > > > > > > When searching various terms in the > doc > > to figure out what happens i am not > > > > sure why i missed this one. > > > > > > > > But: IMHO, RFCs can not only be the > > minimum number of words to get a > > > > running implementation. It also > needs > > to specify what this implementation > > > > intends to achieve. Otherwise its > not > > possible to do a useful review: > > > > The reviewer can to verify whether > the > > spec will achieve what it claims to > > > > achieve is there no definitionn of > what > > it claims to achieve. > > > > > > > > If i understand ISIS correctly, my > > reverse engineering of the intent is: > > > > > > > > - BIER TLVs stay within single ISIS > > areas. BFIR and BFER must therefore be > > > > in the same ISIS area: There is no > > inter-area BIER traffic possible > > > > with this specification. This is > also > > true for ISIS area 0. > > > > > > > > - The same BIER sub-domain > identifiers > > can be re-used > > > > across different ISIS areas > without > > any current impact. If these BFR-IDs > > > > are non-overlapping, then this > would > > allow in the future to create a single > > > > cross ISIS area BIER sub-domain by > > leaking TLVs for such a BIER sub-domain > > > > across ISIS levels. Leakage is > > outside the scope of this > specificication. > > > > > > > > I actually even would like to do the > > following: > > > > > > > > - If BIER sub-domains are made to > span > > multiple ISIS areas and BFR-ids > > > > assignemtns > > > > are made such that all BFR-ids > with > > the same SI are in the same ISIS ara, > > > > then it should be in the future > > reasonably easy to create inter-area BIER > > > > not by leaking of the BIER TLV > but by > > having BFIR MPLS unicastBIER packets > > > > for different SIs to an > appropriate > > L2L1 BFIR that is part of the destination > > > > area/SI. > > > > (if you would use SI number that > are > > the same as ISIS area numbers then > > > > you could probably do this > without > > any new signaling. Not quite sure if > > > > you can today easily find L1L2 > > border router for another area via > existing > > > > TLVs). > > > > > > > > Alas, this idea will probably be > > killed because of the BIER architecture > > > > intent not to engineer SI > assignments > > in geographical fashions to > > > > minimize traffic duplication in > the > > presence of multiple SIs. > > > > > > > > Cheers > > > > Toerless > > > > > > > > On Sat, Jul 22, 2017 at 06:03:53AM > > +0000, Les Ginsberg (ginsberg) wrote: > > > > > Tony/Toerless ??? > > > > > > > > > > There is an explicit statement as > to > > scope: > > > > > > > > > > <snip> > > > > > Section 4.2 > > > > > ??? > > > > > o BIER sub-TLVs MUST NOT be > > included when a prefix reachability > > > > > advertisement is leaked > between > > levels. > > > > > <end snip> > > > > > > > > > > Tony seems to have forgotten that > we > > had a discussion about how BIER > > > > might be supported across areas and > the > > conclusion was we did not know > > > > how to do that yet. > > > > > (Sorry Tony) > > > > > > > > > > Note this is ???consistent??? with > > https://www.ietf.org/id/draft-ietf-bier- > > <https://www.ietf.org/id/ > draft-ietf-bier-> > > > > ospf-bier-extensions-07.txt Section > > 2.5<https://www.ietf.org/id/draft-ietf- > <https://www.ietf.org/id/draft-ietf-%0b%C2%A0%20>> > <https://www.ietf.org/id/draft-ietf-> > > > > > > bier-ospf-bier-extensions-07. > txt%20Section%202.5> > > - which limits the > > > > flooding scope of BIER information > to a > > single area unless it can be validated > > > > that the best path to the prefix > with > > BIER info can be validated to be to a > > > > router which itself advertised the > BIER > > info. This is not something IS-IS can do > > > > since a single IS-IS instance only > > supports one area and therefore does not > > > > have the Level-1 advertisements of > the > > originating router when that router is > > > > in another area. > > > > > > > > > > A few more responses inline. > > > > > > > > > > From: BIER > > [mailto:bier-bounces@ietf.org > > <mailto:bier-bounces@ietf.org> > <bier-bounces@ietf.org%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:bier-bounces@ietf.org%3e>] > On Behalf Of > > Tony Przygienda > > > > > Sent: Friday, July 21, 2017 5:17 > AM > > > > > To: Toerless Eckert > > > > > Cc: Hannes Gredler ( > hannes@gredler.at > > <mailto:hannes@gredler.at > <hannes@gredler.at>>); Greg Shepherd; > > bier@ietf.org <mailto:bier@ietf.org > <bier@ietf.org>>; > > > > > isis-wg@ietf.org > > <mailto:isis-wg@ietf.org > <isis-wg@ietf.org>> list; Christian Hopps > > > > > Subject: Re: [Bier] WGLC: > > draft-ietf-bier-isis-extensions-04 > > > > > > > > > > Terminology is a bit nits IMO > since > > the doc is reading clear enough for > > > > someone who read BIER & ISIS. I can > > reread it or Les can comment whether > > > > we should tighten glossary ... > > > > > > > > > > With the scope I agree, that got > lost > > and the doc should be possibly rev'ed > > > > before closing LC. Yes, we flood AD > > wide was the agreement but something > > > > mentioning that this could change in > > the future is good so we are forced to > > > > give it some thought how that would > > transition ... > > > > > > > > > > Thinking further though, in ISIS > we > > have a clean document really. The BIER > > > > sub-TLVs go into well defined TLVs > in > > terms of flooding scope. Normal L1-L2 > > > > redistribution can be used to get > the > > info to all needed places AFAIS. So > > > > maybe nothing needs to be written. I > > wait for Les to chime in. > > > > > > > > > > OSPF I would have to look @ scopes > > again & think whether we need to > > > > write something or maybe Peter can > > comment ... > > > > > > > > > > --- tony > > > > > > > > > > > > > > > > > > > > On Fri, Jul 21, 2017 at 8:27 AM, > > Toerless Eckert > > > > <tte@cs.fau.de > <tte@cs.fau.de%0b%C2%A0%20>> < > mailto:tte@cs.fau.de <tte@cs.fau.de>><mailto:tte@cs.fau.de > <tte@cs.fau.de%0b%C2%A0%20>> < > mailto:tte@cs.fau.de <tte@cs.fau.de>>>> wrote: > > > > > Sorry, past the two weeks, but > > hopefully benign textual comments: > > > > > > > > > > We tried to find an explicit > > statement about the scope of BIER TLVs - > eg: > > > > > are they meant to stay within an > > area, have some redistribution across > > > > > areas/levels or not. > > > > > > > > > > Tony said WG agreement was to have > > these TLV be flooded across the > > > > > whole ISIS domain for now (this > > draft). So an explicit statement to that > > > > effect would > > > > > be great (All BIER sub-domains > TLVs > > are flooded across all ISIS areas/levels, > > > > so they span the whole ISIS domain). > > > > > > > > > > Also, if future work may/should > could > > improve on that maybe some > > > > > sentence about that (i guess one > > could just have ISIS intra-area BIER sub- > > > > domains ?). > > > > > > > > > > Also: Do a check about possible > > ambiguity of any generic terms like > > > > sub-domain, level, area, topology so > > that reader that don't know the > > > > terminology ofall protocols (ISIS, > > BIER) by heart can easily know which > > > > protocol is referred to. > > > > > > > > > > [Les:] There is no mention of > > ???level??? in the document. > > > > > The use of ???sub-domain??? is > > clearly always associated with > ???BIER???. > > > > > ???topology??? is always used as > an > > RFC 5120 topology ??? therefore > > > > clearly an IS-IS topology. > > > > > There is only one use of the term > > ???area??? (in Section 5.1). That text > > > > might deserve a bit of clarification > > given this might be either a Level 1 > area or > > > > the Level2 sub-domain. I???ll take a > > pass at it. > > > > > (BTW ??? I am talking about IS-IS > > area/L2sub-domain Toerless. ???) > > > > > > > > > > I don???t see that any other > > clarification is needed ??? but Toerless > ??? if > > > > you can point to any specific > > sentences/paragraphs which you find > confusing > > > > - I???ll take a second look. > > > > > > > > > > Les > > > > > > > > > > > > > > > I guess there are no BIER level, > area > > or topologies, but still makes > > > > > reading easier if the doc would > say > > "ISIS level", "ISIS area", or at > > > > > least have them in the Terminology > > section. And probably in > > > > > terminology say "domain -> in the > > context of this document the BIER > > > > domain which is also the same as the > > ISIS domain" > > > > > (which i hope is the correct > > statement, see above). > > > > > > > > > > Cheers > > > > > Toerless > > > > > > > > > > > > ______________________________ > _________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > <mailto:BIER@ietf.org <BIER@ietf.org>>< > mailto:BIER@ietf.org > <BIER@ietf.org%0b%C2%A0%20>> < > mailto:BIER@ietf.org <BIER@ietf.org>>> > > > > > > > https://www.ietf.org/ > mailman/listinfo/bier > > <https://www.ietf.org/mailman/ > listinfo/bier> > > > > > > > > > > > > > > > > > > > > -- > > > > > We???ve heard that a million > monkeys > > at a million keyboards could > > > > produce the complete works of > > Shakespeare; now, thanks to the Internet, > > > > we know that is not true. > > > > > ???Robert Wilensky > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de <mailto:tte@cs.fau.de > <tte@cs.fau.de>>____ > > > > __ __ > > > > > > > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org <mailto:BIER@ietf.org <BIER@ietf.org>> > > https://www.ietf.org/mailman/listinfo/bier > > <https://www.ietf.org/mailman/listinfo/bier> > > > > > > > > > > > > > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > <image001.png> > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > <image001.png> > > > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > >
- [Bier] WGLC: draft-ietf-bier-isis-extensions-04 Greg Shepherd
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Toerless Eckert
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Les Ginsberg (ginsberg)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Toerless Eckert
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Les Ginsberg (ginsberg)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Toerless Eckert
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Greg Shepherd
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Les Ginsberg (ginsberg)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Greg Shepherd
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Greg Shepherd
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… IJsbrand Wijnands (iwijnand)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Greg Shepherd
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Alia Atlas
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Alia Atlas
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Greg Shepherd
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- [Bier] Fwd: WGLC: draft-ietf-bier-isis-extensions… Alia Atlas
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Les Ginsberg (ginsberg)
- [Bier] Fwd: WGLC: draft-ietf-bier-isis-extensions… Alia Atlas
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… IJsbrand Wijnands
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Peter Psenak
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Peter Psenak
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Acee Lindem (acee)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Acee Lindem (acee)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… IJsbrand Wijnands
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Les Ginsberg (ginsberg)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… IJsbrand Wijnands
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Les Ginsberg (ginsberg)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… IJsbrand Wijnands
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Les Ginsberg (ginsberg)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Peter Psenak
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… IJsbrand Wijnands
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Acee Lindem (acee)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Eric C Rosen
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Les Ginsberg (ginsberg)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Les Ginsberg (ginsberg)
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Tony Przygienda
- Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-… Xiejingrong