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

[Peter Psenak <[e-mail]>]

Hi Folks,

can we add an errata to RFC 8279, instead of adding the text to both 
IGP drafts that does not really belong there.


thanks,
Peter

On 13/02/18 08:16 , Tony Przygienda wrote:
> +1 what Les says as my understanding of the problem we're tackling here ...
>
> --- tony
>
> On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Ice –____
>
>     __ __
>
>     MY understanding is that – in the future – there may be additional
>     encaps defined for BIER. When that happens, a given BFR may support
>     multiple encaps. In such a case, it is OK if other BFRs supporting
>     the same <MT,SD> only support one of the set of encaps – so long as
>     we have one encap in common we can successfully forward. I believe
>     that is the case the text change is trying to address – not encap vs
>     no encap. The original text would have required identical sets of
>     encaps to be supported by all BFRs for a give <MT,SD> - which is
>     unnecessarily restrictive.____
>
>     __ __
>
>     Make sense?____
>
>     __ __
>
>        Les____
>
>     __ __
>
>     __ __
>
>     *From:*IJsbrand Wijnands (iwijnand)
>     *Sent:* Monday, February 12, 2018 1:50 PM
>
>
>     *To:* Les Ginsberg (ginsberg) <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* Acee Lindem (acee) <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>; Peter Psenak (ppsenak)
>     <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]> list <[e-mail]
>     <mailto:[e-mail]>>
>     *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04____
>
>     __ __
>
>     Les,____
>
>     __ __
>
>         (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
>                being used, this means that every BFR that is advertising
>         a label
>                for sub-domain S is advertising a label for the
>         combination of
>                sub-domain S and Disposition BitStringLength L.)____
>
>     __ __
>
>     It says, if MPLS encapsulation is used, there is a Label for the
>     {SD, BSL}. So, if there is non-MPLS (ether) only, there will not be
>     a Label and the compatibility check will fail. Is that not the same
>     a router that does not support MPLS BIER, and treated as a non-BIER
>     router?____
>
>     __ __
>
>         [Les:] I don’t see how this text can be used to mean “multiple
>         encap types can be supported on the same BFR for a given <MT,SD>”.
>         ???____
>
>     __ __
>
>     Are these not like ships in the night? Like an Prefix can be
>     reachable over MPLS and IP on the same interface? I do assume you
>     want to stay with the encapsulation that you where provisioned in
>     and not move from MPLS into non-MPLS. Why do you need to say you can
>     support both?____
>
>     __ __
>
>     Thx,____
>
>     __ __
>
>     Ice.____
>
>     __ __
>
>     __ __
>
>         On 12 Feb 2018, at 22:16, Les Ginsberg (ginsberg)
>         <[e-mail] <mailto:[e-mail]>> wrote:
>
>         Ice -
>
>         From: IJsbrand Wijnands (iwijnand)
>         Sent: Monday, February 12, 2018 12:58 PM
>         To: Les Ginsberg (ginsberg) <[e-mail]
>         <mailto:[e-mail]>>
>         Cc: Acee Lindem (acee) <[e-mail] <mailto:[e-mail]>>;
>         [e-mail] <mailto:[e-mail]>; Peter Psenak (ppsenak)
>         <[e-mail] <mailto:[e-mail]>>; [e-mail]
>         <mailto:[e-mail]> list <[e-mail]
>         <mailto:[e-mail]>>
>         Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
>         Les,
>
>
>         Perhaps the thread is too long and you have gotten confused. J
>
>         Maybe :-), but...
>
>
>         The point being discussed now is support for multiple
>         encapsulation types (BSL conversion was mentioned in the thread
>         – but it is NOT the subject being discussed at the moment).
>
>         I got that, it was removed after a long debate sometime back.
>
>
>
>         In latest IS-IS BIER draft we changed:
>
>              >     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.
>              >
>              > "
>              >
>              > to
>              >
>              > "
>              >
>              >     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.
>              >
>
>         Point has been made that this really belongs in the architecture
>         RFC, but since it isn’t there it may make sense for the IGP
>         drafts to mention it.
>
>         Below is taken from "6.10.1.  BitStringLength Compatibility
>         Check” RFC 8279, does this not cover it?
>
>         ****
>         The combination of sub-domain S and Imposition BitStringLength L
>             passes the BitStringLength Compatibility Check if and only
>         if the
>             following condition holds:
>
>                Every BFR that has advertised its membership in
>         sub-domain S has
>                also advertised that it is using Disposition
>         BitStringLength L
>                (and possibly other BitStringLengths as well) in that
>         sub-domain.
>                (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
>                being used, this means that every BFR that is advertising
>         a label
>                for sub-domain S is advertising a label for the
>         combination of
>                sub-domain S and Disposition BitStringLength L.)
>
>         If a BFIR has been provisioned to use a particular Imposition
>             BitStringLength and a particular sub-domain for some set of
>         packets,
>             and if that combination of Imposition BitStringLength and
>         sub-domain
>             does not pass the BitStringLength Compatibility Check, the BFIR
>             SHOULD log this fact as an error.
>         ****
>
>         [Les:] I don’t see how this text can be used to mean “multiple
>         encap types can be supported on the same BFR for a given <MT,SD>”.
>         ???
>
>             Les
>
>
>         Thx,
>
>         Ice.
>
>
>
>         In the case of IS-IS, because earlier versions of the draft had
>         an explicit statement which we now consider too limiting, it
>         made sense to make an explicit statement of the more flexible
>         behavior.
>
>         In the case of OSPF, the overly restrictive text was never
>         present, so it is more debatable as to whether the clarifying
>         statement is needed – but doing so keeps the drafts in sync.
>
>         Still, the “right solution” would be to have the statement in
>         RFC 8279 – but a bit late for that.
>
>             Les
>
>
>         From: IJsbrand Wijnands (iwijnand)
>         Sent: Monday, February 12, 2018 12:05 PM
>         To: Acee Lindem (acee) <[e-mail] <mailto:[e-mail]>>
>         Cc: Tony Przygienda <[e-mail]
>         <mailto:[e-mail]>>; Les Ginsberg (ginsberg)
>         <[e-mail] <mailto:[e-mail]>>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]> list <[e-mail]
>         <mailto:[e-mail]>>; Peter Psenak (ppsenak)
>         <[e-mail] <mailto:[e-mail]>>
>         Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
>         Folks,
>
>         I would say its wrong to try and fix the BIER architecture by
>         adding this into the IGP drafts. The IGP is a pass-through for
>         the BIER information, and adding this text seems to imply that
>         the IGP now needs to become BIER aware in order to detect and
>         trigger notifications of encapsulation incompatibilities.
>
>         The BIER architecture RFC 8279 has section 6.10 "Use of
>         Different BitStringLengths within a Domain”, what is missing in
>         that section that would justify the IGP to become aware of
>         BitStringLength differences? IMO everything is covered.
>
>         Thx,
>
>         Ice.
>
>
>         On 12 Feb 2018, at 19:33, Acee Lindem (acee) <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>         Hi Tony,
>         I agree that since architecture has been published, it would not
>         hurt to add the 5.2 text to the IGP documents.
>         Thanks,
>         Acee
>
>         From: Tony Przygienda <[e-mail]
>         <mailto:[e-mail]>>
>         Date: Monday, February 12, 2018 at 12:13 PM
>         To: Acee Lindem <[e-mail] <mailto:[e-mail]>>
>         Cc: "Peter Psenak (ppsenak)" <[e-mail]
>         <mailto:[e-mail]>>, "Les Ginsberg (ginsberg)"
>         <[e-mail] <mailto:[e-mail]>>, "[e-mail]
>         <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>,
>         "[e-mail] list <mailto:[e-mail]%20list>"
>         <[e-mail] <mailto:[e-mail]>>
>         Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
>         Peter, Acee, agree that this was missed in architecture and we
>         should have talked about multiple encaps on a link there (just
>         like we mentioned the BSL conversion). Alas, it was theoretical
>         then and we missed. It was just a suggestion here to put it into
>         IGP draft as we did in ISIS. I'm fine whichever way you guys
>         feel it's better and a clarification draft can be always
>         published later after more experience in the field albeit it
>         seems that the issue is straight fwd' for most old hands, it's a
>         link local decision so just use any matching encaps to transfer,
>         however the computation has to agree to prevent blackholes  ...
>
>         Otherwise went through the important sections on -11 and looks
>         good to me, no further comments. Thanks for the work
>
>         --- tony
>
>         On Mon, Feb 12, 2018 at 7:58 AM, Acee Lindem (acee)
>         <[e-mail] <mailto:[e-mail]>> wrote:
>         With respect to the text in section 5.2, I agree with Peter.
>
>         Thanks
>         Acee
>
>         On 2/12/18, 9:59 AM, "BIER on behalf of Peter Psenak (ppsenak)"
>         <[e-mail] on behalf of [e-mail]
>         <mailto:[e-mail][e-mail]>>
>         wrote:
>
>              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
>         <[e-mail]
>         <mailto:[e-mail]%0b%C2%A0%20>>
>         <mailto:[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] <mailto:[e-mail]
>         <mailto:[e-mail]%20%3cmailto:[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]
>         <mailto:[e-mail]%0b%C2%A0%20>>
>         <mailto:[e-mail]>> wrote:
>              >
>              >             On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
>              >             <[e-mail]
>         <mailto:[e-mail]
>         <mailto:[e-mail]%20%3cmailto:[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]
>         <mailto:[e-mail]
>         <mailto:[e-mail]%20%3cmailto:[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]
>         <mailto:[e-mail]%0b%C2%A0%20>>
>         <mailto:[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]
>              >                         <mailto:[e-mail]>
>         <mailto:[e-mail]%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:[e-mail]%3e>]
>              >                         *Sent:* Thursday, February 01,
>         2018 2:23 AM
>              >                         *To:* Toerless Eckert <[e-mail]
>         <mailto:[e-mail]%0b%C2%A0%20>>
>         <mailto:[e-mail]>>
>              >                         *Cc:* Les Ginsberg (ginsberg)
>              >                         <[e-mail]
>         <mailto:[e-mail]%0b%C2%A0%20>>
>         <mailto:[e-mail]>>; Tony Przygienda
>              >                         <[e-mail]
>         <mailto:[e-mail]%0b%C2%A0%20>>
>            <mailto:[e-mail]>>; Hannes Gredler
>              >                         ([e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>)
>              >                         <[e-mail]
>         <mailto:[e-mail]
>         <mailto:[e-mail]%20%3cmailto:[e-mail]>>>;
>              > [e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>;
>              > [e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>> list
>              >                         <[e-mail]
>         <mailto:[e-mail]
>         <mailto:[e-mail]%20%3cmailto:[e-mail]>>>;
>              >                         Christian Hopps <[e-mail]
>         <mailto:[e-mail]%0b%C2%A0%20>>
>         <mailto:[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]
>         <mailto:[e-mail]
>         <mailto:[e-mail]%20%3cmailto:[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]
>         <mailto:[e-mail]>
>         <mailto:[e-mail]%20%3cmailto:[e-mail]%3e>]
>              >                              > > Sent: Saturday, July 22,
>         2017 6:34 AM
>              >                              > > To: Les Ginsberg (ginsberg)
>              >                              > > Cc: Tony Przygienda;
>         Hannes Gredler
>              >                             ([e-mail]
>         <mailto:[e-mail]>
>              >                             <mailto:[e-mail]>);
>         Greg Shepherd;
>              >                              > > [e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>;
>              > [e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[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-
>         <https://www.ietf.org/id/draft-ietf-bier->
>              >
>         <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-%0b%C2%A0%20>>
>                        <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:[e-mail]
>              >
>         <mailto:[e-mail]>
>         <mailto:[e-mail]%0b%C2%A0%20%C2%A0%20%3e%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%C2%A0%20%3cmailto:[e-mail]%3e>]
>         On Behalf Of
>              >                             Tony Przygienda
>              >                              > > > Sent: Friday, July 21,
>         2017 5:17 AM
>              >                              > > > To: Toerless Eckert
>              >                              > > > Cc: Hannes Gredler
>         ([e-mail] <mailto:[e-mail]>
>              >                             <mailto:[e-mail]>);
>         Greg Shepherd;
>              > [e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>;
>              >                              > > > [e-mail]
>         <mailto:[e-mail]>
>              >                             <mailto:[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]%0b%C2%A0%20>>
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]%0b%C2%A0%20>>
>         <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]>
>              >
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]%0b%C2%A0%20>>
>         <mailto:[e-mail]>>
>              >                              > > >
>              > https://www.ietf.org/mailman/listinfo/bier
>         <https://www.ietf.org/mailman/listinfo/bier>
>              >
>         <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
>              >                              > >
>              >                              > > --
>              >                              > > ---
>              >                              > > [e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>____
>              >
>              >                         __ __
>              >
>              >
>              >
>              >
>              >
>         _______________________________________________
>              >                 BIER mailing list
>              > [e-mail]
>         <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>              > https://www.ietf.org/mailman/listinfo/bier
>         <https://www.ietf.org/mailman/listinfo/bier>
>              >
>         <https://www.ietf.org/mailman/listinfo/bier
>         <https://www.ietf.org/mailman/listinfo/bier>>
>              >
>              >
>              >
>              >
>              >
>              >
>              >
>              > _______________________________________________
>              > BIER mailing list
>              > [e-mail] <mailto:[e-mail]>
>              > https://www.ietf.org/mailman/listinfo/bier
>         <https://www.ietf.org/mailman/listinfo/bier>
>              >
>
>              _______________________________________________
>              BIER mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/bier
>         <https://www.ietf.org/mailman/listinfo/bier>
>
>
>
>         _______________________________________________
>         BIER mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/bier
>         <https://www.ietf.org/mailman/listinfo/bier>
>
>         <image001.png>
>
>         _______________________________________________
>         BIER mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/bier
>         <https://www.ietf.org/mailman/listinfo/bier>
>
>         <image001.png>____
>
>     __ __
>
>     ____
>
>     __ __
>
>
>     _______________________________________________
>     BIER mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/bier
>     <https://www.ietf.org/mailman/listinfo/bier>
>
>