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

[Alia Atlas <[e-mail]>]

Ice,

The draft is in IETF Last Call.
What is your technical objection to having it go forward as it is?

Regards,
Alia

On Fri, Feb 9, 2018 at 12:13 PM, IJsbrand Wijnands (iwijnand) <[e-mail]
> wrote:

> Greg,
>
> I think there is a confusion here, there is no consensus to remove BAR! We
> want to keep it, but might change the format a little...
>
> Sent from my iPhone
>
> On 9 Feb 2018, at 17:49, Greg Shepherd <[e-mail]> wrote:
>
> Les,
> draft-ietf-bier-isis-extensions still mentions BAR. Is this intentional?
> Then consensus on the thread was to remove BAR.
>
> Greg
>
> 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/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:[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
>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>
>