Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
Peter Psenak <[email protected]> Mon, 12 Feb 2018 15:58:52 +0100
| Newsgroups | gmane.ietf.isis |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> wrote: > > On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda > <[email protected] <mailto:[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] <mailto:[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] > <mailto:[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] > <mailto:[email protected]>] > *Sent:* Thursday, February 01, 2018 2:23 AM > *To:* Toerless Eckert <[email protected] > <mailto:[email protected]>> > *Cc:* Les Ginsberg (ginsberg) > <[email protected] > <mailto:[email protected]>>; Tony Przygienda > <[email protected] > <mailto:[email protected]>>; Hannes Gredler > ([email protected] <mailto:[email protected]>) > <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]> list > <[email protected] <mailto:[email protected]>>; > Christian Hopps <[email protected] > <mailto:[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] <mailto:[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] <mailto:[email protected]>] > > > Sent: Saturday, July 22, 2017 6:34 AM > > > To: Les Ginsberg (ginsberg) > > > Cc: Tony Przygienda; Hannes Gredler > ([email protected] > <mailto:[email protected]>); Greg Shepherd; > > > [email protected] <mailto:[email protected]>; > [email protected] <mailto:[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- > <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-> > > > > 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] > <mailto:[email protected]>] On Behalf Of > Tony Przygienda > > > > Sent: Friday, July 21, 2017 5:17 AM > > > > To: Toerless Eckert > > > > Cc: Hannes Gredler ([email protected] > <mailto:[email protected]>); Greg Shepherd; > [email protected] <mailto:[email protected]>; > > > > [email protected] > <mailto:[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]><mailto:[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]><mailto:[email protected] > <mailto:[email protected]>> > > > > > 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 > > > > > > -- > > > --- > > > [email protected] <mailto:[email protected]>____ > > __ __ > > > > > _______________________________________________ > BIER mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/bier > <https://www.ietf.org/mailman/listinfo/bier> > > > > > > > > _______________________________________________ > BIER mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bier >