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

From: Greg Shepherd <[email-masked]>
Date: Thu, 1 Feb 2018 02:23:18 -0800

Have these changes been reflected in the draft? We're in WGLC but this
discussion needs to come to a conclusion so we can progress.

Greg

On Tue, Jul 25, 2017 at 12:52 PM, Toerless Eckert <[email-masked]> wrote:

> Thanks, Less, that would be lovely!
>
> I didn't check the OSPF draft, if its similar state, explanatory text wold
> equally be appreciated.
>
> On Sun, Jul 23, 2017 at 11:28:08PM +0000, Les Ginsberg (ginsberg) wrote:
> > Toerless -
> >
> > I am thinking to add a statement in Section 4.1 - something like:
> >
> > "At present, IS-IS support for a given BIER domain/sub-domain is limited
> to a single area - or to the IS-IS L2 sub-domain."
> >
> > If you believe this would be helpful I will spin a new version (subject
> to review/agreement from my co-authors).
> >
> >    Les
> >
> >
> > > -----Original Message-----
> > > From: Toerless Eckert [mailto:[email-masked]]
> > > Sent: Saturday, July 22, 2017 6:34 AM
> > > To: Les Ginsberg (ginsberg)
> > > Cc: Tony Przygienda; Hannes Gredler ([email-masked]); Greg
> Shepherd;
> > > [email-masked]; [email-masked] list; Christian Hopps
> > > Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
> > >
> > > Thanks Les
> > >
> > > When searching various terms in the doc to figure out what happens i
> am not
> > > sure why i missed this one.
> > >
> > > But: IMHO, RFCs can not only be the minimum number of words to get a
> > > running implementation. It also needs to specify what this
> implementation
> > > intends to achieve. Otherwise its not possible to do a useful review:
> > > The reviewer can to verify whether the spec will achieve what it
> claims to
> > > achieve is there no definitionn of what it claims to achieve.
> > >
> > > If i understand ISIS correctly, my reverse engineering of the intent
> is:
> > >
> > > - BIER TLVs stay within single ISIS areas. BFIR and BFER must
> therefore be
> > >   in the same ISIS area: There is no inter-area BIER traffic possible
> > >   with this specification. This is also true for ISIS area 0.
> > >
> > > - The same BIER sub-domain identifiers can be re-used
> > >   across different ISIS areas without any current impact. If these
> BFR-IDs
> > >   are non-overlapping, then this would allow in the future to create a
> single
> > >   cross ISIS area BIER sub-domain by leaking TLVs for such a BIER
> sub-domain
> > >   across ISIS levels. Leakage is outside the scope of this
> specificication.
> > >
> > > I actually even would like to do the following:
> > >
> > > - If BIER sub-domains are made to span multiple ISIS areas and BFR-ids
> > > assignemtns
> > >   are made such that all BFR-ids with the same SI are in the same ISIS
> ara,
> > >   then it should be in the future reasonably easy to create inter-area
> BIER
> > >   not by leaking of the BIER TLV but by having BFIR MPLS unicastBIER
> packets
> > >   for different SIs to an appropriate L2L1 BFIR that is part of the
> destination
> > > area/SI.
> > >   (if you would use SI number that are the same as ISIS area numbers
> then
> > >    you could probably do this without any new signaling. Not quite
> sure if
> > >    you can today easily find L1L2 border router for another area via
> existing
> > >    TLVs).
> > >
> > >   Alas, this idea will probably be killed because of the BIER
> architecture
> > >   intent not to engineer SI assignments in geographical fashions to
> > >   minimize traffic duplication in the presence of multiple SIs.
> > >
> > > Cheers
> > >     Toerless
> > >
> > > On Sat, Jul 22, 2017 at 06:03:53AM +0000, Les Ginsberg (ginsberg)
> wrote:
> > > > Tony/Toerless ???
> > > >
> > > > There is an explicit statement as to scope:
> > > >
> > > > <snip>
> > > > Section 4.2
> > > > ???
> > > >    o  BIER sub-TLVs MUST NOT be included when a prefix reachability
> > > >       advertisement is leaked between levels.
> > > > <end snip>
> > > >
> > > > Tony seems to have forgotten that we had a discussion about how BIER
> > > might be supported across areas and the conclusion was we did not know
> > > how to do that yet.
> > > > (Sorry Tony)
> > > >
> > > > Note this is ???consistent??? with https://www.ietf.org/id/draft-
> ietf-bier-
> > > ospf-bier-extensions-07.txt Section 2.5<https://www.ietf.org/id/
> draft-ietf-
> > > bier-ospf-bier-extensions-07.txt%20Section%202.5> - which limits the
> > > flooding scope of BIER information to a single area unless it can be
> validated
> > > that the best path to the prefix with BIER info can be validated to be
> to a
> > > router which itself advertised the BIER info. This is not something
> IS-IS can do
> > > since a single IS-IS instance only supports one area and therefore
> does not
> > > have the Level-1 advertisements of the originating router when that
> router is
> > > in another area.
> > > >
> > > > A few more responses inline.
> > > >
> > > > From: BIER [mailto:[email-masked]] On Behalf Of Tony
> Przygienda
> > > > Sent: Friday, July 21, 2017 5:17 AM
> > > > To: Toerless Eckert
> > > > Cc: Hannes Gredler ([email-masked]); Greg Shepherd; [email-masked]
> ;
> > > > [email-masked] list; Christian Hopps
> > > > Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
> > > >
> > > > Terminology is a bit nits  IMO since the doc is reading clear enough
> for
> > > someone who read BIER & ISIS. I can reread it or Les can comment
> whether
> > > we should tighten glossary ...
> > > >
> > > > With the scope I agree, that got lost and the doc should be possibly
> rev'ed
> > > before closing LC. Yes, we flood AD wide was the agreement but
> something
> > > mentioning that this could change in the future is good so we are
> forced to
> > > give it some thought how that would transition ...
> > > >
> > > > Thinking further though, in ISIS we have a clean document really.
> The  BIER
> > > sub-TLVs go into well defined TLVs in terms of flooding scope. Normal
> L1-L2
> > > redistribution can be used to get the info to all needed places AFAIS.
> So
> > > maybe nothing needs to be written. I wait for Les to chime in.
> > > >
> > > > OSPF I would have to look @ scopes again & think whether we need to
> > > write something or maybe Peter can comment ...
> > > >
> > > > --- tony
> > > >
> > > >
> > > >
> > > > On Fri, Jul 21, 2017 at 8:27 AM, Toerless Eckert
> > > <[email-masked]<mailto:[email-masked]>> wrote:
> > > > Sorry, past the two weeks, but hopefully  benign textual comments:
> > > >
> > > > We tried to find an explicit statement about the scope of BIER TLVs
> - eg:
> > > > are they meant to stay within an area, have some redistribution
> across
> > > > areas/levels or not.
> > > >
> > > > Tony said WG agreement was to have these TLV be flooded across the
> > > > whole ISIS domain for now (this draft). So an explicit statement to
> that
> > > effect would
> > > > be great (All BIER sub-domains TLVs are flooded across all ISIS
> areas/levels,
> > > so they span the whole ISIS domain).
> > > >
> > > > Also, if future work may/should could improve on that maybe some
> > > > sentence about that (i guess one could just have ISIS intra-area
> BIER sub-
> > > domains ?).
> > > >
> > > > Also: Do a check about possible ambiguity of any generic terms like
> > > sub-domain, level, area, topology so that reader that don't know the
> > > terminology ofall protocols (ISIS, BIER) by heart can easily know which
> > > protocol is referred to.
> > > >
> > > > [Les:] There is no mention of ???level??? in the document.
> > > > The use of ???sub-domain??? is clearly always associated with
> ???BIER???.
> > > > ???topology??? is always used as an RFC 5120 topology ??? therefore
> > > clearly an IS-IS topology.
> > > > There is only one use of the term ???area??? (in Section 5.1). That
> text
> > > might deserve a bit of clarification given this might be either a
> Level 1 area or
> > > the Level2 sub-domain. I???ll take a pass at it.
> > > > (BTW ??? I am talking about IS-IS area/L2sub-domain Toerless. ???)
> > > >
> > > > I don???t see that any other clarification is needed ??? but
> Toerless ??? if
> > > you can point to any specific sentences/paragraphs which you find
> confusing
> > > - I???ll take a second look.
> > > >
> > > >    Les
> > > >
> > > >
> > > > I guess there are no BIER level, area or topologies, but still makes
> > > > reading easier if the doc would say "ISIS level", "ISIS area", or at
> > > > least have them in the Terminology section. And probably in
> > > > terminology say "domain -> in the context of this document the BIER
> > > domain which is also the same as the ISIS domain"
> > > > (which i hope is the correct statement, see above).
> > > >
> > > > Cheers
> > > >     Toerless
> > > >
> > > > _______________________________________________
> > > > BIER mailing list
> > > > [email-masked]<mailto:[email-masked]>
> > > > https://www.ietf.org/mailman/listinfo/bier
> > > >
> > > >
> > > >
> > > > --
> > > > We???ve heard that a million monkeys at a million keyboards could
> > > produce the complete works of Shakespeare; now, thanks to the Internet,
> > > we know that is not true.
> > > > ???Robert Wilensky
> > >
> > > --
> > > ---
> > > [email-masked]
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 1 Feb 2018 15:26:06 +0000

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

Was changed to

o  BIER sub-TLVs MUST be included when a prefix reachability
      advertisement is leaked between levels.

This aligns IS-IS and OSPF drafts in this regard.

    Les

From: Greg Shepherd [mailto:[email-masked]]
Sent: Thursday, February 01, 2018 2:23 AM
To: Toerless Eckert <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda <[email-masked]>; Hannes Gredler ([email-masked]) <[email-masked]>; [email-masked]; [email-masked] list <[email-masked]>; Christian Hopps <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

Have these changes been reflected in the draft? We're in WGLC but this discussion needs to come to a conclusion so we can progress.

Greg

On Tue, Jul 25, 2017 at 12:52 PM, Toerless Eckert <[email-masked]<mailto:[email-masked]>> 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:
> "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
>
>
> > From: Toerless Eckert [mailto:[email-masked]<mailto:[email-masked]>]
> > Cc: Tony Przygienda; Hannes Gredler ([email-masked]<mailto:[email-masked]>); Greg Shepherd;
> > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> list; Christian Hopps
> > When searching various terms in the doc to figure out what happens i am not
> > running implementation. It also needs to specify what this implementation
> > The reviewer can to verify whether the spec will achieve what it claims to
> > 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
> >   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.
> >
> >   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
> > On Sat, Jul 22, 2017 at 06:03:53AM +0000, Les Ginsberg (ginsberg) wrote:
> > > Tony/Toerless ???
> > >
> > > Note this is ???consistent??? with https://www.ietf.org/id/draft-ietf-bier-
> > ospf-bier-extensions-07.txt Section 2.5<https://www.ietf.org/id/draft-ietf-
> > 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.
> > >
> > > From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tony Przygienda
> > > Cc: Hannes Gredler ([email-masked]<mailto:[email-masked]>); Greg Shepherd; [email-masked]<mailto:[email-masked]>;
> > > [email-masked]<mailto:[email-masked]> list; Christian Hopps
> > > 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
> > > 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
> > > 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
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> > > 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.
> > >
> > > 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,
> > > sentence about that (i guess one could just have ISIS intra-area BIER sub-
> > domains ?).
> > >
> > > The use of ???sub-domain??? is clearly always associated with ???BIER???.
> > > 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
> > > 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
> > > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > [email-masked]<mailto:[email-masked]>

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 6 Feb 2018 15:45:02 -0800

Thanks Les.

Any other feedback? Looks like the concerns have been addressed. Speak now.

Cheers,
Greg

On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) <[email-masked]>
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:
>
>
>
> *From:* Greg Shepherd [mailto:[email-masked]]
> *Sent:* Thursday, February 01, 2018 2:23 AM
> *To:* Toerless Eckert <[email-masked]>
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda <
> [email-masked]>; Hannes Gredler ([email-masked]) <
> [email-masked]>; [email-masked]; [email-masked] list <[email-masked]>;
> Christian Hopps <[email-masked]>
>
> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>
>
>

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 9 Feb 2018 08:49:27 -0800

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 <[email-masked]> wrote:

> On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
>> Greg –
>>
>>
>>
>> This thread is outdated.
>>
>> [email-masked]>; [email-masked]; [email-masked] list <
>> [email-masked]>; Christian Hopps <[email-masked]>
>>
>> > "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."
>> >
>> > > > Cc: Hannes Gredler ([email-masked]); Greg Shepherd;
>> [email-masked];

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Fri, 9 Feb 2018 17:13:39 +0000

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Les.

Cheers,
Greg

On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Greg –

This thread is outdated.

Specifically:

Section 4.1:

Section 4.2

Was changed to

    Les

From: Greg Shepherd [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, February 01, 2018 2:23 AM
To: Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; Hannes Gredler ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>

Greg

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 9 Feb 2018 09:20:58 -0800

Greg, where did you see that? The last standing working status was to have
it as fixed field and just reserve 0 for IGP delivered SPF nexthops.
thanks. tony

On Fri, Feb 9, 2018 at 8:49 AM, Greg Shepherd <[email-masked]> wrote:

>>> 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:
>>>
>>>
>>>
>>> > If you believe this would be helpful I will spin a new version
>>> (subject to review/agreement from my co-authors).
>>> >
>>> >    Les
>>> >
>>> >

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 9 Feb 2018 09:40:02 -0800

Sorry.. Crossed wires with Peter's comment on OSPF and I wanted to ensure
both IGP drafts are in sync. Peter corrected his comment. Please ignore me
at this time. :)

Greg

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 9 Feb 2018 09:46:12 -0800

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.
tony

---

From: Alia Atlas <[email-masked]>
Date: Fri, 9 Feb 2018 13:58:52 -0500

On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda <[email-masked]>
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

> [email-masked]

---

From: Alia Atlas <[email-masked]>
Date: Fri, 9 Feb 2018 13:59:42 -0500

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) <[email-masked]

> 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 <[email-masked]> wrote:
>
> Les,

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 9 Feb 2018 11:04:54 -0800

Les has the diff, I'd expect him to publish any minute to the list ... The
encaps was a real defect, the rest is just tightening down the
language/spec where it was too loose/too strict.

OSPF still needs update with conversion TLV removed, same paragraph on
encaps could be useful. I hope Greg pinged Peter ...

thanks

tony

On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas <[email-masked]> wrote:

> 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.
>

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 9 Feb 2018 11:12:25 -0800

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

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 9 Feb 2018 11:17:53 -0800

Sure ;-)  let me ping Peter @ the bottom then ... I don't think any of the
stuff applies to OSPF (was ISIS nits) except we can consider an encaps
paragraph. We basically suggest both to replace in ISIS the encaps section
like this

before:

"
   All routers in the flooding scope of the BIER TLVs MUST advertise the
   same encapsulation for a given <MT,SD>.  A router discovering
   encapsulation advertised that is different from its own MUST report a
   misconfiguration of a specific <MT,SD>.  All received BIER
   advertisements associated with the conflicting <MT, SD> pair MUST be
   ignored.

"

now

"

   Multiple encapsulations MAY be advertised/supported for a given
   <MT,SD>.  Clearly, however, there MUST be at least one encapsulation
   type in common in order for a BIER encapsulated packet to be
   successfully forwarded between two BFRs.

"

I do think that OSPF would benefit from adding this section to clarify the
issue which is not theoretical now that we have Ethernet.

So Peter, any ETA on outstanding OSPF nits now that we're tying up the IETF
LC?

thanks

--- tony

On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd <[email-masked]> 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
>>> 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.
>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 9 Feb 2018 11:19:41 -0800

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

On Fri, Feb 9, 2018 at 11:17 AM, Tony Przygienda <[email-masked]>
wrote:

> So Peter, any ETA on outstanding OSPF nits now that we're tying up the
> IETF LC?
>
> thanks
>
> --- tony
>
>
>>>>>>> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda
>>>>>>> <[email-masked]>; Hannes Gredler ([email-masked]) <

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 9 Feb 2018 21:45:50 +0100

Alia,

> Please tell that to Tony, its not me who started that discussion.
> 
> Tony is BIER WG Chair.  Managing the draft authors and different perspectives is part of his role.

Nice twist/try!

> BUT changes to WG drafts are based upon transparent mailing list discussion - so all are included.
> You know all of this, of course :-) but sometimes the details get losts in copious email threads.

Who can disagree with that...

Enjoy the weekend,

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Sat, 10 Feb 2018 09:49:07 +0100

Tony,

> Ice, as you well know we ended up with a one value BAR field without a registry (you being a strong proponent of such solution if I recall correctly) which is the current draft state in IETF LC Greg initiated. 

Indeed, along with other steak holders -T.

> Yes, ideas were extended based on original private drafts which have not been initiated from my side BTW. Some draft of a draft followed from other parties (which I was part of) trying to reconcile the different asks into some kind of a workable state.  Obviously I have many such discussions juggling at any given point in time around technologies I push forward and I try to keep a lot of people invested while assuring that we don't end up with intractable balls of yarn. In this case I did not see in a timely manner any consensus that seemed mature enough to me to shake the IETF LC despite having repeatedly notifying the parties that time is not infinite here and workable consensus for many involved interests is not equivalent to having one's desires being part of imperative substratum of the technology. And in this case all was aggravated somewhat by the fact that we were talking introduction of unspecified fields reflecting  working versions of private drafts on top of an already barely specified field we have. 
> 
> In short: since you state you're fine with the draft as it is (I omit the nits/defect I found with Les

I was always fine with the version that Greg LC'd as you rightfully state above.

>  which I assume will cause no further discussions) neither do I see any need to shake the draft further.

Good to hear!

>  Ongoing developments of the technology will be taken into future drafts  especially since we are steering towards a generous standards charter to develop BIER. 

Thx,

Ice.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 12 Feb 2018 15:55:06 +0100

Hi Tony,

On 09/02/18 20:04 , Tony Przygienda wrote:
> OSPF still needs update with conversion TLV removed,

that has been removed already and is NOT anymore in the published 
version 10.

thanks,
Peter

> same paragraph on
> On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
>     <[email-masked] <mailto:[email-masked]>> 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.
>
>
>             On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg)
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 Greg –____
>
>                 __ __
>
>                 This thread is outdated.____
>
>                 In V6 of the draft we removed the restriction to limit
>                 IS-IS BIER support to area boundaries – so Toerless’s
>                 comment (and my proposed text) are no longer relevant.____
>
>                 __ __
>
>                 Specifically:____
>
>                 __ __
>
>                 Section 4.1:____
>
>                 __ __
>
>                 “At present, IS-IS support for a given BIER
>                 domain/sub-domain is ____
>
>                                     limited to a single area - or to the
>                 IS-IS L2 sub-domain.”____
>
>                 __ __
>
>                 The above text was removed.____
>
>                 __ __
>
>                 Section 4.2____
>
>                 __ __
>
>                 o  BIER sub-TLVs MUST NOT be included when a prefix
>                 reachability____
>
>                        advertisement is leaked between levels.____
>
>                 __ __
>
>                 Was changed to____
>
>                 __ __
>
>                 o  BIER sub-TLVs MUST be included when a prefix
>                 reachability____
>
>                        advertisement is leaked between levels.____
>
>                 __ __
>
>                 This aligns IS-IS and OSPF drafts in this regard.____
>
>                 __ __
>
>                      Les____
>
>                 __ __
>
>                 *From:*Greg Shepherd [mailto:[email-masked]
>                 <mailto:[email-masked]>]
>                 *To:* Toerless Eckert <[email-masked] <mailto:[email-masked]>>
>                 *Cc:* Les Ginsberg (ginsberg) <[email-masked]
>                 <mailto:[email-masked]>>; Tony Przygienda
>                 <[email-masked] <mailto:[email-masked]>>;
>                 Hannes Gredler ([email-masked]
>                 <mailto:[email-masked]>) <[email-masked]
>                 <mailto:[email-masked]>>; [email-masked]
>                 <mailto:[email-masked]>; [email-masked]
>                 <mailto:[email-masked]> list <[email-masked]
>                 <mailto:[email-masked]>>; Christian Hopps
>                 <[email-masked] <mailto:[email-masked]>>
>
>
>                 *Subject:* Re: [Bier] WGLC:
>                 draft-ietf-bier-isis-extensions-04____
>
>                 __ __
>
>                 Have these changes been reflected in the draft? We're in
>                 WGLC but this discussion needs to come to a conclusion
>                 so we can progress. ____
>
>                 __ __
>
>                 Greg____
>
>                 __ __
>
>                 On Tue, Jul 25, 2017 at 12:52 PM, Toerless Eckert
>                 <[email-masked] <mailto:[email-masked]>> wrote:____
>
>                     I didn't check the OSPF draft, if its similar state,
>                     explanatory text wold equally be appreciated.____
>
>
>                      > "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
>                      >
>                      >
>                      > > Cc: Tony Przygienda; Hannes Gredler
>                     ([email-masked] <mailto:[email-masked]>); Greg
>                     Shepherd;
>                      > > [email-masked] <mailto:[email-masked]>;
>                     [email-masked] <mailto:[email-masked]> list;
>                     Christian Hopps
>                     <https://www.ietf.org/id/draft-ietf-bier->
>                     <https://www.ietf.org/id/draft-ietf->
>                      > >
>                      > > > From: BIER [mailto:[email-masked]
>                     <mailto:[email-masked]>] On Behalf Of Tony
>                     Przygienda
>                      > > > Cc: Hannes Gredler ([email-masked]
>                     <mailto:[email-masked]>); Greg Shepherd;
>                     [email-masked] <mailto:[email-masked]>;
>                      > > > [email-masked] <mailto:[email-masked]>
>                     list; Christian Hopps
>                      > > <[email-masked]
>                     <mailto:[email-masked]><mailto:[email-masked]
>                     <mailto:[email-masked]>>> wrote:
>                      > > you can point to any specific
>                     sentences/paragraphs which you find confusing
>                     <mailto:[email-masked]><mailto:[email-masked]
>                     <mailto:[email-masked]>>
>                     <https://www.ietf.org/mailman/listinfo/bier>
>                      > > >
>                      > > >
>                      > > >
>                      > > > --
>                      > > [email-masked] <mailto:[email-masked]>____
>
>                 __ __
>
>
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/bier>
>
>
>
>
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 12 Feb 2018 15:58:52 +0100

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:
>
> "
> I do think that OSPF would benefit from adding this section to clarify
> the issue which is not theoretical now that we have Ethernet.
>
>
> On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd <[email-masked]
> <mailto:[email-masked]>> 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
>         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
>
>                 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.
>
>                 On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>                     Thanks Les.
>
>                     On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg
>                     (ginsberg) <[email-masked]
>                     <mailto:[email-masked]>> wrote:
>
>                         Greg –____
>
>                         __ __
>
>                         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:____
>
>                         __ __
>
>                                             limited to a single area -
>                         or to the IS-IS L2 sub-domain.”____
>
>                         __ __
>
>                         o  BIER sub-TLVs MUST NOT be included when a
>                         prefix reachability____
>
>                         <[email-masked]
>                         <mailto:[email-masked]>>; Hannes Gredler
>                         ([email-masked] <mailto:[email-masked]>)
>                         <[email-masked] <mailto:[email-masked]>>;
>                         [email-masked] <mailto:[email-masked]> list
>                         <[email-masked] <mailto:[email-masked]>>;
>                         Christian Hopps <[email-masked]
>                         <mailto:[email-masked]>>
>
>
>                         Have these changes been reflected in the draft?
>                         We're in WGLC but this discussion needs to come
>                         to a conclusion so we can progress. ____
>
>                         __ __
>
>                         Greg____
>
>                         __ __
>
>                         On Tue, Jul 25, 2017 at 12:52 PM, Toerless
>                         Eckert <[email-masked] <mailto:[email-masked]>>
>                         wrote:____
>
>                             I didn't check the OSPF draft, if its
>                             similar state, explanatory text wold equally
>                             be appreciated.____
>
>
>                              > "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
>                              >
>                              >
>                              > > From: Toerless Eckert
>                             [mailto:[email-masked] <mailto:[email-masked]>]
>                             ([email-masked]
>                              > >   across ISIS levels. Leakage is
>                             outside the scope of this specificication.
>                              > >
>                              > >   then it should be in the future
>                             reasonably easy to create inter-area BIER
>                              > >   for different SIs to an appropriate
>                             L2L1 BFIR that is part of the destination
>                              > > area/SI.
>                              > >    you can today easily find L1L2
>                             border router for another area via existing
>                              > >    TLVs).
>                              > >
>                             <mailto:[email-masked]>] On Behalf Of
>                             Tony Przygienda
>                              > > > [email-masked]
>                             <mailto:[email-masked]> list; Christian Hopps
>                              > > > We tried to find an explicit
>                             statement about the scope of BIER TLVs - eg:
>                              > > > be great (All BIER sub-domains TLVs
>                             are flooded across all ISIS areas/levels,
>                              > > > sentence about that (i guess one
>                             could just have ISIS intra-area BIER sub-
>                              > > domains ?).
>                              > > >
>                              > > > The use of ???sub-domain??? is
>                             clearly always associated with ???BIER???.
>                              > > might deserve a bit of clarification
>                             given this might be either a Level 1 area or
>                              > > > I don???t see that any other
>                             clarification is needed ??? but Toerless ??? if
>                              > > produce the complete works of
>                             Shakespeare; now, thanks to the Internet,

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 12 Feb 2018 15:58:49 +0000

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)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Tony,

    
    thanks,
    Peter

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 12 Feb 2018 09:12:28 -0800

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) <[email-masked]> wrote:

> On 2/12/18, 9:59 AM, "BIER on behalf of Peter Psenak (ppsenak)" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hi Tony,
>
>     >                         ([email-masked] <mailto:[email-masked]
> >)
>     >                         <[email-masked] <mailto:[email-masked]
> >>;
> list
>     >                         <[email-masked] <mailto:[email-masked]
> >>;
>     >                         Eckert <[email-masked] <mailto:[email-masked]
> >>
>     >                         wrote:____
>     >
>     >                              > > [email-masked] <mailto:[email-masked]
> >;
>     >                              > > When searching various terms in the
> doc
>     >                             to figure out what happens i am not
>     >                              > > 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.
>     >                              > >
>     >                              > >   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
>     >                              > > - 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,
>     >                              > >   not by leaking of the BIER TLV
> but by
>     >                             having BFIR MPLS unicastBIER packets
>     >                              > >   for different SIs to an
> appropriate
>     >                              > >   (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
>     >                              > >   intent not to engineer SI
> assignments
>     >                             in geographical fashions to
>     >                              > >   minimize traffic duplication in
> the
>     >                             presence of multiple SIs.
>     >                              > >
>     >                              > > Cheers
>     >                              > >     Toerless
>     >                              > >
>     >                              > > > There is an explicit statement as
> to
>     >                             scope:
>     >                              > > >
>     >                              > > > <snip>
>     >                              > > > Section 4.2
>     >                              > > > ???
>     >                              > > >       advertisement is leaked
> between
>     >                             levels.
>     >                              > > > 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)
>     >                              > > >
>     >                             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
>     >                              > > have the Level-1 advertisements of
> the
>     >                             originating router when that router is
>     >                              > > in another area.
>     >                              > > >
>     >                              > > > Terminology is a bit nits  IMO
> since
>     >                             the doc is reading clear enough for
>     >                              > > > With the scope I agree, that got
> lost
>     >                             and the doc should be possibly rev'ed
>     >                              > > > 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
>     >                              > > > Also, if future work may/should
> could
>     >                             improve on that maybe some
>     >                              > > > ???topology??? is always used as
> an
>     >                             RFC 5120 topology ??? therefore
>     >                              > > > 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
>     >                              > > > We???ve heard that a million
> monkeys
>     >                             at a million keyboards could
>     >                              > > [email-masked] <mailto:[email-masked]
> >____
>     >
>     >                         __ __
>     >
>     >
>     >
>     >

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 12 Feb 2018 18:33:21 +0000

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 <[email-masked]>
Date: Monday, February 12, 2018 at 12:13 PM
To: Acee Lindem <[email-masked]>
Cc: "Peter Psenak (ppsenak)" <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked] list" <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> 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)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi Tony,

    thanks,
    Peter

    On 09/02/18 20:17 , Tony Przygienda wrote:
    > On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd <[email-masked]<mailto:[email-masked]>
    > <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
    >
    >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
    >
    >         On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>
    >         <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
    >
    >             <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
    >
    >                 <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
    >
    >                     Thanks Les.
    >
    >                     (ginsberg) <[email-masked]<mailto:[email-masked]>
    >                     <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
    >
    >                         Greg –____
    >
    >                         __ __
    >
    >                         *From:*Greg Shepherd [mailto:[email-masked]<mailto:[email-masked]>
    >                         <mailto:[email-masked]<mailto:[email-masked]>>]
    >                         *To:* Toerless Eckert <[email-masked]<mailto:[email-masked]>
    >                         <mailto:[email-masked]<mailto:[email-masked]>>>
    >                         *Cc:* Les Ginsberg (ginsberg)
    >                         <[email-masked]<mailto:[email-masked]>
    >                         <mailto:[email-masked]<mailto:[email-masked]>>>; Tony Przygienda
    >                         <[email-masked]<mailto:[email-masked]>
    >                         <mailto:[email-masked]<mailto:[email-masked]>>>; Hannes Gredler
    >                         ([email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>)
    >                         <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
    >                         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>;
    >                         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> list
    >                         <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
    >                         Christian Hopps <[email-masked]<mailto:[email-masked]>
    >                         <mailto:[email-masked]<mailto:[email-masked]>>>
    >
    >
    >                         Eckert <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
    >                         wrote:____
    >
    >                             [mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>]
    >                             ([email-masked]<mailto:[email-masked]>
    >                             <mailto:[email-masked]<mailto:[email-masked]>>); Greg Shepherd;
    >                              > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>;
    >                             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    >                             list; Christian Hopps
    >                              > > > From: BIER
    >                             [mailto:[email-masked]<mailto:[email-masked]>
    >                             <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of
    >                             Tony Przygienda
    >                              > > > Cc: Hannes Gredler ([email-masked]<mailto:[email-masked]>
    >                             <mailto:[email-masked]<mailto:[email-masked]>>); Greg Shepherd;
    >                             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>;
    >                              > > > [email-masked]<mailto:[email-masked]>
    >                             <mailto:[email-masked]<mailto:[email-masked]>> list; Christian Hopps
    >                              > > <[email-masked]<mailto:[email-masked]>
    >                             <mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]>
    >                             <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
    >                             <mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]>
    >                             <mailto:[email-masked]<mailto:[email-masked]>>>
    >                              > > >
    >                              > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>____
    >
    >                         __ __
    >
    >
    >
    >
    >                 [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 12 Feb 2018 21:04:32 +0100

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) <[email-masked]> wrote:
> 
> Hi Tony, 
>     >                         <[email-masked]
>     >                             [mailto:[email-masked]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 12 Feb 2018 20:12:53 +0000

Ice –

Perhaps the thread is too long and you have gotten confused. ☺

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).

    >     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.

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) <[email-masked]>
Cc: Tony Przygienda <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; [email-masked] list <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

Folks,

Thx,

Ice.

On 12 Feb 2018, at 19:33, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tony,

From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 12, 2018 at 12:13 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked] list<mailto:[email-masked] list>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

--- tony

Thanks
Acee

On 2/12/18, 9:59 AM, "BIER on behalf of Peter Psenak (ppsenak)" <[email-masked] on behalf of [email-masked]<mailto:[email-masked] on%20behalf%20of [email-masked]>> wrote:

    Hi Tony,

    thanks,
    Peter

    <mailto:[email-masked]%0b %20 %20> > <mailto:[email-masked]>> wrote:
    >     <[email-masked] <mailto:[email-masked]<mailto:[email-masked] %3cmailto:[email-masked]>>> wrote:
    >
    <mailto:[email-masked]%0b %20 %20> >         <mailto:[email-masked]>> wrote:
    >             <[email-masked] <mailto:[email-masked]<mailto:[email-masked] %3cmailto:[email-masked]>>> wrote:
    >
    >                 <[email-masked] <mailto:[email-masked]<mailto:[email-masked] %3cmailto:[email-masked]>>> wrote:
    >
    >                     Thanks Les.
    >
    <mailto:[email-masked]%0b %20 %20> >                     <mailto:[email-masked]>> wrote:
    >                         <mailto:[email-masked]><mailto:[email-masked]%0b %20 %20%3e%20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20%3cmailto:[email-masked]%3e>]
    >                         *To:* Toerless Eckert <[email-masked]
    <mailto:[email-masked]%0b %20 %20> >                         <mailto:[email-masked]>>
    >                         *Cc:* Les Ginsberg (ginsberg)
    <mailto:[email-masked]%0b %20 %20> >                         <mailto:[email-masked]>>; Tony Przygienda
    >                         <[email-masked]
    <mailto:[email-masked]%0b %20 %20> >                         <mailto:[email-masked]>>; Hannes Gredler
    >                         ([email-masked]<mailto:[email-masked]> <mailto:[email-masked]>)
    >                         <[email-masked] <mailto:[email-masked]<mailto:[email-masked] %3cmailto:[email-masked]>>>;
    >                         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
    >                         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> list
    >                         <[email-masked] <mailto:[email-masked]<mailto:[email-masked] %3cmailto:[email-masked]>>>;
    <mailto:[email-masked]%0b %20 %20> >                         <mailto:[email-masked]>>
    >                         Eckert <[email-masked] <mailto:[email-masked]<mailto:[email-masked] %3cmailto:[email-masked]>>>
    >                         wrote:____
    >
    >                             [mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked] %3cmailto:[email-masked]%3e>]
    >                              > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
    >                             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
    >                             list; Christian Hopps
    <https://www.ietf.org/id/draft-ietf-%0b %20 %20> >                             <https://www.ietf.org/id/draft-ietf->
    >                             <mailto:[email-masked]><mailto:[email-masked]%0b %20 %20%3e%20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20 %20%3cmailto:[email-masked]%3e>] On Behalf Of
    >                             Tony Przygienda
    >                             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;
    <mailto:[email-masked]%0b %20 %20> >                             <mailto:[email-masked]><mailto:[email-masked]
    >                              > > > (which i hope is the correct
    <mailto:[email-masked]%0b %20 %20> >                             <mailto:[email-masked]>>
    >                              > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>____
    >
    >                         __ __
    >
    >
    >
    >
    >                 [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 12 Feb 2018 12:51:40 -0800

we are talking different encapsulations here and not different BSLs, Ice
(like Ether &  MPLS on the same link) ...  I don't think architecture says
anything about multiple encaps on same link (scanned it quickly again) but
it's necessary to prevent IGP blackholing/looping ... I'm agnostic, we can
publish a normative draft for both IGPs or we can add it into each IGP
(since it's really an IGP problem assuming architecture is concerned with
any signalling underlay) ...

-=-- tony

On Mon, Feb 12, 2018 at 12:04 PM, IJsbrand Wijnands <[email-masked]> wrote:

> 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.
>
> Cc: "Peter Psenak (ppsenak)" <[email-masked]>, "Les Ginsberg
> (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked] list" <[email-masked]>
>     >                         <mailto:[email-masked]>>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 12 Feb 2018 21:58:20 +0100

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.

> 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. 
****

Thx,

Ice.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 12 Feb 2018 21:16:32 +0000

Ice -

From: IJsbrand Wijnands (iwijnand)
Sent: Monday, February 12, 2018 12:58 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]; Peter Psenak (ppsenak) <[email-masked]>; [email-masked] list <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

Les,

Maybe :-), but...

****

[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.

   Les

From: IJsbrand Wijnands (iwijnand)
Sent: Monday, February 12, 2018 12:05 PM
To: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Cc: Tony Przygienda <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

Folks,

Thx,

Ice.

Hi Tony,

Cc: "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked] list<mailto:[email-masked]%20list>" <[email-masked]<mailto:[email-masked]>>

--- tony

Thanks
Acee

On 2/12/18, 9:59 AM, "BIER on behalf of Peter Psenak (ppsenak)" <[email-masked] on behalf of [email-masked]<mailto:[email-masked]%20on%20behalf%20of [email-masked]>> wrote:

    Hi Tony,

    thanks,
    Peter

    <mailto:[email-masked]%0b %20  > > <mailto:[email-masked]>> wrote:
    >     <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:
    >
    <mailto:[email-masked]%0b %20  > >         <mailto:[email-masked]>> wrote:
    >             <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:
    >
    >                 <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:
    >
    >                     Thanks Les.
    >
    >                         *To:* Toerless Eckert <[email-masked]
    <mailto:[email-masked]%0b %20  > >                         <mailto:[email-masked]>>
    >                         *Cc:* Les Ginsberg (ginsberg)
    <mailto:[email-masked]%0b %20  > >                         <mailto:[email-masked]>>; Tony Przygienda
    >                         <[email-masked]
    <mailto:[email-masked]%0b %20  > >                         <mailto:[email-masked]>>; Hannes Gredler
    >                         <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>;
    >                         <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>;
    <mailto:[email-masked]%0b %20  > >                         <mailto:[email-masked]>>
    >                         Eckert <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
    >                         wrote:____
    >
    >                             [mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]%20%3cmailto:[email-masked]%3e>]
    <https://www.ietf.org/id/draft-ietf-%0b %20  > >                             <https://www.ietf.org/id/draft-ietf->
    >                              > > > On Fri, Jul 21, 2017 at 8:27 AM,
    <mailto:[email-masked]%0b %20  > >                             <mailto:[email-masked]><mailto:[email-masked]
    >                              > > > (which i hope is the correct
    <mailto:[email-masked]%0b %20  > >                             <mailto:[email-masked]>>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 12 Feb 2018 22:49:59 +0100

Les,

>       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) <[email-masked]> wrote:
> 
> Ice -
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 12 Feb 2018 22:06:36 +0000

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

Sent: Monday, February 12, 2018 1:50 PM

Les,

Thx,

Ice.

On 12 Feb 2018, at 22:16, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Ice -

From: IJsbrand Wijnands (iwijnand)
Sent: Monday, February 12, 2018 12:58 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

Les,

Maybe :-), but...

****

   Les

Thx,

Ice.

   Les

Folks,

Thx,

Ice.

Hi Tony,

--- tony

Thanks
Acee

    Hi Tony,

    thanks,
    Peter

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 12 Feb 2018 23:16:15 -0800

+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) <[email-masked]

> 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) <[email-masked]>
> *Cc:* Acee Lindem (acee) <[email-masked]>; [email-masked]; Peter Psenak
> (ppsenak) <[email-masked]>; [email-masked] list <[email-masked]>
> 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.
>
>
>
>
>
> Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]; Peter Psenak
> (ppsenak) <[email-masked]>; [email-masked] list <[email-masked]>
> 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).
>
> 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.
>
> [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.
>
> Cc: Tony Przygienda <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; [email-masked]; [email-masked] list <
> [email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
> 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.
>
> (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]
> list" <[email-masked]>
> 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
> decision so just use any matching encaps to transfer, however
> the computation has to agree to prevent blackholes  ...
>
>      <[email-masked]%0b%C2%A0%20>> <mailto:[email-masked]
> <[email-masked]>>> wrote:
>     >
>      <[email-masked]%0b%C2%A0%20>>         <mailto:[email-masked]
> <[email-masked]>>> wrote:
>     >
>      <[email-masked]%0b%C2%A0%20>>                     <
> mailto:[email-masked] <[email-masked]>>> wrote:
>     >
>     >                         Greg –____
>     >
>     >                         __ __
>     >
>     >                         <mailto:[email-masked]>
> <[email-masked]%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:[email-masked]%3e>
> ]
>      <[email-masked]%0b%C2%A0%20>>                         <
> mailto:[email-masked] <[email-masked]>>>
>      <[email-masked]%0b%C2%A0%20>>                         <
> mailto:[email-masked] <[email-masked]>>>; Tony Przygienda
>     >                         <[email-masked]
>      <[email-masked]%0b%C2%A0%20>>                         <
> mailto:[email-masked] <[email-masked]>>>; Hannes Gredler
> <[email-masked]>>)
> <[email-masked]>>;
>     >                         [email-masked] <mailto:[email-masked]
> <[email-masked]>> list
>      <[email-masked]%0b%C2%A0%20>>                         <
> mailto:[email-masked] <[email-masked]>>>
>     >
>     >
>     >                             [mailto:[email-masked]
> <mailto:[email-masked]> <[email-masked]%20%3cmailto:[email-masked]%3e>]
>     >                             <mailto:[email-masked]
> <[email-masked]>>); Greg Shepherd;
> <[email-masked]>>;
>     >                             [email-masked] <mailto:
> [email-masked] <[email-masked]>>
>     >                             list; Christian Hopps
>      <https://www.ietf.org/id/draft-ietf-%0b%C2%A0%20>>
>     >                             <mailto:[email-masked]>
> <[email-masked]%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:[email-masked]%3e>]
> On Behalf Of
>     >                             Tony Przygienda
>     >                             <mailto:[email-masked]
> <[email-masked]>>); Greg Shepherd;
> <[email-masked]>>;
>     >                             <mailto:[email-masked]
> <[email-masked]>> list; Christian Hopps
>      <[email-masked]%0b%C2%A0%20>>                             <
> mailto:[email-masked] <[email-masked]>><mailto:[email-masked]
>      <[email-masked]%0b%C2%A0%20>>                             <
> mailto:[email-masked] <[email-masked]>>>> wrote:
>     >                             <mailto:[email-masked] <[email-masked]>><
> mailto:[email-masked]
>      <[email-masked]%0b%C2%A0%20>>                             <
> mailto:[email-masked] <[email-masked]>>>
>     >                              > > >
>     >                             https://www.ietf.org/
> mailman/listinfo/bier
> <[email-masked]>>____
>     >                 [email-masked] <mailto:[email-masked] <[email-masked]>>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 13 Feb 2018 10:03:20 +0100

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:
> On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
>     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)
>     *To:* Les Ginsberg (ginsberg) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>; Peter Psenak (ppsenak)
>     <[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>>
>     *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04____
>
>     __ __
>
>     Les,____
>
>     __ __
>
>                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)
>         Cc: Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>;
>         [email-masked] <mailto:[email-masked]>; Peter Psenak (ppsenak)
>         <[email-masked] <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>>
>         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).
>
>         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.
>
>         [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.
>
>         To: Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>
>         Cc: Tony Przygienda <[email-masked]
>         <mailto:[email-masked]>>; Les Ginsberg (ginsberg)
>         <[email-masked] <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>>; Peter Psenak (ppsenak)
>         <[email-masked] <mailto:[email-masked]>>
>         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.
>
>
>         I agree that since architecture has been published, it would not
>         hurt to add the 5.2 text to the IGP documents.
>         Thanks,
>         Acee
>
>         To: Acee Lindem <[email-masked] <mailto:[email-masked]>>
>         Cc: "Peter Psenak (ppsenak)" <[email-masked]
>         <mailto:[email-masked]>>, "Les Ginsberg (ginsberg)"
>         <[email-masked] <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
>         "[email-masked] list <mailto:[email-masked]%20list>"
>         <[email-masked] <mailto:[email-masked]>>
>         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)
>         <[email-masked] <mailto:[email-masked]>> wrote:
>         On 2/12/18, 9:59 AM, "BIER on behalf of Peter Psenak (ppsenak)"
>         <[email-masked] on behalf of [email-masked]
>         <mailto:[email-masked][email-masked]>>
>         wrote:
>
>              Hi Tony,
>
>         <mailto:[email-masked]%0b%C2%A0%20>>
>              >     <[email-masked] <mailto:[email-masked]
>         <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>         wrote:
>              >
>         <mailto:[email-masked]%0b%C2%A0%20>>
>         <mailto:[email-masked]
>         <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>         wrote:
>              >
>              >                 <[email-masked]
>         <mailto:[email-masked]
>         <mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:
>              >
>              >                     Thanks Les.
>              >
>              >                     Any other feedback? Looks like the
>         concerns have
>              >                     been addressed. Speak now.
>              >
>              >                     Cheers,
>              >                     Greg
>              >
>         <mailto:[email-masked]%0b%C2%A0%20>>
>         between levels.____
>         between levels.____
>              >                         This aligns IS-IS and OSPF drafts
>         in this
>              >                         regard.____
>              >
>              >                         __ __
>              >
>              >                              Les____
>              >
>              >                         __ __
>              >
>              >                         *From:*Greg Shepherd
>         [mailto:[email-masked]
>         <mailto:[email-masked]%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:[email-masked]%3e>]
>         <mailto:[email-masked]%0b%C2%A0%20>>
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]%0b%C2%A0%20>>
>         <mailto:[email-masked]%0b%C2%A0%20>>
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>)
>              >                         <[email-masked]
>         <mailto:[email-masked]%20%3cmailto:[email-masked]>>>;
>              > [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>;
>              > [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>> list
>              >                         <[email-masked]
>         <mailto:[email-masked]
>         <mailto:[email-masked]%20%3cmailto:[email-masked]>>>;
>         <mailto:[email-masked]%0b%C2%A0%20>>
>         <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>              >                         wrote:____
>              >
>              >                             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:
>              >                              >
>         <mailto:[email-masked]>
>         <mailto:[email-masked]%20%3cmailto:[email-masked]%3e>]
>              >                              > > Sent: Saturday, July 22,
>         2017 6:34 AM
>         <mailto:[email-masked]>
>              >                              > > [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>;
>              > [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>              >                             list; Christian Hopps
>              >                              > > Subject: Re: [Bier] WGLC:
>              >
>         draft-ietf-bier-isis-extensions-04
>              >                              > >
>              >                              > > Thanks Les
>              >                              > >
>              >                              > > When searching various
>         terms in the doc
>              >                              > > 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
>              >                              > > The reviewer can to
>         verify whether the
>              >                              > > achieve is there no
>         definitionn of what
>              >                              > > 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
>              >                              > >   are non-overlapping,
>         then this would
>              >                              > >   cross ISIS area BIER
>         sub-domain by
>              >                             leaking TLVs for such a BIER
>         sub-domain
>              >                              > >   across ISIS levels.
>         Leakage is
>              >                              > > I actually even would
>         like to do the
>              >                             following:
>              >                              > > - If BIER sub-domains
>         are made to span
>              >                              > >   are made such that all
>         BFR-ids with
>              >                              > >   not by leaking of the
>         BIER TLV but by
>              >                              > >   (if you would use SI
>         number that are
>              >                              > >    you could probably do
>         this without
>              >                              > >   Alas, this idea will
>         probably be
>              >                             killed because of the BIER
>         architecture
>              >                              > >   intent not to engineer
>         SI assignments
>              >                              > >   minimize traffic
>         duplication in the
>              >                              > > On Sat, Jul 22, 2017 at
>         06:03:53AM
>              >                             +0000, Les Ginsberg
>         (ginsberg) wrote:
>              >                              > > > There is an explicit
>         statement as to
>              >                              > > >    o  BIER sub-TLVs
>         MUST NOT be
>              >                             included when a prefix
>         reachability
>              >                              > > >       advertisement is
>         leaked between
>              >                              > > > Tony seems to have
>         forgotten that we
>              >                              > > might be supported
>         across areas and the
>              >                              > > > 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->>
>              >                              > >
>         ospf-bier-extensions-07.txt Section
>              >
>         2.5<https://www.ietf.org/id/draft-ietf-
>                        <https://www.ietf.org/id/draft-ietf-
>         <https://www.ietf.org/id/draft-ietf->>
>              >                              > >
>              >
>              >                              > > flooding scope of BIER
>         information to a
>              >                              > > that the best path to
>         the prefix with
>              >                              > > router which itself
>         advertised the BIER
>              >                              > > since a single IS-IS
>         instance only
>              >                             supports one area and
>         therefore does not
>              >                              > > have the Level-1
>         advertisements of the
>         <mailto:[email-masked]%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:[email-masked]%3e>]
>         On Behalf Of
>              >                             Tony Przygienda
>              >                              > > > Sent: Friday, July 21,
>         2017 5:17 AM
>              >                              > > > To: Toerless Eckert
>              >                              > > > Cc: Hannes Gredler
>         ([email-masked] <mailto:[email-masked]>
>              > [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>;
>              >                              > > > [email-masked]
>         <mailto:[email-masked]>
>              >                              > > > 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
>              >                              > > sub-TLVs go into well
>         defined TLVs in
>              >                              > > redistribution can be
>         used to get the
>              >                              > > maybe nothing needs to
>         be written. I
>              >                             wait for Les to chime in.
>              >                              > > >
>              >                              > > > OSPF I would have to
>         look @ scopes
>              >                             again & think whether we need to
>              >                              > > write something or maybe
>         Peter can
>              >                             comment ...
>              >                              > > >
>              >                              > > > --- tony
>              >                              > > >
>              >                              > > >
>              >                              > > >
>              >                              > > > On Fri, Jul 21, 2017
>         at 8:27 AM,
>              >                             Toerless Eckert
>              >                              > > <[email-masked]
>         <mailto:[email-masked]%0b%C2%A0%20>>
>         <mailto:[email-masked]%0b%C2%A0%20>>
>              >                              > > > Sorry, past the two
>         weeks, but
>              >                             hopefully  benign textual
>         comments:
>              >                              > > > are they meant to stay
>         within an
>              >                             area, have some
>         redistribution across
>              >                              > > > 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
>              >                              > > > Also, if future work
>         may/should could
>              >                              > > > 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
>              >                              > > > ???topology??? is
>         always used as an
>              >                              > > > There is only one use
>         of the term
>              >                             ???area??? (in Section 5.1).
>         That text
>              >                              > > might deserve a bit of
>         clarification
>              >                              > > 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
>              >                              > > > I guess there are no
>         BIER level, area
>              >                              > > > reading easier if the
>         doc would say
>              >                              > > > 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
>              >                              > > >
>              >                              > > >
>              >
>         <mailto:[email-masked]>
>         <mailto:[email-masked]%0b%C2%A0%20>>
>         <mailto:[email-masked]>>
>              >                              > > >
>         <https://www.ietf.org/mailman/listinfo/bier
>         <https://www.ietf.org/mailman/listinfo/bier>>
>              >                              > > >
>              >                              > > >
>              >                              > > >
>              >                              > > > --
>              >                              > > > We???ve heard that a
>         million monkeys
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>____
>              >
>              >                         __ __
>              >
>              >
>              >
>              >
>              >
>         <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>         <https://www.ietf.org/mailman/listinfo/bier
>         <https://www.ietf.org/mailman/listinfo/bier>>
>              >
>              >
>              >
>              >
>              >
>              >
>              >

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 13 Feb 2018 11:26:07 +0100

+1

But, I’m not yet sure if we’re taking about a errata or a new draft.. I see different ways to interpret the proposed text and Les’s explanation.

Thx,

Ice.

> On 13 Feb 2018, at 10:03, Peter Psenak <[email-masked]> 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
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Feb 2018 12:04:47 +0000

Only problem with this is that people don’t normally read all the errata. I’m a WG chair and I don’t even read them for an RFC until I find something I think is broken – then I look for one that is pertinent.

Thanks,
Acee

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Tuesday, February 13, 2018 at 5:26 AM
To: "Peter Psenak (ppsenak)" <[email-masked]>
Cc: Tony Przygienda <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>, "[email-masked] list" <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

+1

Thx,

Ice.

On 13 Feb 2018, at 10:03, Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:

Hi Folks,

thanks,
Peter

--- tony

On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

   Ice –____

   __ __

   __ __

   Make sense?____

   __ __

      Les____

   __ __

   __ __

   *To:* Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>>
   *Cc:* Acee Lindem (acee) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>;
   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Peter Psenak (ppsenak)
   <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>>
   *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.)____

   __ __

   __ __

   __ __

   __ __

   Thx,____

   __ __

   Ice.____

   __ __

   __ __

       On 12 Feb 2018, at 22:16, Les Ginsberg (ginsberg)
       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

       Ice -

       From: IJsbrand Wijnands (iwijnand)
       Sent: Monday, February 12, 2018 12:58 PM
       To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>>
       Cc: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>;
       [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>; Peter Psenak (ppsenak)
       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>>
       Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

       Les,

       Maybe :-), but...

       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

       Thx,

       Ice.

       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) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
       Cc: Tony Przygienda <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>>; Les Ginsberg (ginsberg)
       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>>; Peter Psenak (ppsenak)
       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
       Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

       Folks,

       Thx,

       Ice.

       On 12 Feb 2018, at 19:33, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>> wrote:

       Hi Tony,

       From: Tony Przygienda <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>>
       Date: Monday, February 12, 2018 at 12:13 PM
       To: Acee Lindem <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
       Cc: "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>>, "Les Ginsberg (ginsberg)"
       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>,
       "[email-masked]<mailto:[email-masked]> list <mailto:[email-masked]%20list>"
       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
       Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

       --- tony

       On Mon, Feb 12, 2018 at 7:58 AM, Acee Lindem (acee)
       <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> 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)"
       <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>
       <mailto:[email-masked][email-masked]<mailto:[email-masked]>>>
       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:
            > On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd
       <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]%0b%C2%A0%20>>
       <mailto:[email-masked]>> wrote:
            >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]
       <mailto:[email-masked]%20%3cmailto:[email-masked]<http://gmail.com>>>>
       wrote:
            >         On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas
       <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]%0b%C2%A0%20>>
       <mailto:[email-masked]
       <mailto:[email-masked]%20%3cmailto:[email-masked]<http://gmail.com>>>>
       wrote:
            >                 <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]
       concerns have
       between levels.____
       between levels.____
       in this
            >                         <mailto:[email-masked]>
       <mailto:[email-masked]%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:[email-masked]<http://gmail.com>%3e>]
            >                         <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]
       <mailto:[email-masked]%20%3cmailto:[email-masked]<http://gredler.at>>>>;
            > [email-masked]<mailto:[email-masked]>
            >                         <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]
       <mailto:[email-masked]%20%3cmailto:[email-masked]<mailto:[email-masked]>>>>;
            >                         Eckert <[email-masked]<mailto:[email-masked]>
       <mailto:[email-masked]
       <mailto:[email-masked]%20%3cmailto:[email-masked]<http://cs.fau.de>>>>
       11:28:08PM +0000,
       statement in
            >                              > > -----Original Message-----
       <mailto:[email-masked]>
       <mailto:[email-masked]%20%3cmailto:[email-masked]<http://cs.fau.de>%3e>]
            >                              > > [email-masked]<mailto:[email-masked]>
       terms in the doc
       only be the
       It also needs
       Otherwise its not
       verify whether the
       definitionn of what
       correctly, my
       single ISIS
       therefore be
       There is no
       sub-domain identifiers
       areas without
       then this would
       sub-domain by
       sub-domain
       like to do the
       are made to span
       BFR-ids with
       BIER TLV but by
       number that are
       this without
       probably be
       architecture
       SI assignments
       duplication in the
       06:03:53AM
       statement as to
       MUST NOT be
       reachability
       leaked between
       forgotten that we
       across areas and the
       ???consistent??? with
       bier-ospf-bier-extensions-07.txt%20Section%202.5>
       information to a
       the prefix with
       advertised the BIER
       instance only
       therefore does not
       advertisements of the
       <mailto:[email-masked]>
       <mailto:[email-masked]<mailto:[email-masked]>%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:[email-masked]<mailto:[email-masked]>%3e>]
       On Behalf Of
            >                              > > > Cc: Hannes Gredler
       ([email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
            > [email-masked]<mailto:[email-masked]>
       list; Christian Hopps
       nits  IMO since
       ISIS. I can
       whether
       agree, that got lost
       we flood AD
       something
       could change in
       forced to
       that would
       though, in ISIS we
       defined TLVs in
       used to get the
       be written. I
       look @ scopes
       Peter can
       at 8:27 AM,
       weeks, but
       within an
       redistribution across
       was to have
       now (this
       statement to that
       may/should could
       possible
       terms like
       topology so
       protocols (ISIS,
       know which
       mention of
       always used as an
       of the term
       That text
       I???ll take a
       about IS-IS
       BIER level, area
       doc would say
       Terminology
       "domain -> in the
       same as the
       correct
       <mailto:[email-masked]>
       million monkeys

       ____

   __ __

   ____

   __ __

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 13 Feb 2018 08:11:12 -0500

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:
>>              >     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.
>>              >
>>
>>              > Sure ;-)  let me ping Peter @ the bottom then ... I don't
>>         think any of
>>              > the stuff applies to OSPF (was ISIS nits) except we can
>>         consider an
>>              > encaps paragraph. We basically suggest both to replace in
>>         ISIS the
>>              > encaps section like this
>>              >
>>              > before:
>>              >
>>              > "
>>              >     All routers in the flooding scope of the BIER TLVs
>>         MUST advertise the
>>              >     same encapsulation for a given <MT,SD>.  A router
>>         discovering
>>              >     encapsulation advertised that is different from its
>>         own MUST report a
>>              >     misconfiguration of a specific <MT,SD>.  All received
>>         BIER
>>              >     advertisements associated with the conflicting <MT,
>>         SD> pair MUST be
>>              >     ignored.
>>              >
>>              > "
>>              >
>>              > now
>>              >
>>              > "
>>              >
>>              >     Multiple encapsulations MAY be advertised/supported
>>         for a given
>>              >     <MT,SD>.  Clearly, however, there MUST be at least
>>         one encapsulation
>>              >     type in common in order for a BIER encapsulated
>>         packet to be
>>              >     successfully forwarded between two BFRs.
>>              >
>>              > "
>>              >
>>              > I do think that OSPF would benefit from adding this
>>         section to clarify
>>              > the issue which is not theoretical now that we have 
>> Ethernet.
>>              >
>>              >
>>              > So Peter, any ETA on outstanding OSPF nits now that we're
>>         tying up the
>>              > IETF LC?
>>              >
>>              > thanks
>>              >
>>              > --- tony
>>              >
>>              >
>>              > On Fri, Feb 9, 2018 at 11:12 AM, Greg Shepherd
>>         <[email-masked]
>>              >
>>              >     No I didn't. Why would I? These are the changes you
>>         and Les worked
>>              >     out. I assumed you'd share them as needed. If for
>>         some reason you're
>>              >     uncomfortable engaging with the OSPF draft thread and
>>         authors with
>>              >     your proposed changes, let me know and I'll broker
>>         the conversation.
>>              >
>>              >     Greg
>>              >
>>              >     On Fri, Feb 9, 2018 at 11:04 AM, Tony Przygienda
>>              >     <[email-masked] <mailto:[email-masked]
>>              >
>>              >         Les has the diff, I'd expect him to publish any
>>         minute to the
>>              >         list ... The encaps was a real defect, the rest
>>         is just
>>              >         tightening down the language/spec where it was
>>         too loose/too
>>              >         strict.
>>              >
>>              >         OSPF still needs update with conversion TLV
>>         removed, same
>>              >         paragraph on encaps could be useful. I hope Greg
>>         pinged Peter ...
>>              >
>>              >         thanks
>>              >
>>              >         tony
>>              >
>>              >         On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas
>>         <[email-masked]
>>              >
>>              >             On Fri, Feb 9, 2018 at 12:46 PM, Tony 
>> Przygienda
>>              >             <[email-masked]
>>              >
>>              >                 Went last nits with Les, we found one
>>         issue (encaps
>>              >                 section was wrong, need to look @ OSPF as
>>         well) and
>>              >                 basically tightened language in few 
>> places.
>>              >
>>              >
>>              >             K - please get that  out with the details of
>>         changes to the
>>              >             list.  I did my AD review back in Oct and
>>         looked at the
>>              >             differences before issuing
>>              >             IETF Last Call.
>>              >
>>              >             I look forward to reviewing the minor 
>> changes.
>>              >
>>              >             Regards,
>>              >             Alia
>>              >
>>              >                 tony
>>              >
>>              >                 On Tue, Feb 6, 2018 at 3:45 PM, Greg 
>> Shepherd
>>              >                 <[email-masked]
>>         <mailto:[email-masked]
>>              >
>>              >                     Thanks Les.
>>              >
>>              >                     Any other feedback? Looks like the
>>         concerns have
>>              >                     been addressed. Speak now.
>>              >
>>              >                     Cheers,
>>              >                     Greg
>>              >
>>              >                     On Thu, Feb 1, 2018 at 7:26 AM, Les
>>         Ginsberg
>>              >                     (ginsberg) <[email-masked]
>>              >
>>              >                         Greg –____
>>              >
>>              >                         __ __
>>              >
>>              >                         This thread is outdated.____
>>              >
>>              >                         In V6 of the draft we removed the
>>         restriction to
>>              >                         limit IS-IS BIER support to area
>>         boundaries – so
>>              >                         Toerless’s comment (and my
>>         proposed text) are no
>>              >                         longer relevant.____
>>              >
>>              >                         __ __
>>              >
>>              >                         Specifically:____
>>              >
>>              >                         __ __
>>              >
>>              >                         Section 4.1:____
>>              >
>>              >                         __ __
>>              >
>>              >                         “At present, IS-IS support for a
>>         given BIER
>>              >                         domain/sub-domain is ____
>>              >
>>              > limited to a
>>         single area -
>>              >                         or to the IS-IS L2 
>> sub-domain.”____
>>              >
>>              >                         __ __
>>              >
>>              >                         The above text was removed.____
>>              >
>>              >                         __ __
>>              >
>>              >                         Section 4.2____
>>              >
>>              >                         __ __
>>              >
>>              >                         o  BIER sub-TLVs MUST NOT be
>>         included when a
>>              >                         prefix reachability____
>>              >
>>              >                                advertisement is leaked
>>         between levels.____
>>              >
>>              >                         __ __
>>              >
>>              >                         Was changed to____
>>              >
>>              >                         __ __
>>              >
>>              >                         o  BIER sub-TLVs MUST be included
>>         when a prefix
>>              >                         reachability____
>>              >
>>              >                                advertisement is leaked
>>         between levels.____
>>              >
>>              >                         __ __
>>              >
>>              >                         This aligns IS-IS and OSPF drafts
>>         in this
>>              >                         regard.____
>>              >
>>              >                         __ __
>>              >
>>              >                              Les____
>>              >
>>              >                         __ __
>>              >
>>              >                         *From:*Greg Shepherd
>>         [mailto:[email-masked]
>>              > <mailto:[email-masked]>
>>              >                         *Sent:* Thursday, February 01,
>>         2018 2:23 AM
>>              >                         *To:* Toerless Eckert 
>> <[email-masked]
>>              >                         *Cc:* Les Ginsberg (ginsberg)
>>              >                         <[email-masked]
>>              > <[email-masked]
>>              >                         ([email-masked]
>>              >                         <[email-masked]
>>              > [email-masked]
>>              > [email-masked]
>>              >                         <[email-masked]
>>              >                         Christian Hopps 
>> <[email-masked]
>>              >
>>              >
>>              >                         *Subject:* Re: [Bier] WGLC:
>>              >
>>              >
>>              >                         __ __
>>              >
>>              >                         Have these changes been reflected
>>         in the draft?
>>              >                         We're in WGLC but this discussion
>>         needs to come
>>              >                         to a conclusion so we can
>>         progress. ____
>>              >
>>              >                         __ __
>>              >
>>              >                         Greg____
>>              >
>>              >                         __ __
>>              >
>>              >                         On Tue, Jul 25, 2017 at 12:52 PM,
>>         Toerless
>>              >                         Eckert <[email-masked]
>>         <mailto:[email-masked]
>>              >                         wrote:____
>>              >
>>              >                             Thanks, Less, that would be
>>         lovely!
>>              >
>>              >                             I didn't check the OSPF
>>         draft, if its
>>              >                             similar state, explanatory
>>         text wold equally
>>              >                             be appreciated.____
>>              >
>>              >
>>              >                             On Sun, Jul 23, 2017 at
>>         11:28:08PM +0000,
>>              >                             Les Ginsberg (ginsberg) 
>> wrote:
>>              >                              > Toerless -
>>              >                              >
>>              >                              > I am thinking to add a
>>         statement in
>>              >                             Section 4.1 - something like:
>>              >                              >
>>              >                              > "At present, IS-IS support
>>         for a given
>>              >                             BIER domain/sub-domain is
>>         limited to a
>>              >                             single area - or to the IS-IS
>>         L2 sub-domain."
>>              >                              >
>>              >                              > If you believe this would
>>         be helpful I
>>              >                             will spin a new version
>>         (subject to
>>              >                             review/agreement from my
>>         co-authors).
>>              >                              >
>>              >                              >    Les
>>              >                              >
>>              >                              >
>>              >                              > > -----Original 
>> Message-----
>>              >                              > > From: Toerless Eckert
>>              > [mailto:[email-masked]
>>         <mailto:[email-masked]>
>>              >                              > > Sent: Saturday, July 22,
>>         2017 6:34 AM
>>              >                              > > To: Les Ginsberg 
>> (ginsberg)
>>              >                              > > Cc: Tony Przygienda;
>>         Hannes Gredler
>>              >                             ([email-masked]
>>              > <mailto:[email-masked]>);
>>         Greg Shepherd;
>>              >                              > > [email-masked]
>>              > [email-masked]
>>              >                             list; Christian Hopps
>>              >                              > > Subject: Re: [Bier] 
>> WGLC:
>>              >
>>              >                              > >
>>              >                              > > 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
>>              >                             true for ISIS area 0.
>>              >                              > >
>>              >                              > > - The same BIER
>>              >                             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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=>
>>              >
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dbier-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=FwRdfGyEveb9AfmKOlsQTa_M6f7RT2N02wLc96QcFmI&e=>>
>>              >                              > >
>>              >
>> 2.5<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=gzwy_n3ZN-lRwF4Ou6NVHEAarhQF22bRElJ6kiqHbqo&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D-250b-25C2-25A0-2520&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=WUyeExz9aM6aWI40OfobGvQ-Sr1x4kuhMECczm1lBJg&e=>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=gzwy_n3ZN-lRwF4Ou6NVHEAarhQF22bRElJ6kiqHbqo&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=gzwy_n3ZN-lRwF4Ou6NVHEAarhQF22bRElJ6kiqHbqo&e=>>
>>              >                              > >
>>              >
>>              >                             - which limits the
>>              >                              > > flooding scope of BIER
>>         information to a
>>              >                             single area unless it can be
>>         validated
>>              >                              > > that the best path to
>>         the prefix with
>>              >                             BIER info can be validated to
>>         be to a
>>              >                              > > router which itself
>>         advertised the BIER
>>              >                             info. This is not something
>>         IS-IS can do
>>              >                              > > since a single IS-IS
>>         instance only
>>              >                             supports one area and
>>         therefore does not
>>              >                              > > have the Level-1
>>         advertisements of the
>>              >                             originating router when that
>>         router is
>>              >                              > > in another area.
>>              >                              > > >
>>              >                              > > > A few more responses
>>         inline.
>>              >                              > > >
>>              >                              > > > From: BIER
>>              > [mailto:[email-masked]
>>              >
>>              >                             Tony Przygienda
>>              >                              > > > Sent: Friday, July 21,
>>         2017 5:17 AM
>>              >                              > > > To: Toerless Eckert
>>              >                              > > > Cc: Hannes Gredler
>>              > <mailto:[email-masked]>);
>>         Greg Shepherd;
>>              > [email-masked]
>>              >                              > > > [email-masked]
>>              > <mailto:[email-masked]>
>>         list; Christian Hopps
>>              >                              > > > Subject: Re: [Bier] 
>> WGLC:
>>              >
>>              >                              > > >
>>              >                              > > > Terminology is a bit
>>         nits  IMO since
>>              >                             the doc is reading clear
>>         enough for
>>              >                              > > someone who read BIER &
>>         ISIS. I can
>>              >                             reread it or Les can comment
>>         whether
>>              >                              > > we should tighten
>>         glossary ...
>>              >                              > > >
>>              >                              > > > With the scope I
>>         agree, that got lost
>>              >                             and the doc should be
>>         possibly rev'ed
>>              >                              > > before closing LC. Yes,
>>         we flood AD
>>              >                             wide was the agreement but
>>         something
>>              >                              > > mentioning that this
>>         could change in
>>              >                             the future is good so we are
>>         forced to
>>              >                              > > give it some thought how
>>         that would
>>              >                             transition ...
>>              >                              > > >
>>              >                              > > > Thinking further
>>         though, in ISIS we
>>              >                             have a clean document really.
>>         The  BIER
>>              >                              > > sub-TLVs go into well
>>         defined TLVs in
>>              >                             terms of flooding scope.
>>         Normal L1-L2
>>              >                              > > redistribution can be
>>         used to get the
>>              >                             info to all needed places
>>         AFAIS. So
>>              >                              > > maybe nothing needs to
>>         be written. I
>>              >                             wait for Les to chime in.
>>              >                              > > >
>>              >                              > > > OSPF I would have to
>>         look @ scopes
>>              >                             again & think whether we 
>> need to
>>              >                              > > write something or maybe
>>         Peter can
>>              >                             comment ...
>>              >                              > > >
>>              >                              > > > --- tony
>>              >                              > > >
>>              >                              > > >
>>              >                              > > >
>>              >                              > > > On Fri, Jul 21, 2017
>>         at 8:27 AM,
>>              >                             Toerless Eckert
>>              >                              > > <[email-masked]
>>              >                              > > > Sorry, past the two
>>         weeks, but
>>              >                             hopefully  benign textual
>>         comments:
>>              >                              > > >
>>              >                              > > > We tried to find an
>>         explicit
>>              >                             statement about the scope of
>>         BIER TLVs - eg:
>>              >                              > > > are they meant to stay
>>         within an
>>              >                             area, have some
>>         redistribution across
>>              >                              > > > areas/levels or not.
>>              >                              > > >
>>              >                              > > > Tony said WG agreement
>>         was to have
>>              >                             these TLV be flooded 
>> across the
>>              >                              > > > whole ISIS domain for
>>         now (this
>>              >                             draft). So an explicit
>>         statement to that
>>              >                              > > effect would
>>              >                              > > > be great (All BIER
>>         sub-domains TLVs
>>              >                             are flooded across all ISIS
>>         areas/levels,
>>              >                              > > so they span the whole
>>         ISIS domain).
>>              >                              > > >
>>              >                              > > > Also, if future work
>>         may/should could
>>              >                             improve on that maybe some
>>              >                              > > > sentence about that (i
>>         guess one
>>              >                             could just have ISIS
>>         intra-area BIER sub-
>>              >                              > > domains ?).
>>              >                              > > >
>>              >                              > > > Also: Do a check about
>>         possible
>>              >                             ambiguity of any generic
>>         terms like
>>              >                              > > sub-domain, level, area,
>>         topology so
>>              >                             that reader that don't 
>> know the
>>              >                              > > terminology ofall
>>         protocols (ISIS,
>>              >                             BIER) by heart can easily
>>         know which
>>              >                              > > protocol is referred to.
>>              >                              > > >
>>              >                              > > > [Les:] There is no
>>         mention of
>>              >                             ???level??? in the document.
>>              >                              > > > The use of
>>         ???sub-domain??? is
>>              >                             clearly always associated
>>         with ???BIER???.
>>              >                              > > > ???topology??? is
>>         always used as an
>>              >                             RFC 5120 topology ??? 
>> therefore
>>              >                              > > clearly an IS-IS 
>> topology.
>>              >                              > > > There is only one use
>>         of the term
>>              >                             ???area??? (in Section 5.1).
>>         That text
>>              >                              > > might deserve a bit of
>>         clarification
>>              >                             given this might be either a
>>         Level 1 area or
>>              >                              > > the Level2 sub-domain.
>>         I???ll take a
>>              >                             pass at it.
>>              >                              > > > (BTW ??? I am talking
>>         about IS-IS
>>              >                             area/L2sub-domain 
>> Toerless. ???)
>>              >                              > > >
>>              >                              > > > I don???t see that any
>>         other
>>              >                             clarification is needed ???
>>         but Toerless ??? if
>>              >                              > > you can point to any
>>         specific
>>              > sentences/paragraphs which
>>         you find confusing
>>              >                              > > - I???ll take a 
>> second look.
>>              >                              > > >
>>              >                              > > > Les
>>              >                              > > >
>>              >                              > > >
>>              >                              > > > I guess there are no
>>         BIER level, area
>>              >                             or topologies, but still 
>> makes
>>              >                              > > > reading easier if the
>>         doc would say
>>              >                             "ISIS level", "ISIS area", 
>> or at
>>              >                              > > > least have them in the
>>         Terminology
>>              >                             section. And probably in
>>              >                              > > > terminology say
>>         "domain -> in the
>>              >                             context of this document 
>> the BIER
>>              >                              > > domain which is also the
>>         same as the
>>              >                             ISIS domain"
>>              >                              > > > (which i hope is the
>>         correct
>>              >                             statement, see above).
>>              >                              > > >
>>              >                              > > > Cheers
>>              >                              > > >     Toerless
>>              >                              > > >
>>              >                              > > >
>>              >
>>              >                              > > > BIER mailing list
>>              >                              > > > [email-masked]
>>         <mailto:[email-masked]>
>>              >
>>              >                              > > >
>>              > 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>              >
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>>
>>              >                              > > >
>>              >                              > > >
>>              >                              > > >
>>              >                              > > > --
>>              >                              > > > We???ve heard that a
>>         million monkeys
>>              >                             at a million keyboards could
>>              >                              > > produce the complete
>>         works of
>>              >                             Shakespeare; now, thanks to
>>         the Internet,
>>              >                              > > we know that is not 
>> true.
>>              >                              > > > ???Robert Wilensky
>>              >                              > >
>>              >                              > > --
>>              >                              > > ---
>>              >                              > > [email-masked]
>>              >
>>              >                         __ __
>>              >
>>              >
>>              >
>>              >
>>              >
>>              >                 BIER mailing list
>>              > [email-masked]
>>              > 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>              >
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>>
>>              >
>>              >
>>              >
>>              >
>>              >
>>              >
>>              >
>>              > _______________________________________________
>>              > BIER mailing list
>>              > [email-masked] <mailto:[email-masked]>
>>              > 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>              >
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>
>>         
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>
>>         ____
>>
>>     __ __
>>
>>     ____
>>
>>     __ __
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e=>
>>
>>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=3qtn22GD6IXe8Gc7BKOgPUWWiCGQr6JDqiGS_qFd26I&s=eQlYmpmC84owMH74euBgR2MKoybqhitrlsIYSxeK-kM&e= 
>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 13 Feb 2018 07:55:49 -0800

+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 <[email-masked]> 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.
>
>
>> 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
>>
>>> <mailto:[email-masked][email-masked]
>>> >>
>>>         wrote:
>>>
>>>              Hi Tony,
>>>
>>> <mailto:[email-masked]%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:[email-masked]%3e>]
>> ...
> [Message clipped]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 13 Feb 2018 16:09:30 +0000

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:[email-masked]]
Sent: Tuesday, February 13, 2018 7:56 AM
To: Eric C Rosen <[email-masked]>
Cc: Peter Psenak (ppsenak) <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]; IJsbrand Wijnands (iwijnand) <[email-masked]>; [email-masked] list <[email-masked]>
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 ;-)

--- tony

On Tue, Feb 13, 2018 at 5:11 AM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> 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.

thanks,
Peter

--- tony

On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Ice –____

    __ __

    __ __

    Make sense?____

    __ __

       Les____

    __ __

    __ __

    *To:* Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>>
    *Cc:* Acee Lindem (acee) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak)
    <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>> list <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>>
    *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04____

    __ __

    Les,____

    __ __

    __ __

    __ __

    __ __

    __ __

    Thx,____

    __ __

    Ice.____

    __ __

    __ __

        On 12 Feb 2018, at 22:16, Les Ginsberg (ginsberg)
        <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

        Ice -

        From: IJsbrand Wijnands (iwijnand)
        Sent: Monday, February 12, 2018 12:58 PM
        To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
        Cc: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
        [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak)
        <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>> list <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
        Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

        Les,

        Maybe :-), but...

        ****

            Les

        Thx,

        Ice.

            Les

        From: IJsbrand Wijnands (iwijnand)
        Sent: Monday, February 12, 2018 12:05 PM
        To: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
        Cc: Tony Przygienda <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>; Les Ginsberg (ginsberg)
        <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>> list <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>; Peter Psenak (ppsenak)
        <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
        Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

        Folks,

        Thx,

        Ice.

        On 12 Feb 2018, at 19:33, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

        Hi Tony,

        From: Tony Przygienda <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
        Date: Monday, February 12, 2018 at 12:13 PM
        To: Acee Lindem <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
        Cc: "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>, "Les Ginsberg (ginsberg)"
        <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>,
        "[email-masked]<mailto:[email-masked]> list <mailto:[email-masked]<mailto:[email-masked]>%20list>"
        <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
        Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

        --- tony

        On Mon, Feb 12, 2018 at 7:58 AM, Acee Lindem (acee)
        <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> 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)"
        <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>>
        wrote:

             Hi Tony,

             thanks,
             Peter

        <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>%0b%C2%A0%20>>
        <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
             >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>%20%3cmailto:[email-masked]<mailto:[email-masked]>>>>
        <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>%0b%C2%A0%20>>
             >             <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>%20%3cmailto:[email-masked]<mailto:[email-masked]>>>>
             >                 <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>
        concerns have
             >                     (ginsberg) <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>%0b%C2%A0%20>>
        single area -
        between levels.____
        between levels.____
        in this
             >                         *From:*Greg Shepherd
        [mailto:[email-masked]<mailto:[email-masked]>
             > <mailto:[email-masked]<mailto:[email-masked]>>
<mailto:[email-masked]<mailto:[email-masked]>%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:[email-masked]<mailto:0b%25C2%25A0%2520%25C2%25A0%2520%253e%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%25C2%25A0%2520%[email-masked]>%3e>]
             >                         *To:* Toerless Eckert <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>%0b%C2%A0%20>>
        <mailto:[email-masked]<mailto:[email-masked]>>>
             >                         <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>%0b%C2%A0%20>>
        <mailto:[email-masked]<mailto:[email-masked]>>>; Tony Przygienda
             > <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>%0b%C2%A0%20>>
           <mailto:[email-masked]<mailto:[email-masked]>>>; Hannes Gredler
             >                         ([email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>)
             >                         <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>%20%3cmailto:[email-masked]<mailto:[email-masked]>>>>;
             > [email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>;
             > [email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>> list
             >                         <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>%20%3cmailto:[email-masked]<mailto:[email-masked]>>>>;
             >                         Christian Hopps <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>%0b%C2%A0%20>>
        <mailto:[email-masked]<mailto:[email-masked]>>>
             >                         Eckert <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>%20%3cmailto:[email-masked]<mailto:[email-masked]>>>>
        11:28:08PM +0000,
        statement in
             > [mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>
<mailto:[email-masked]<mailto:[email-masked]>%20%3cmailto:[email-masked]<mailto:[email-masked]>%3e>]
             >                             ([email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>
             >                              > > [email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>;
             > [email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
        terms in the doc
        only be the
        It also needs
        Otherwise its not
        verify whether the
        definitionn of what
        correctly, my
        single ISIS
        therefore be
        There is no
        sub-domain identifiers
        areas without
        then this would
        sub-domain by
        sub-domain
        like to do the
        are made to span
        BFR-ids with
        BIER TLV but by
        number that are
        this without
        probably be
        architecture
        SI assignments
        duplication in the
        06:03:53AM
        statement as to
        MUST NOT be
        reachability

...

[Message clipped]

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 13 Feb 2018 08:17:19 -0800

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) <[email-masked]

> 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:[email-masked]]
> *Sent:* Tuesday, February 13, 2018 7:56 AM
> *To:* Eric C Rosen <[email-masked]>
> *Cc:* Peter Psenak (ppsenak) <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked];
> IJsbrand Wijnands (iwijnand) <[email-masked]>; [email-masked] list <
> [email-masked]>
> <mailto:[email-masked]%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:[email-masked]%3e>]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 13 Feb 2018 17:06:47 +0000

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:[email-masked]]
Sent: Tuesday, February 13, 2018 8:17 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Eric C Rosen <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]; IJsbrand Wijnands (iwijnand) <[email-masked]>; [email-masked] list <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Tony –

   Les

From: Tony Przygienda [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, February 13, 2018 7:56 AM
To: Eric C Rosen <[email-masked]<mailto:[email-masked]>>
Cc: Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; IJsbrand Wijnands (iwijnand) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

--- tony

thanks,
Peter

--- tony

    Ice –____

    __ __

    __ __

    Make sense?____

    __ __

       Les____

    __ __

    __ __

    __ __

    Les,____

    __ __

    __ __

    __ __

    __ __

    __ __

    Thx,____

    __ __

    Ice.____

    __ __

    __ __

        Ice -

        Les,

        Maybe :-), but...

        ****

            Les

        Thx,

        Ice.

            Les

        Folks,

        Thx,

        Ice.

        Hi Tony,

        --- tony

        Thanks
        Acee

             Hi Tony,

             thanks,
             Peter

        concerns have
        single area -
        between levels.____
        between levels.____
        in this
        11:28:08PM +0000,
        statement in
        terms in the doc
        only be the
        It also needs
        Otherwise its not
        verify whether the
        definitionn of what
        correctly, my
        single ISIS
        therefore be
        There is no
        sub-domain identifiers
        areas without
        then this would
        sub-domain by
        sub-domain
        like to do the
        are made to span
        BFR-ids with
        BIER TLV but by
        number that are
        this without
        probably be
        architecture
        SI assignments
        duplication in the
        06:03:53AM
        statement as to
        MUST NOT be
        reachability

...

[Message clipped]

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 13 Feb 2018 09:37:07 -0800

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) <[email-masked]

> 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
>
>
>
>
>
> *Sent:* Tuesday, February 13, 2018 8:17 AM
> *Cc:* Eric C Rosen <[email-masked]>; Peter Psenak (ppsenak) <
> [email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked];
> On Tue, Feb 13, 2018 at 8:09 AM, Les Ginsberg (ginsberg) <

---

From: Xiejingrong <[email-masked]>
Date: Wed, 14 Feb 2018 06:46:34 +0000

Hi, forks
Really a long trip and thread since WG LC to IETF LC! Many great improvements have been made.
The draft have been completely changed from version-04, and it looks good to me.
I simply share my summary here:
(1) Allow BIER info flood spanning multi areas/levels from version-05, thanks to Toerless catched the problem.
(2) Allow the BAR field be back in ISIS message to support further other algorithms from version-06.
(3) Allow 256 SIs Change Label Range Size to Max SI to  from version-07, thanks to Senthil catched the problem.
(4) Allow one <SD,BSL,SI> to have multi Encapsulations from version-07, thanks to you guys make it clear that there will be multi encapsulations on a link.
(5) And a consensus to clarify this in BIER Architecture documents have been made.
(6) And some clarification examples which allow a MT to support multi SDs have been added from version-07.

Regards,
XieJingrong

From: BIER [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Wednesday, February 14, 2018 1:37 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked] list <[email-masked]>; IJsbrand Wijnands (iwijnand) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Eric C Rosen <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

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) <[email-masked]<mailto:[email-masked]>> wrote:
Tony –

    Les

Cc: Eric C Rosen <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; IJsbrand Wijnands (iwijnand) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>

-- tony

   Les

--- tony

thanks,
Peter

--- tony

    Ice –____

    __ __

    __ __

    Make sense?____

    __ __

       Les____

    __ __

    __ __

    __ __

    Les,____

    __ __

    __ __

    __ __

    __ __

    __ __

    Thx,____

    __ __

    Ice.____

    __ __

    __ __

        Ice -

        Les,

        Maybe :-), but...

        ****

            Les

        Thx,

        Ice.

            Les

        Folks,

        Thx,

        Ice.

        Hi Tony,

        --- tony

        Thanks
        Acee

             Hi Tony,

             thanks,
             Peter

        concerns have
        single area -
        between levels.____
        between levels.____
        in this
        11:28:08PM +0000,
        statement in
        terms in the doc
        only be the
        It also needs
        Otherwise its not
        verify whether the
        definitionn of what
        correctly, my
        single ISIS
        therefore be
        There is no
        sub-domain identifiers
        areas without
        then this would
        sub-domain by
        sub-domain
        like to do the
        are made to span
        BFR-ids with
        BIER TLV but by
        number that are
        this without
        probably be
        architecture
        SI assignments
        duplication in the
        06:03:53AM
        statement as to
        MUST NOT be
        reachability

...

[Message clipped]