Subject: [Bier] draft-ietf-bier-isis-extension-06 shepherd writeup available

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 1 Feb 2018 18:31:43 +0000

Hi All

There is a shepherd writeup available for draft-ietf-bier-isis-extension-06, I am not sure if the data tracker should send out an email when there is a shepherd writeup but it did not happen.

As such the manual broadcast.

Regards

Hooman

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 1 Feb 2018 22:17:24 +0000

Hooman -

Thanx for the careful review.
Responses to your comments:

Section 3: is there a reason that sub-sub-tlvs are not sequential? i.e. type 1 and 3 and no type 2.

LES: As recently as V5 of the draft sub-sub-tlv 2 was used for:

2       BIER sub-domain Tree Type

Tree type support was removed from the draft in V6, but the remaining two sub-sub-TLV codepoints were deliberately not adjusted so as not to introduce backwards compatibility issues for any early implementations.
The number assigned to a code point is never of significance in and of itself - and nothing can be inferred from the relative values of code points.

Section 4.1: An ISIS signaled BIER domain is aligned with the scope of distribution of BFR-prefixes that identify the BFRs within ISIS.
Comment: should it be BIER sub-domain? As bier-architecture aligns BFR-PREFIX to a subdomain.

LES: The prefix itself is NOT sub-domain specific - but the advertisement of BIER information associated with that prefix is sub-domain/topology specific.
Section 6.1 states:

"This sub-TLV carries the information for the BIER sub-domains that
   the router participates in as BFR.  This sub-TLV MAY appear multiple
   times in a given prefix-reachability TLV - once for each sub-domain
   supported in the associated topology."

Section 4.1: The mapping of sub-domains to topologies MUST be consistent within a BIER flooding domain.
Comment: what is a BIER flooding domain here? The terminology is not consistence with bier-architecture, might be worth a while to have a sentence explaining it.

LES: The flooding domain is the IGP flooding domain - but I agree the text could be more clear on this point. I will add something.

Section 5.1: All routers in the flooding scope of the BIER sub-TLVs MUST advertise the same sub-domain within the same multi-topology.
Comment: This means one MT can have multiple SDs. As an example, <MT1, SD1>, <MT1, SD2>. But <MT2, SD1> is not legal, since SD1 is part of MT1. An example might be appropriate here as it is not to clear.

LES: OK - will add a clarifying example.

I am going to wait for the discussion about label-range-size to reach a conclusion before providing a new version - so it will be a few more days before we publish an update.

   Les

From: BIER [mailto:[email-masked]] On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Thursday, February 01, 2018 10:32 AM
To: BIER WG <[email-masked]>; [email-masked]
Subject: [Bier] draft-ietf-bier-isis-extension-06 shepherd writeup available

Hi All

Regards

Hooman

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 2 Feb 2018 08:00:54 +0800

>
>
>
> *Section 4.1: The mapping of sub-domains to topologies MUST be consistent
> within a BIER flooding domain.*
>
> *Comment: what is a BIER flooding domain here? The terminology is not
> consistence with bier-architecture, might be worth a while to have a
> sentence explaining it.*
>
>
>
> *LES: The flooding domain is the IGP flooding domain – but I agree the
> text could be more clear on this point. I will add something.*
>
>
>
> *Section 5.1: All routers in the flooding scope of the BIER sub-TLVs MUST
> advertise the same sub-domain within the same multi-topology.*
>
> *Comment: This means one MT can have multiple SDs. As an example, <MT1,
> SD1>, <MT1, SD2>. But <MT2, SD1> is not legal, since SD1 is part of MT1. An
> example might be appropriate here as it is not to clear.*
>
>
>
> *LES: OK – will add a clarifying example.*
>

Yes, we cannot emphasize clearly enough what the legal associations between
MT/SD/BML/ENC/SET are ...    In fact I wish we'd have something like in the
architecture since the question comes up over and over again in multiple of
those places when I talk BIER in depth

MT <1-*> SD <1-*> ENC <1-*> BML
                   ^         ^
                   1         +-- associated via label/BIFT-id
                   |         v
                   +-----*> SET

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 2 Feb 2018 15:10:41 +0000

Inline "HB>"

Regards

Hooman

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, February 1, 2018 5:17 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; BIER WG <[email-masked]>; [email-masked]
Subject: RE: [Bier] draft-ietf-bier-isis-extension-06 shepherd writeup available

Hooman -

HB> thanks, understood.

HB>  I agree that same bier prefix can be used in different sub-domains, but as you said the advertisement of the info is a sub-domain function... This is why I find the text "An ISIS signaled BIER domain" confusing, as we signal in a sub-domain. Just my 2 cents.
Section 4.1: The mapping of sub-domains to topologies MUST be consistent within a BIER flooding domain.
Comment: what is a BIER flooding domain here? The terminology is not consistence with bier-architecture, might be worth a while to have a sentence explaining it.

   Les

From: BIER [mailto:[email-masked]] On Behalf Of Bidgoli, Hooman (Nokia - CA/Ottawa)
Sent: Thursday, February 01, 2018 10:32 AM
To: BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [Bier] draft-ietf-bier-isis-extension-06 shepherd writeup available

Hi All

Regards

Hooman