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

[Tony Przygienda <[e-mail]>]

As I said, if we think it's more complex than what we wrote for the ISIS
draft then I'm fine with a simple "here be dragons" disclaimer on the
drafts as long we don't leave it as an unmentioned minefield for the
developers.  And then we start a draft standardizing, I foresee a BIER, eeh
beer session @ the bar in London ;-)

--- tony

On Tue, Feb 13, 2018 at 9:06 AM, Les Ginsberg (ginsberg) <[e-mail]
> wrote:

> Tony –
>
>
>
> I think the issues around supporting multiple encap types and how one
> might map one encap to another if your outgoing neighbor did not support
> the incoming encap are much more complex than the simple statement we have
> in the IS-IS draft.
>
> I do think it would be better if we did not make a statement which
> suggests there is a way to support something – but the actual details of
> how to support are still TBD. Better to put that in a draft that has the
> context to completely define such a solution. What is currently in the
> IS-IS isn’t useful w/o the additional detail.
>
>
>
> The new text we have is better than the old text – but I do agree with
> others that it really doesn’t belong in the IGP drafts.
>
>
>
>     Les
>
>
>
>
>
> *From:* Tony Przygienda [mailto:[e-mail]]
> *Sent:* Tuesday, February 13, 2018 8:17 AM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>
> *Cc:* Eric C Rosen <[e-mail]>; Peter Psenak (ppsenak) <
> [e-mail]>; Acee Lindem (acee) <[e-mail]>; [e-mail];
> IJsbrand Wijnands (iwijnand) <[e-mail]>; [e-mail] list <
> [e-mail]>
> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
>
>
> Yes, it's one possible interpretation ;-) albeit I would be more
> comfortable to deliver draft(s) that can be looked @ and implemented as
> they are written and published ;-)
>
> So let's say, if we can all agree that there is one correct interpretation
> (and I suggest of course what we both agreed on but have no vested stake)
> then I prefer to have the drafts put it in as part of IETF LC comments. If
> we cannot agree, be it, let us put in a sentence to the tune  of "issue of
> multiple encapsulations on the same <MT,SD,BML> combination is undefined in
> this RFC" which basically reads "here be dragons" which is inifintely
> better than having looping implementations because no'one knew what the
> score was. And in such case I would recommend to immediately follow up with
> a draft  about how multiple encapsulations are to be treated and discuss it
> out since we all know the issue will likely show up in the field.
>
> sounds fair?
>
> I'm sorry again I missed it writing the ISIS draft (or rather wrote a
> section that we realized only on last fine read seemed overly restrictive)
> ...
>
>
>
> -- tony
>
>
>
> On Tue, Feb 13, 2018 at 8:09 AM, Les Ginsberg (ginsberg) <
> [e-mail]> wrote:
>
> Tony –
>
>
>
> Can I interpret this as meaning you are OK with removing the text about
> multiple encapsulations from the IS-IS draft?
>
>
>
>    Les
>
>
>
>
>
> *From:* Tony Przygienda [mailto:[e-mail]]
> *Sent:* Tuesday, February 13, 2018 7:56 AM
> *To:* Eric C Rosen <[e-mail]>
> *Cc:* Peter Psenak (ppsenak) <[e-mail]>; Les Ginsberg (ginsberg)
> <[e-mail]>; Acee Lindem (acee) <[e-mail]>; [e-mail];
> IJsbrand Wijnands (iwijnand) <[e-mail]>; [e-mail] list <
> [e-mail]>
> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
>
>
> +1 Eric's take ... I don't see how we can interpret it/standardize it in
> many ways unless we want it to be overly restrictive but in any case I
> think a new draft is a good thing. And sigh, we didn't pay enough attention
> since the issue seemed "ephemeral" (and arguably, there were many things
> more worth aruging to be argued then ;-) but with ether it needs
> clarification.  The way it slipped me was that while writing the ISIS draft
> originally and using the <MT,SD,BML> I thought briefly based on my UML that
> it's really  <MT,SD,ENC,BML> but then I was thinking "gosh, this is getting
> deep and people will probably roll their eyes" ;-)   Another principle
> slipped, another lesson learned albeit I think this one is pretty harmless.
>
>
>
> Question more being: are we ready with the OSPF draft if we leave that
> completely open. If I'd be an implementer (or maybe I am ;-) I would have
> no issue implementing the ISIS draft in a clear way when computing, without
> any ENC explanation I would say @ this point in computaiton "hmm, am I
> supposed ignore the TLV because I see encaps I don't understand/support on
> this link" or do I install in fast-path just any encapsulation we both
> agree on?  (Or we could think about e.g. is MPLS preferred over anything
> else, i.e. have a predictable ordering which may play a role if someone
> wants to debug the network). Or otherwise, yes, we could sya, more than ONE
> encap on the link is illegal (but that's not what my UML based on
> architecture doc/discussion says ;-)
>
>
>
> yes, it's finely carved, yes, IGPs always are ...
>
>
>
> --- tony
>
>
>
> On Tue, Feb 13, 2018 at 5:11 AM, Eric C Rosen <[e-mail]> wrote:
>
> If some folks think that there needs to be a correction or addition to the
> architecture, the best thing to do would be to write a new draft and post
> it for discussion.
>
> This appears to be a substantive technical issue, which is not appropriate
> for an erratum.  It also doesn't seem appropriate for the IGP drafts.
>
>
>
> On 2/13/2018 4:03 AM, Peter Psenak wrote:
>
> 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
>
>
> ...
>
> [Message clipped]
>
>
>
>
>