Subject: [Bier] Alvaro Retana's No Objection on draft-ietf-bier-isis-extensions-07: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Thu, 22 Feb 2018 06:39:57 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-bier-isis-extensions-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bier-isis-extensions/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Section 4.2: "Prefix length MUST be 32 for an IPv4 prefix or 128 for an
IPv6 prefix"  What should the receiver do of the length doesn't indicate a host
route?

(2) Section 4.2: "When the Prefix Attributes Flags sub-TLV is present N flag
MUST be set.  [RFC7794]"  This change from rfc7794 seems like it could impact
other uses of the flag (based on the expected behavior in rfc7794).  What
should a receiver do if the flag is not set (which would be compliant with
rfc7794)?

(3) "Advertisements associated with <0,0> and <2,0> MUST be ignored."  This
text is part of the example, so the "MUST" is just stating a fact. s/MUST/must

(4) From 5.4:

   A router that desires to participate in <MT,SD> MUST advertise for
   each bitstring length it supports in <MT,SD> a Maximum Set ID that
   guarantees to cover the maximum BFR-id injected into <MT,SD> (which
   implies a certain maximum set id per bitstring length as described in
   [RFC8279]).  Any router that violates this condition MUST be excluded
   from BIER BFTs for <MT,SD>.

What is "this condition" (in the last sentence)?  From the rest of the
paragraph, it seems like the condition is the "[guarantee] to cover the maximum
BFR-id injected into <MT,SD>".  If so, how can the receiver verify that
condition/guarantee?  Maybe the reference is just to the combination of BSL,
MT, SD, Max SI, advertised.  Please clarify.

(5) Section 5.5: "Each BFER/BFIR MAY advertise with its TLV<MT,SD> the BFR-id
that it has administratively chosen."  If the BFER/BFIR doesn't include the
BFD-id, is there any value in advertising the new sub-TLV?

BTW, I think the text was meant to indicate that the BFR can chose to not
advertise the "BFR-id that it has administratively chosen" (as in not advertise
anything), but another interpretation of the text could be that it may
advertise a BFR-id it didn't chose (as in any other id, including someone
else's).

(6) Section 5.7: "BIER domain information SHOULD change infrequently."  From a
Normative point of view, what does this mean?  What if the changes are
frequent?  I think that the sentence is just a statement of fact --
s/SHOULD/should  If the BFR should do something to limit the frequency of
changes, please say so.

(7) Section 6.1: "If no BFR-id has been assigned this field is set to the
invalid BFR-id."  I looked in rfc8279 for the text about "invalid BFR-id", but
found this instead: "The value 0 is not a legal BFR-id."  I assume that in this
case "invalid" is the same as "not legal".  It would be nice to be consistent.

(8) Section 6.2: "On violation of any of the following conditions, the
receiving router MUST ignore the encapsulating BIER Info sub-TLV."  If a
violation is detected, the result is that *all* BIER Info sub-TLVs (from *all*
BFRs contributing to the violation) are ignored, right?  The text is not clear
as to whether the result applies to all or just the BFR that advertised last
(and resulted in the violation being detected).

(9) Section 6.2: "All labels in the range MUST represent valid label values" 
What is a "valid label value"?

(10) Security Considerations: I support Eric's DISCUSS.  It seems to me that an
attacker could simply advertise duplicate BFR-IDs or overlapping label ranges
and have a significant impact on the network.

(11) Section 8: "The RFC is aligned with the
[I-D.draft-ietf-bier-ospf-bier-extensions-10] draft as far as the protocol
mechanisms overlap."  Good!

(11.1) The ospf draft mentions that the extensions are only applicable to MPLS
networks.  This draft also only defines an MPLS encapsulation sub-sub-TLV. 
Section 5.2 seems to however open the door to multiple encapsulations
("Multiple encapsulations MAY be advertised/supported...")...but without the
support (?) for anything else.  Please be clear about it since it may not be
clear to a casual reader.

(11.2) The BIER Info sub-TLV doesn't include an explicit indication of the MT
as does the OSPF version -- which is fine.  Assuming that the information is
included somewhere else so that the <MT, SD> combination can be evaluated,
please include details of how the MT information is obtained.

(11.3) The latest version of draft-ietf-bier-ospf-bier-extensions points to
this document as defining a "BIER Algorithm Registry"...but I don't see that
yet.  I'm eagerly awaiting the nest version!

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Feb 2018 23:55:48 +0000

Alvaro -

Thanx for the careful review.

V8 of the draft has been published.  It was not in response to your comments - so there is at least one more version to go - but some of your comments have been addressed or made obsolete.
Detail inline.

> -----Original Message-----
> From: Alvaro Retana [mailto:[email-masked]]
> Sent: Thursday, February 22, 2018 6:40 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Hooman Bidgoli
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: Alvaro Retana's No Objection on draft-ietf-bier-isis-extensions-07:
> (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> IPv6 prefix"  What should the receiver do of the length doesn't indicate a
> host route?
> 
[Les:] Advertisements associated with  non-host prefix reachability MUST be ignored. This also  is the case if N flag is NOT set.
I will make that explicit.

> should a receiver do if the flag is not set (which would be compliant with

[Les:] This is NOT a change to RFC7794. Setting of N flag for host prefixes is optional - not mandatory. From RFC7794:

<snip>
N-flag:  Node Flag (Bit 2)
      Set when the prefix identifies the advertising router, i.e., the
      prefix is a host prefix advertising a globally reachable address
      typically associated with a loopback address.

      The advertising router MAY choose to NOT set this flag even when
      the above conditions are met.

      If the flag is set and the prefix length is NOT a host prefix (/32
      for IPV4, /128 for IPv6), then the flag MUST be ignored.  The flag
      MUST be preserved when leaked between levels."
<end snip>

We are saying for BIER usage N flag MUST be set.

> text is part of the example, so the "MUST" is just stating a fact. s/MUST/must

[Les:] ACK

> paragraph, it seems like the condition is the "[guarantee] to cover the
> maximum BFR-id injected into <MT,SD>".  If so, how can the receiver verify
> that condition/guarantee?  Maybe the reference is just to the combination
> of BSL, MT, SD, Max SI, advertised.  Please clarify.
> 
[Les:] I prefer to remove this paragraph. I think the best it can do is be redundant with what is in RFC8279. At worst it will be in conflict.
I note OSPF BIER Draft has no equivalent text.

Is this OK with you?

> (5) Section 5.5: "Each BFER/BFIR MAY advertise with its TLV<MT,SD> the BFR-
> id that it has administratively chosen."  If the BFER/BFIR doesn't include the
[Les:] Clearly that is not what is intended. I will rephrase to indicate that if it does not have a BFR-id field MUST be 0.

> (6) Section 5.7: "BIER domain information SHOULD change infrequently."
> From a Normative point of view, what does this mean?  What if the changes
> are frequent?  I think that the sentence is just a statement of fact --
[Les:] The intent here is to ensure that an implementation rate limits the regeneration of LSPs caused by changes in BIER info. While it is expected that standard protocol timers which control LSP generation should be sufficient for transient bursts of changes, if - likely due to some pathology - sustained churning of BIER info is occurring implementations SHOULD dampen. I will revise the text.

> (7) Section 6.1: "If no BFR-id has been assigned this field is set to the invalid
> BFR-id."  I looked in rfc8279 for the text about "invalid BFR-id", but found this
> instead: "The value 0 is not a legal BFR-id."  I assume that in this case "invalid"
> is the same as "not legal".  It would be nice to be consistent.
> 
[Les:] Peter has suggested 

"the value of this field is set to 0, which is defined as illegal in [RFC8279]."

Which seems fine to me.

> (8) Section 6.2: "On violation of any of the following conditions, the receiving
> router MUST ignore the encapsulating BIER Info sub-TLV."  If a violation is
> detected, the result is that *all* BIER Info sub-TLVs (from *all* BFRs
> contributing to the violation) are ignored, right?
[Les:] >  The text is not clear as to
> whether the result applies to all or just the BFR that advertised last (and
> resulted in the violation being detected).
> 
[Les:] Sigh...yes - you are right. The OSPF draft states this much better. I will correct this section.

> What is a "valid label value"?
[Les:] Again I agree with Peter's resolution. As we only have 20 bits for the label in the encoding all values are "valid".
Best to remove this text.

> and have a significant impact on the network.
[Les:] Please see revised Security section in v8 of the draft,

> (11) Section 8: "The RFC is aligned with the [I-D.draft-ietf-bier-ospf-bier-
> extensions-10] draft as far as the protocol mechanisms overlap."  Good!
> 
> (11.1) The ospf draft mentions that the extensions are only applicable to
> MPLS networks.  This draft also only defines an MPLS encapsulation sub-sub-
> TLV.
> ("Multiple encapsulations MAY be advertised/supported...")...but without
> the support (?) for anything else.  Please be clear about it since it may not be
[Les:] This has been removed/clarified in V8 of the draft.
 
> included somewhere else so that the <MT, SD> combination can be
> evaluated, please include details of how the MT information is obtained.
> 
[Les:] The BIER Info sub-TLV is advertised in the context of Prefix Reachability TLV which has the MTID.

> (11.3) The latest version of draft-ietf-bier-ospf-bier-extensions points to this
> document as defining a "BIER Algorithm Registry"...but I don't see that yet.
> I'm eagerly awaiting the nest version!
> 

[Les:] Now you have it. :-)

   Les

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 23 Feb 2018 11:36:39 -0800

Here are my comments (having read the extend -09 version not published yet)

> host

I think we should fall back as much and as hard as we can on RFC 7794. The
use of N-flag preconditions a host prefix per 7794. We're done?

> should a receiver do if the flag is not set (which would be compliant with

I think if we agree on host we align with 7794 and we're done. Albeit the
_architecture_ can advocate _any_ prefix this is a specific IGP signalling
draft and hence can only implement limited subset of the architecture.

> text is part of the example, so the "MUST" is just stating a fact.
ok, I think the text is not precise enough. We have a single router
advertising <0,0> _and_ <2,0> while all other routers may happily advertise
<0,0>. Operationally, shutting down a whole domain (whatever the domain is)
because of one router misbehaving has proven a bad proposition. I think the
text must read as something to the effect of "Any BIER-TLV advertising a
subdomain in a different MT than the one locally configured MUST be ignored"

> maximum

I see the section removed in -09, something I would agree with for multiple
reasons. First: a router coming in with a 'too-high BFR-id' can shutdown a
whole domain, real bad. Second, a good implementation should automatically
adjust and increase advertised range. We could put something to the effect
of "A router SHOULD advertise a range covering the highest visible BFRid".
Worst can happen, we have certain BFR-ids being blackholed where the
operational community is equally split whether they prefer blackout on
misconfig/misbehavior or brownout, oftne changing opinion depending on the
last pain point ;-)

> advertise a BFR-id it didn't chose (as in any other id, including someone

I think -09 covers that adequatly now.

> From a

I think -09 says as much about it as it can.

> case "invalid" is the same as "not legal".  It would be nice to be

I suggest to adjust the terminology in front to

Invalid BFR-id:  Also called not legal or
      unassigned BFR-id.  The special value 0 is reserved
      for this purpose.

And the whole draft refer everywhere where it's the case to "invalid
bfr-id" consistently.

It is a mild architectural sloppiness that we did not differentiate between
"invalid" and "undefined" but right now it's a distinction without
differentiation.

> (and resulted in the violation being detected).

Delicate. The language "all BFRs contributing to the violation" is too
loose IMO.
Basically each advertisement exhibiting a defect MUST be ignored, i.e. per
BFR. That "cauterizes" the routers misbehaving while keeping the sane part
of the domain alive. One can consider that a "brownout on the domain" ...

> What is a "valid label value"?

I think -09 addresses that.

> and have a significant impact on the network.

-09 took a bit of a heavy hammer to the task here but I agree this is a
sane and good approach.

> mechanisms overlap."  Good!

I expect those comments carrying through to OSPF then. Both editors did a
meticulous job trying to align the signalling as far as possible.

> MPLS
> the

I think introduction contains the WG consensus text

> please include details of how the MT information is obtained.

this is well understood by all skilled in the art. ISIS has a very
orthogonal and clean MT encoding carried through the protocol elements.

> yet.  I'm eagerly awaiting the nest version!

I think the registry creation has been treated separately ...

thanks

--- tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Feb 2018 19:59:40 +0000

Tony –

Inline.

From: Tony Przygienda [mailto:[email-masked]]
Sent: Friday, February 23, 2018 11:37 AM
To: Alvaro Retana <[email-masked]>
Cc: The IESG <[email-masked]>; BIER WG <[email-masked]>; [email-masked]; Hooman Bidgoli <[email-masked]>; [email-masked]
Subject: Re: [Bier] Alvaro Retana's No Objection on draft-ietf-bier-isis-extensions-07: (with COMMENT)

I think we should fall back as much and as hard as we can on RFC 7794. The use of N-flag preconditions a host prefix per 7794. We're done?

I think if we agree on host we align with 7794 and we're done. Albeit the _architecture_ can advocate _any_ prefix this is a specific IGP signalling draft and hence can only implement limited subset of the architecture.

ok, I think the text is not precise enough. We have a single router advertising <0,0> _and_ <2,0> while all other routers may happily advertise <0,0>. Operationally, shutting down a whole domain (whatever the domain is) because of one router misbehaving has proven a bad proposition. I think the text must read as something to the effect of "Any BIER-TLV advertising a subdomain in a different MT than the one locally configured MUST be ignored"

[Les:] This gets tricky. Suppose Router A sends <0,0> and Router B sends <2,0> - who wins??
You seem to be assuming that only one router is “crazy” and sends both <0,0> and <2,0> - but this seems to me to be the more unlikely case. Far more likely that two routers disagree on the pairing. So I think we need to ignore all such advertisements from all routers. Agreed that this means one misconfig on one router can affect the whole sub-domain – but I don’t see a good alternative.
??

(4) From 5.4:

I see the section removed in -09, something I would agree with for multiple reasons. First: a router coming in with a 'too-high BFR-id' can shutdown a whole domain, real bad. Second, a good implementation should automatically adjust and increase advertised range. We could put something to the effect of "A router SHOULD advertise a range covering the highest visible BFRid". Worst can happen, we have certain BFR-ids being blackholed where the operational community is equally split whether they prefer blackout on misconfig/misbehavior or brownout, oftne changing opinion depending on the last pain point ;-)

      for this purpose.
And the whole draft refer everywhere where it's the case to "invalid bfr-id" consistently.

[Les:] The first part (terminology) was already put in. I have modified the body to reference “Invalid BFR-id” as you suggested.

   Les

It is a mild architectural sloppiness that we did not differentiate between "invalid" and "undefined" but right now it's a distinction without differentiation.

Delicate. The language "all BFRs contributing to the violation" is too loose IMO.
Basically each advertisement exhibiting a defect MUST be ignored, i.e. per BFR. That "cauterizes" the routers misbehaving while keeping the sane part of the domain alive. One can consider that a "brownout on the domain" ...

-09 took a bit of a heavy hammer to the task here but I agree this is a sane and good approach.

I expect those comments carrying through to OSPF then. Both editors did a meticulous job trying to align the signalling as far as possible.

this is well understood by all skilled in the art. ISIS has a very orthogonal and clean MT encoding carried through the protocol elements.

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 23 Feb 2018 12:19:31 -0800

> *[Les:] This gets tricky. Suppose Router A sends <0,0> and Router B sends
> <2,0> - who wins??*
>
> *You seem to be assuming that only one router is “crazy” and sends both
> <0,0> and <2,0> - but this seems to me to be the more unlikely case. Far
> more likely that two routers disagree on the pairing. So I think we need to
> ignore all such advertisements from all routers. Agreed that this means one
> misconfig on one router can affect the whole sub-domain – but I don’t see a
> good alternative.*
>
> *??*
>
>
>

Actually here the solution is very elegant. If router A,B,C configured
<0,0> and routers D,E <2,0>  the subdomain for A,B,C will be in MT=0 and
for D,E in MT=2 since e'one will ignore the other "sub-domain partition".
While I would _never_ advise a customer to build a network architecture
this way, this will allow to have one misconfigured router "sulk in the
corner" while the rest is getting their job done. With text saying "report
misconfiguration" the netop console will be flashing red light so such a
thing can be found relatively quickly without one fat finger taking down a
subdomain with potentially lots of valuable traffic ...

makes sense?

rest I'm happy we agree on ...

--- tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Feb 2018 20:35:20 +0000

From: Tony Przygienda [mailto:[email-masked]]
Sent: Friday, February 23, 2018 12:20 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; The IESG <[email-masked]>; BIER WG <[email-masked]>; [email-masked]; Hooman Bidgoli <[email-masked]>; [email-masked]
Subject: Re: [Bier] Alvaro Retana's No Objection on draft-ietf-bier-isis-extensions-07: (with COMMENT)

Actually here the solution is very elegant. If router A,B,C configured <0,0> and routers D,E <2,0>  the subdomain for A,B,C will be in MT=0 and for D,E in MT=2 since e'one will ignore the other "sub-domain partition". While I would _never_ advise a customer to build a network architecture this way, this will allow to have one misconfigured router "sulk in the corner" while the rest is getting their job done. With text saying "report misconfiguration" the netop console will be flashing red light so such a thing can be found relatively quickly without one fat finger taking down a subdomain with potentially lots of valuable traffic ...
makes sense?
[Les:] Agreed.
   Les
rest I'm happy we agree on ...

--- tony

---

From: Alvaro Retana <[email-masked]>
Date: Sat, 24 Feb 2018 09:08:10 -0500

Les:

Hi!

I looked at the latest version (-09) and that addresses my comments.
Thanks!!

Alvaro.

On February 22, 2018 at 6:55:50 PM, Les Ginsberg (ginsberg) (
[email-masked]) wrote:

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 24 Feb 2018 08:12:17 -0800

ok, ready for WG LC then?

--- tony

On Sat, Feb 24, 2018 at 6:08 AM, Alvaro Retana <[email-masked]>
wrote:

> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
>

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 26 Feb 2018 10:21:12 -0800

Draft https://tools.ietf.org/html/draft-ietf-bier-isis-extensions-09 has
been returned to the working group for a limited WG LC of the changes
introduced since version -06 (IETF LC & AD comments)

The last call last 7 days, i.e. finishes next Monday ...

Please observe  that AFAIS this is the last chance for comments before
publication of this pivotal draft ...

thanks to Les as editor for keeping up with the incoming comments in a very
timely manner ...

thanks

--- tony