Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04

[Tony Przygienda <[e-mail]>]

And observe that the encaps section is important in the sense that if two
routers disagree on what is acceptable BIER <MT,SD> advertisement they may
blackhole the forwarding AFAIS. So clarifying this seems necessary ...
thanks. tony

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