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

From: Toerless Eckert <[email-masked]>
Date: Fri, 21 Jul 2017 08:27:41 +0200

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

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 21 Jul 2017 14:17:23 +0200

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

> be great (All BIER sub-domains TLVs are flooded across all ISIS
> areas/levels,                     so they span the whole ISIS domain).
>
> 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.
>
> _______________________________________________
> BIER mailing list
> [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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 22 Jul 2017 06:03:53 +0000

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:

[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

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

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 22 Jul 2017 15:34:19 +0200

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 ???
> ???
> 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.
> 
> [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
> 
> 
> 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: Tony Przygienda <[email-masked]>
Date: Sun, 23 Jul 2017 11:02:27 +0200

On Sat, Jul 22, 2017 at 8:03 AM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

>       advertisement is leaked between levels.

sigh, missed that on fly-over.

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

I forgot about that specifically since we had multiple discussions, you,
Peter, others and different conclusions have been reached in time per
protocol. You're here to keep my distracted self honest ...

OK< with that I think ISIS is a no-action-necessary.

>
>
> Note this is “consistent” with https://www.ietf.org/id/draft-
> ietf-bier-ospf-bier-extensions-07.txt Section 2.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.
>

ah, ok, I see that that we're area-scope now as well. I know we had an
agreement before that it would be AS scope or something so that changed and
is consistent ...

IMO no action on OSPF necessary either, Toerless ... Sorry for my imperfect
memories when we talked ....

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

Well, we could say "loopbacks must be leaked ..." and so on but this is
cleaner. We limit ourselves and solve the problem in the general ISIS
framework if it comes up ...

thanks Les

--- tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 23 Jul 2017 23:28:08 +0000

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
> When searching various terms in the doc to figure out what happens i am not
> sure why i missed this one.
> 
> 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.
> 
> > 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.
> >
> someone who read BIER & ISIS. I can reread it or Les can comment whether
> we should tighten glossary ...
> >
> > 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:
> > 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
> > 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 ?).
> >
> 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.
> >
> > 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.
> > 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"
> > 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: Toerless Eckert <[email-masked]>
Date: Tue, 25 Jul 2017 21:52:11 +0200

Thanks, Less, that would be lovely!

I didn't check the OSPF draft, if its similar state, explanatory text wold equally be appreciated.