On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda <[email protected]> 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 <[email protected]> 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) < >> [email protected]> 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:[email protected]] >>> *Sent:* Thursday, February 01, 2018 2:23 AM >>> *To:* Toerless Eckert <[email protected]> >>> *Cc:* Les Ginsberg (ginsberg) <[email protected]>; Tony Przygienda < >>> [email protected]>; Hannes Gredler ([email protected]) < >>> [email protected]>; [email protected]; [email protected] list < >>> [email protected]>; Christian Hopps <[email protected]> >>> >>> *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 <[email protected]> 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:[email protected]] >>> > > Sent: Saturday, July 22, 2017 6:34 AM >>> > > To: Les Ginsberg (ginsberg) >>> > > Cc: Tony Przygienda; Hannes Gredler ([email protected]); Greg >>> Shepherd; >>> > > [email protected]; [email protected] 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- >>> > > ospf-bier-extensions-07.txt Section 2.5<https://www.ietf.org/id/dr >>> aft-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:[email protected]] On Behalf Of Tony >>> Przygienda >>> > > > Sent: Friday, July 21, 2017 5:17 AM >>> > > > To: Toerless Eckert >>> > > > Cc: Hannes Gredler ([email protected]); Greg Shepherd; >>> [email protected]; >>> > > > [email protected] 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 >>> > > <[email protected]<mailto:[email protected]>> 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 >>> > > > [email protected]<mailto:[email protected]> >>> > > > 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 >>> > > >>> > > -- >>> > > --- >>> > > [email protected] >>> >>> >>> >> >> > > _______________________________________________ > BIER mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bier > >
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
