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 <akat...@gmail.com> wrote: > On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda <tonysi...@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 <gjs...@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) < >>> ginsb...@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:gjs...@gmail.com] >>>> *Sent:* Thursday, February 01, 2018 2:23 AM >>>> *To:* Toerless Eckert <t...@cs.fau.de> >>>> *Cc:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Tony Przygienda < >>>> tonysi...@gmail.com>; Hannes Gredler (han...@gredler.at) < >>>> han...@gredler.at>; b...@ietf.org; isis-wg@ietf.org list < >>>> isis-wg@ietf.org>; Christian Hopps <cho...@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 <t...@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:t...@cs.fau.de] >>>> > > Sent: Saturday, July 22, 2017 6:34 AM >>>> > > To: Les Ginsberg (ginsberg) >>>> > > Cc: Tony Przygienda; Hannes Gredler (han...@gredler.at); Greg >>>> Shepherd; >>>> > > b...@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- >>>> > > 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:bier-boun...@ietf.org] On Behalf Of Tony >>>> Przygienda >>>> > > > Sent: Friday, July 21, 2017 5:17 AM >>>> > > > To: Toerless Eckert >>>> > > > Cc: Hannes Gredler (han...@gredler.at); Greg Shepherd; >>>> b...@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 >>>> > > <t...@cs.fau.de<mailto:t...@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 >>>> > > > b...@ietf.org<mailto:b...@ietf.org> >>>> > > > 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 >>>> > > >>>> > > -- >>>> > > --- >>>> > > t...@cs.fau.de >>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> BIER mailing list >> b...@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> >> >
_______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
