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

[Tony Przygienda]

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  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)  wrote:

> Tony –
>
>
>
> Can I interpret this as meaning you are OK with removing the text about
> multiple encapsulations from the IS-IS draft?
>
>
>
>Les
>
>
>
>
>
> *From:* Tony Przygienda [mailto:tonysi...@gmail.com]
> *Sent:* Tuesday, February 13, 2018 7:56 AM
> *To:* Eric C Rosen 
> *Cc:* Peter Psenak (ppsenak) ; Les Ginsberg (ginsberg)
> ; Acee Lindem (acee) ; b...@ietf.org;
> IJsbrand Wijnands (iwijnand) ; isis-wg@ietf.org list <
> isis-wg@ietf.org>
> *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  I thought briefly based on my UML that
> it's really   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  wrote:
>
> If some folks think that there needs to be a correction or addition to the
> architecture, the best thing to do would be to write a new draft and post
> it for discussion.
>
> This appears to be a substantive technical issue, which is not appropriate
> for an erratum.  It also doesn't seem appropriate for the IGP drafts.
>
>
>
> On 2/13/2018 4:03 AM, Peter Psenak wrote:
>
> Hi Folks,
>
> can we add an errata to RFC 8279, instead of adding the text to both IGP
> drafts that does not really belong there.
>
>
> thanks,
> Peter
>
> On 13/02/18 08:16 , Tony Przygienda wrote:
>
> +1 what Les says as my understanding of the problem we're tackling here ...
>
> --- tony
>
> On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
> > wrote:
>
> Ice –
>
> __ __
>
> MY understanding is that – in the future – there may be additional
> encaps defined for BIER. When that happens, a given BFR may support
> multiple encaps. In such a case, it is OK if other BFRs supporting
> the same  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  - which is
> unnecessarily restrictive.
>
> __ __
>
> Make sense?
>
> __ __
>
>  

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

[Tony Przygienda]

+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  I thought briefly based on my UML that
it's really   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  wrote:

> If some folks think that there needs to be a correction or addition to the
> architecture, the best thing to do would be to write a new draft and post
> it for discussion.
>
> This appears to be a substantive technical issue, which is not appropriate
> for an erratum.  It also doesn't seem appropriate for the IGP drafts.
>
>
> On 2/13/2018 4:03 AM, Peter Psenak wrote:
>
>> Hi Folks,
>>
>> can we add an errata to RFC 8279, instead of adding the text to both IGP
>> drafts that does not really belong there.
>>
>>
>> thanks,
>> Peter
>>
>> On 13/02/18 08:16 , Tony Przygienda wrote:
>>
>>> +1 what Les says as my understanding of the problem we're tackling here
>>> ...
>>>
>>> --- tony
>>>
>>> On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
>>> > wrote:
>>>
>>> Ice –
>>>
>>> __ __
>>>
>>> MY understanding is that – in the future – there may be additional
>>> encaps defined for BIER. When that happens, a given BFR may support
>>> multiple encaps. In such a case, it is OK if other BFRs supporting
>>> the same  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  - which is
>>> unnecessarily restrictive.
>>>
>>> __ __
>>>
>>> Make sense?
>>>
>>> __ __
>>>
>>>Les
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> *From:*IJsbrand Wijnands (iwijnand)
>>> *Sent:* Monday, February 12, 2018 1:50 PM
>>>
>>>
>>> *To:* Les Ginsberg (ginsberg) >> >
>>> *Cc:* Acee Lindem (acee) >;
>>> b...@ietf.org ; Peter Psenak (ppsenak)
>>> >; isis-wg@ietf.org
>>>  list >> >
>>> *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
>>>
>>> __ __
>>>
>>> Les,
>>>
>>> __ __
>>>
>>> (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
>>>being used, this means that every BFR that is advertising
>>> a label
>>>for sub-domain S is advertising a label for the
>>> combination of
>>>sub-domain S and Disposition BitStringLength L.)
>>>
>>> __ __
>>>
>>> It says, if MPLS encapsulation is used, there is a Label for the
>>> {SD, BSL}. So, if there is non-MPLS (ether) only, there will not be
>>> a Label and the compatibility check will fail. Is that not the same
>>> a router that does not support MPLS BIER, and treated as a non-BIER
>>> router?
>>>
>>> __ __
>>>
>>> [Les:] I don’t see how this text can be used to mean “multiple
>>> encap types can be supported on the same BFR for a given
>>> ”.
>>> ???
>>>
>>> __ __
>>>
>>> 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 

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

[Eric C Rosen]

If some folks think that there needs to be a correction or addition to 
the architecture, the best thing to do would be to write a new draft and 
post it for discussion.


This appears to be a substantive technical issue, which is not 
appropriate for an erratum.  It also doesn't seem appropriate for the 
IGP drafts.


On 2/13/2018 4:03 AM, Peter Psenak wrote:

Hi Folks,

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



thanks,
Peter

On 13/02/18 08:16 , Tony Przygienda wrote:
+1 what Les says as my understanding of the problem we're tackling 
here ...


--- tony

On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
> wrote:

    Ice –

    __ __

    MY understanding is that – in the future – there may be additional
    encaps defined for BIER. When that happens, a given BFR may support
    multiple encaps. In such a case, it is OK if other BFRs supporting
    the same  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  - which is
    unnecessarily restrictive.

    __ __

    Make sense?

    __ __

   Les

    __ __

    __ __

    *From:*IJsbrand Wijnands (iwijnand)
    *Sent:* Monday, February 12, 2018 1:50 PM


    *To:* Les Ginsberg (ginsberg) >
    *Cc:* Acee Lindem (acee) >;
    b...@ietf.org ; Peter Psenak (ppsenak)
    >; isis-wg@ietf.org
     list >
    *Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

    __ __

    Les,

    __ __

    (If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
   being used, this means that every BFR that is advertising
    a label
   for sub-domain S is advertising a label for the
    combination of
   sub-domain S and Disposition BitStringLength L.)

    __ __

    It says, if MPLS encapsulation is used, there is a Label for the
    {SD, BSL}. So, if there is non-MPLS (ether) only, there will not be
    a Label and the compatibility check will fail. Is that not the same
    a router that does not support MPLS BIER, and treated as a non-BIER
    router?

    __ __

    [Les:] I don’t see how this text can be used to mean “multiple
    encap types can be supported on the same BFR for a given 
”.

    ???

    __ __

    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)
    > wrote:

    Ice -

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

    Les,


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

    Maybe :-), but...


    The point being discussed now is support for multiple
    encapsulation types (BSL conversion was mentioned in the thread
    – but it is NOT the subject being discussed at the moment).

    I got that, it was removed after a long debate sometime back.



    In latest IS-IS BIER draft we changed:

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

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

[Peter Psenak]

Hi Folks,

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



thanks,
Peter

On 13/02/18 08:16 , Tony Przygienda wrote:

+1 what Les says as my understanding of the problem we're tackling here ...

--- tony

On Mon, Feb 12, 2018 at 2:06 PM, Les Ginsberg (ginsberg)
> wrote:

Ice –

__ __

MY understanding is that – in the future – there may be additional
encaps defined for BIER. When that happens, a given BFR may support
multiple encaps. In such a case, it is OK if other BFRs supporting
the same  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  - which is
unnecessarily restrictive.

__ __

Make sense?

__ __

   Les

__ __

__ __

*From:*IJsbrand Wijnands (iwijnand)
*Sent:* Monday, February 12, 2018 1:50 PM


*To:* Les Ginsberg (ginsberg) >
*Cc:* Acee Lindem (acee) >;
b...@ietf.org ; Peter Psenak (ppsenak)
>; isis-wg@ietf.org
 list >
*Subject:* Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

__ __

Les,

__ __

(If MPLS encapsulation (Section 2.1 of [MPLS_BIER_ENCAPS]) is
   being used, this means that every BFR that is advertising
a label
   for sub-domain S is advertising a label for the
combination of
   sub-domain S and Disposition BitStringLength L.)

__ __

It says, if MPLS encapsulation is used, there is a Label for the
{SD, BSL}. So, if there is non-MPLS (ether) only, there will not be
a Label and the compatibility check will fail. Is that not the same
a router that does not support MPLS BIER, and treated as a non-BIER
router?

__ __

[Les:] I don’t see how this text can be used to mean “multiple
encap types can be supported on the same BFR for a given ”.
???

__ __

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)
> wrote:

Ice -

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

Les,


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

Maybe :-), but...


The point being discussed now is support for multiple
encapsulation types (BSL conversion was mentioned in the thread
– but it is NOT the subject being discussed at the moment).

I got that, it was removed after a long debate sometime back.



In latest IS-IS BIER draft we changed:

 > All routers in the flooding scope of the BIER TLVs
MUST advertise the
 > same encapsulation for a given .  A router
discovering
 > encapsulation advertised that is different from its
own MUST report a
 > misconfiguration of a specific .  All received
BIER
 > advertisements associated with the conflicting  pair MUST be
 > ignored.
 >
 > "
 >
 > to
 >
 > "
 >
 > Multiple encapsulations MAY be advertised/supported
for a given
 > .  Clearly, however, there MUST be at least
one encapsulation
 > type in common in order for a BIER encapsulated
packet to be
 > successfully forwarded between two BFRs.
 >

Point has been made that this 

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

[Tony Przygienda]

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)  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)" <
> bier-boun...@ietf.org on behalf of ppse...@cisco.com> wrote:
>
> Hi Tony,
>
> OSPF does not have the original text, so it does not need the new one.
>
> IMHO, the text in section 5 of ISIS BIER draft suits better to the BIER
> architecture draft than to the IGP extension draft.
>
> thanks,
> Peter
>
>
> On 09/02/18 20:17 , Tony Przygienda wrote:
> > Sure ;-)  let me ping Peter @ the bottom then ... I don't think any
> of
> > the stuff applies to OSPF (was ISIS nits) except we can consider an
> > encaps paragraph. We basically suggest both to replace in ISIS the
> > encaps section like this
> >
> > before:
> >
> > "
> > All routers in the flooding scope of the BIER TLVs MUST
> advertise the
> > same encapsulation for a given .  A router discovering
> > encapsulation advertised that is different from its own MUST
> report a
> > misconfiguration of a specific .  All received BIER
> > advertisements associated with the conflicting  pair
> MUST be
> > ignored.
> >
> > "
> >
> > now
> >
> > "
> >
> > Multiple encapsulations MAY be advertised/supported for a given
> > .  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  > > 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
> > > wrote:
> >
> > Les has the diff, I'd expect him to publish any minute to the
> > list ... The encaps was a real defect, the rest is just
> > tightening down the language/spec where it was too loose/too
> > strict.
> >
> > OSPF still needs update with conversion TLV removed, same
> > paragraph on encaps could be useful. I hope Greg pinged
> Peter ...
> >
> > thanks
> >
> > tony
> >
> > On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas <
> akat...@gmail.com
> > > wrote:
> >
> > On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
> > >
> wrote:
> >
> > Went last nits with Les, we found one issue (encaps
> > section was wrong, need to look @ OSPF as well) and
> > basically tightened language in few places.
> >
> >
> > K - please get that  out with the details of changes to
> the
> > list.  I did my AD review back in Oct and looked at the
> > differences before issuing
> > IETF Last Call.
> >
> > I look forward to reviewing the minor changes.
> >
> > Regards,
> > Alia
> >
> > tony
> >
> > On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd
> > > 

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

[Acee Lindem (acee)]

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)" 
 wrote:

Hi Tony,

OSPF does not have the original text, so it does not need the new one.

IMHO, the text in section 5 of ISIS BIER draft suits better to the BIER 
architecture draft than to the IGP extension draft.

thanks,
Peter


On 09/02/18 20:17 , Tony Przygienda wrote:
> Sure ;-)  let me ping Peter @ the bottom then ... I don't think any of
> the stuff applies to OSPF (was ISIS nits) except we can consider an
> encaps paragraph. We basically suggest both to replace in ISIS the
> encaps section like this
>
> before:
>
> "
> All routers in the flooding scope of the BIER TLVs MUST advertise the
> same encapsulation for a given .  A router discovering
> encapsulation advertised that is different from its own MUST report a
> misconfiguration of a specific .  All received BIER
> advertisements associated with the conflicting  pair MUST be
> ignored.
>
> "
>
> now
>
> "
>
> Multiple encapsulations MAY be advertised/supported for a given
> .  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  > 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
> > wrote:
>
> Les has the diff, I'd expect him to publish any minute to the
> list ... The encaps was a real defect, the rest is just
> tightening down the language/spec where it was too loose/too
> strict.
>
> OSPF still needs update with conversion TLV removed, same
> paragraph on encaps could be useful. I hope Greg pinged Peter ...
>
> thanks
>
> tony
>
> On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas  > wrote:
>
> On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
> > wrote:
>
> Went last nits with Les, we found one issue (encaps
> section was wrong, need to look @ OSPF as well) and
> basically tightened language in few places.
>
>
> K - please get that  out with the details of changes to the
> list.  I did my AD review back in Oct and looked at the
> differences before issuing
> IETF Last Call.
>
> I look forward to reviewing the minor changes.
>
> Regards,
> Alia
>
> tony
>
> On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd
> > wrote:
>
> Thanks Les.
>
> Any other feedback? Looks like the concerns have
> been addressed. Speak now.
>
> Cheers,
> Greg
>
> On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg
> (ginsberg)  > 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:
>
> __ __
>
> 

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

[Peter Psenak]

Hi Tony,

OSPF does not have the original text, so it does not need the new one.

IMHO, the text in section 5 of ISIS BIER draft suits better to the BIER 
architecture draft than to the IGP extension draft.


thanks,
Peter


On 09/02/18 20:17 , Tony Przygienda wrote:

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

before:

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

"

now

"

Multiple encapsulations MAY be advertised/supported for a given
.  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 > 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
> wrote:

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

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

thanks

tony

On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas > wrote:

On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
> wrote:

Went last nits with Les, we found one issue (encaps
section was wrong, need to look @ OSPF as well) and
basically tightened language in few places.


K - please get that  out with the details of changes to the
list.  I did my AD review back in Oct and looked at the
differences before issuing
IETF Last Call.

I look forward to reviewing the minor changes.

Regards,
Alia

tony

On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd
> wrote:

Thanks Les.

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

Cheers,
Greg

On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg
(ginsberg) > 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

 

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

[Peter Psenak]

Hi Tony,

On 09/02/18 20:04 , Tony Przygienda wrote:

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

OSPF still needs update with conversion TLV removed,


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


thanks,
Peter




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 > wrote:

On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda
> wrote:

Went last nits with Les, we found one issue (encaps section was
wrong, need to look @ OSPF as well) and basically tightened
language in few places.


K - please get that  out with the details of changes to the list.  I
did my AD review back in Oct and looked at the differences before
issuing
IETF Last Call.

I look forward to reviewing the minor changes.

Regards,
Alia

tony

On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd > wrote:

Thanks Les.

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

Cheers,
Greg

On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg)
> 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:gjs...@gmail.com
]
*Sent:* Thursday, February 01, 2018 2:23 AM
*To:* Toerless Eckert >
*Cc:* Les Ginsberg (ginsberg) >; Tony Przygienda
>;
Hannes Gredler (han...@gredler.at
) >; b...@ietf.org
; isis-wg@ietf.org
 list >; Christian Hopps
>


*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
> 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 +, 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
   

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

[IJsbrand Wijnands]

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.
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

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

[Greg Shepherd]

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 
wrote:

> Les has the diff, I'd expect him to publish any minute to the list ... The
> encaps was a real defect, the rest is just tightening down the
> language/spec where it was too loose/too strict.
>
> OSPF still needs update with conversion TLV removed, same paragraph on
> encaps could be useful. I hope Greg pinged Peter ...
>
> thanks
>
> tony
>
> On Fri, Feb 9, 2018 at 10:58 AM, Alia Atlas  wrote:
>
>> On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda 
>> wrote:
>>
>>> Went last nits with Les, we found one issue (encaps section was wrong,
>>> need to look @ OSPF as well) and basically tightened language in few places.
>>>
>>
>> K - please get that  out with the details of changes to the list.  I did
>> my AD review back in Oct and looked at the differences before issuing
>> IETF Last Call.
>>
>> I look forward to reviewing the minor changes.
>>
>> Regards,
>> Alia
>>
>>
>>> tony
>>>
>>> On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd  wrote:
>>>
 Thanks Les.

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

 Cheers,
 Greg

 On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) <
 ginsb...@cisco.com> 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:gjs...@gmail.com]
> *Sent:* Thursday, February 01, 2018 2:23 AM
> *To:* Toerless Eckert 
> *Cc:* Les Ginsberg (ginsberg) ; Tony Przygienda <
> tonysi...@gmail.com>; Hannes Gredler (han...@gredler.at) <
> han...@gredler.at>; b...@ietf.org; isis-wg@ietf.org list <
> isis-wg@ietf.org>; Christian Hopps 
>
> *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 
> 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 +, 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:t...@cs.fau.de]
> > > Sent: Saturday, July 22, 2017 6:34 AM
> > > To: Les Ginsberg (ginsberg)
> > > Cc: Tony Przygienda; Hannes Gredler (han...@gredler.at); Greg
> Shepherd;
> > > b...@ietf.org; isis-wg@ietf.org 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 

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

[Alia Atlas]

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)  wrote:

> Greg,
>
> I think there is a confusion here, there is no consensus to remove BAR! We
> want to keep it, but might change the format a little...
>
> Sent from my iPhone
>
> On 9 Feb 2018, at 17:49, Greg Shepherd  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  wrote:
>
>> Thanks Les.
>>
>> Any other feedback? Looks like the concerns have been addressed. Speak
>> now.
>>
>> Cheers,
>> Greg
>>
>> On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) <
>> ginsb...@cisco.com> 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:gjs...@gmail.com]
>>> *Sent:* Thursday, February 01, 2018 2:23 AM
>>> *To:* Toerless Eckert 
>>> *Cc:* Les Ginsberg (ginsberg) ; Tony Przygienda <
>>> tonysi...@gmail.com>; Hannes Gredler (han...@gredler.at) <
>>> han...@gredler.at>; b...@ietf.org; isis-wg@ietf.org list <
>>> isis-wg@ietf.org>; Christian Hopps 
>>>
>>> *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  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 +, 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:t...@cs.fau.de]
>>> > > Sent: Saturday, July 22, 2017 6:34 AM
>>> > > To: Les Ginsberg (ginsberg)
>>> > > Cc: Tony Przygienda; Hannes Gredler (han...@gredler.at); Greg
>>> Shepherd;
>>> > > b...@ietf.org; isis-wg@ietf.org 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 

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

[Alia Atlas]

On Fri, Feb 9, 2018 at 12:46 PM, Tony Przygienda 
wrote:

> Went last nits with Les, we found one issue (encaps section was wrong,
> need to look @ OSPF as well) and basically tightened language in few places.
>

K - please get that  out with the details of changes to the list.  I did my
AD review back in Oct and looked at the differences before issuing
IETF Last Call.

I look forward to reviewing the minor changes.

Regards,
Alia


> tony
>
> On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd  wrote:
>
>> Thanks Les.
>>
>> Any other feedback? Looks like the concerns have been addressed. Speak
>> now.
>>
>> Cheers,
>> Greg
>>
>> On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) <
>> ginsb...@cisco.com> 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:gjs...@gmail.com]
>>> *Sent:* Thursday, February 01, 2018 2:23 AM
>>> *To:* Toerless Eckert 
>>> *Cc:* Les Ginsberg (ginsberg) ; Tony Przygienda <
>>> tonysi...@gmail.com>; Hannes Gredler (han...@gredler.at) <
>>> han...@gredler.at>; b...@ietf.org; isis-wg@ietf.org list <
>>> isis-wg@ietf.org>; Christian Hopps 
>>>
>>> *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  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 +, 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:t...@cs.fau.de]
>>> > > Sent: Saturday, July 22, 2017 6:34 AM
>>> > > To: Les Ginsberg (ginsberg)
>>> > > Cc: Tony Przygienda; Hannes Gredler (han...@gredler.at); Greg
>>> Shepherd;
>>> > > b...@ietf.org; isis-wg@ietf.org 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 

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

[Tony Przygienda]

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

On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd  wrote:

> Thanks Les.
>
> Any other feedback? Looks like the concerns have been addressed. Speak now.
>
> Cheers,
> Greg
>
> On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> 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:gjs...@gmail.com]
>> *Sent:* Thursday, February 01, 2018 2:23 AM
>> *To:* Toerless Eckert 
>> *Cc:* Les Ginsberg (ginsberg) ; Tony Przygienda <
>> tonysi...@gmail.com>; Hannes Gredler (han...@gredler.at) <
>> han...@gredler.at>; b...@ietf.org; isis-wg@ietf.org list <
>> isis-wg@ietf.org>; Christian Hopps 
>>
>> *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  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 +, 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:t...@cs.fau.de]
>> > > Sent: Saturday, July 22, 2017 6:34 AM
>> > > To: Les Ginsberg (ginsberg)
>> > > Cc: Tony Przygienda; Hannes Gredler (han...@gredler.at); Greg
>> Shepherd;
>> > > b...@ietf.org; isis-wg@ietf.org 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

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

[Tony Przygienda]

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  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  wrote:
>
>> Thanks Les.
>>
>> Any other feedback? Looks like the concerns have been addressed. Speak
>> now.
>>
>> Cheers,
>> Greg
>>
>> On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) <
>> ginsb...@cisco.com> 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:gjs...@gmail.com]
>>> *Sent:* Thursday, February 01, 2018 2:23 AM
>>> *To:* Toerless Eckert 
>>> *Cc:* Les Ginsberg (ginsberg) ; Tony Przygienda <
>>> tonysi...@gmail.com>; Hannes Gredler (han...@gredler.at) <
>>> han...@gredler.at>; b...@ietf.org; isis-wg@ietf.org list <
>>> isis-wg@ietf.org>; Christian Hopps 
>>>
>>> *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  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 +, 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:t...@cs.fau.de]
>>> > > Sent: Saturday, July 22, 2017 6:34 AM
>>> > > To: Les Ginsberg (ginsberg)
>>> > > Cc: Tony Przygienda; Hannes Gredler (han...@gredler.at); Greg
>>> Shepherd;
>>> > > b...@ietf.org; isis-wg@ietf.org 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 

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

[Les Ginsberg (ginsberg)]

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:gjs...@gmail.com]
Sent: Thursday, February 01, 2018 2:23 AM
To: Toerless Eckert 
Cc: Les Ginsberg (ginsberg) ; Tony Przygienda 
; Hannes Gredler (han...@gredler.at) ; 
b...@ietf.org; isis-wg@ietf.org list ; Christian Hopps 

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 
> 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 +, 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:t...@cs.fau.de]
> > Sent: Saturday, July 22, 2017 6:34 AM
> > To: Les Ginsberg (ginsberg)
> > Cc: Tony Przygienda; Hannes Gredler 
> > (han...@gredler.at); Greg Shepherd;
> > b...@ietf.org; 
> > isis-wg@ietf.org 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 +, Les Ginsberg (ginsberg) wrote:
> > > Tony/Toerless ???
> > >
> > > There is an explicit statement as to scope:
> > >
> > > 
> > > Section 4.2
> > > ???
> > >o  BIER sub-TLVs MUST NOT be included when a prefix reachability
> > >   advertisement is leaked between levels.
> > > 
> > >
> > > Tony seems to have forgotten that we had a 

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

[Greg Shepherd]

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  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 +, 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:t...@cs.fau.de]
> > > Sent: Saturday, July 22, 2017 6:34 AM
> > > To: Les Ginsberg (ginsberg)
> > > Cc: Tony Przygienda; Hannes Gredler (han...@gredler.at); Greg
> Shepherd;
> > > b...@ietf.org; isis-wg@ietf.org 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 +, Les Ginsberg (ginsberg)
> wrote:
> > > > Tony/Toerless ???
> > > >
> > > > There is an explicit statement as to scope:
> > > >
> > > > 
> > > > Section 4.2
> > > > ???
> > > >o  BIER sub-TLVs MUST NOT be included when a prefix reachability
> > > >   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)
> > > >
> > > > Note this is ???consistent??? with https://www.ietf.org/id/draft-
> ietf-bier-
> > > ospf-bier-extensions-07.txt Section 2.5 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:bier-boun...@ietf.org] On Behalf Of Tony
> Przygienda
> > > > Sent: Friday, July 21, 2017 5:17 AM
> > > > To: Toerless Eckert
> > > > Cc: Hannes 

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

[Toerless Eckert]

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 +, 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:t...@cs.fau.de]
> > Sent: Saturday, July 22, 2017 6:34 AM
> > To: Les Ginsberg (ginsberg)
> > Cc: Tony Przygienda; Hannes Gredler (han...@gredler.at); Greg Shepherd;
> > b...@ietf.org; isis-wg@ietf.org 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 +, Les Ginsberg (ginsberg) wrote:
> > > Tony/Toerless ???
> > >
> > > There is an explicit statement as to scope:
> > >
> > > 
> > > Section 4.2
> > > ???
> > >o  BIER sub-TLVs MUST NOT be included when a prefix reachability
> > >   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)
> > >
> > > Note this is ???consistent??? with 
> > > https://www.ietf.org/id/draft-ietf-bier-
> > ospf-bier-extensions-07.txt Section 2.5 > 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:bier-boun...@ietf.org] On Behalf Of Tony Przygienda
> > > Sent: Friday, July 21, 2017 5:17 AM
> > > To: Toerless Eckert
> > > Cc: Hannes Gredler (han...@gredler.at); Greg Shepherd; b...@ietf.org;
> > > isis-wg@ietf.org 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 

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

[Tony Przygienda]

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  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.
>
> 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
> b...@ietf.org
> 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
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg