Subject: [Bier] Benoit Claise's Discuss on draft-ietf-bier-architecture-07: (with DISCUSS and COMMENT)

From: Benoit Claise <[email-masked]>
Date: Thu, 06 Jul 2017 06:13:56 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-bier-architecture-07: Discuss

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-architecture/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1. I want to come back to the experimental status.

I have seen Alia's reply:

    In the BIER Charter, work item 9 describes a document based on deployment
    experience that can justify moving the BIER work from Experimental to
    Standards Track.  When I chartered the WG, it wasn't clear whether it was
    merely a good idea or a good idea with enough motivations towards
    deployment that it is worth complicating the architecture at the narrow
    point of the IP hourglass.

>From the writeup, it seems that the experiment is successful already:

    The vendors are being quite tight lipped about current implementations.
    Operator feedback indicates there are at least two implementations
    currently, with others in the works. There are currently five vendors
    collaborating on the work in the IETF.

However, I've not been following the specifications development and
implementation to provide a definitive answer.

At the minimum, the document needs to describe what the criteria are for a
successful experiment.
    Implementations (RFC7942?)?
    two interop implementations?
    hardware implementation?
    "deployment experience" (to cite the charter text)?
    impact analysis?
    something else?

The ideal BIER document for this explanation is this architecture doc.
A reference to the charter Item 9 would be a good start.

Examples:
https://tools.ietf.org/html/rfc7360#section-1.3
https://tools.ietf.org/html/rfc7499#section-2

2. operations and management section
I'm sure there are such considerations:
    - configuration
    - sub-domain management
    - BFR-id management
    - adding new BFIR/BFER device to the domain
    - logging
    - troubleshooting
    - OAM
    - etc.

There are also two other management documents that should be referenced:
chartered item 6 and 7. There are some management sentences, from time to time,
in the doc. Ex: avoiding a second copy is an important from an operational
point of view

   It is generally advantageous to assign the BFR-ids of a given sub-
   domain so that as many BFERs as possible can be represented in a
   single bit string.

   ...

   In order to minimize the number of copies that must be made of a
   given multicast packet, it is RECOMMENDED that the BFR-ids be
   assigned "densely" (see Section 2) from the numbering space...

    Btw, I guess you meant: assigned densely per subdomain, right?

What this "operations and management section" should contain is the points that
operators, who will deploy this technology, have to pay attention to. An
architecture document is typically the first document people will read. RFC
5706 appendix A provide typical questions from an OPS point of view. I
understand that this is an experiment and you might not have all the answers at
this point in time.

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

-   Each BFR MUST be assigned a single "BFR-Prefix" for each sub-domain
   to which it belongs.  A BFR's BFR-Prefix MUST be an IP address
   (either IPv4 or IPv6) of the BFR.  It is RECOMMENDED that the
   BFR-prefix be a loopback address of the BFR.

Just one observation. Was thinking, so it's like an (OSPF) routerId, except
that it's called a prefix. Then I understood, reading further. It's not called
a routerId because this address/prefix must be routable

- Was wondering. Is this mechanism only for multicast packets? What about
anycast/unicast? End of section 4 you have an example about MVPN over
ingress/egress PEs. Some multicast packets would take BIER encap, while others
packets would take a different encap From a troubleshooting point of view, does
it make sense (is it even allowed) to send non multicast traffic over BIER.

Victor Kuarsing performed the OPS-DIR review, copied below. Discussion is
ongoing.

First, there were no textual changes recommended as part of this
review.  The document seems to be well written and had undergone
previous review/updates.  Given the nature of this document, there are
limited operational specific points made as part of this review
however three points are noted for follow-up with the actors.

(1). Security Considerations

It was not 100% clear to the reviewer (me) if the use case of how the
BIER architecture (or guidance for future implementation) may avoid
certain DoS like activity from illegitimate neighbors (BFR-NBRs).  I
may have missed specific text which addresses the point made herein
(if so, please disregard my first point and please make reference
where it is addressed).  The concern is if a packet is introduced into
the system by a host (compromised perhaps) which fabricates packets
(may or may not have valid payload inside the BIER encapsulation) that
attempts to starve resources in the system.  One way of doing this
(which may require control plane access - maybe) would be to
set/create packets which forces additional replication at BFRs (i.e.
set a single  - or all bits -  for all SIs).  This would then create
the maximum amount of replication within the system.  Perhaps this use
case is addressed as noted.

I was no able to find specific operations/functions which scrutinized
incoming packets and/or guard for bad NBRs.  Could this be an issue
from the authors standpoint?  In more traditional networks, there are
methods operators use to ensure that illegitimate traffic is not
introduced into the system.  I wanted to make sure there was thoughts
on how to do this with BIER.

(2). SPF assumed.

I agree most places where the BIER architecture would likely live (say
in Enterprises and SP networks) the network would operate a standard
IGP.  However, in some use cases, like modern DCs, some are designing
fabrics which don’t use a traditional IGP.  These networks use all BGP
(eBGP) with full sets of neighbor relationships.  This helps reduce
the amount of running protocols within the underlay, but may (or may
not) cause issues with BIER in relation distribution of system
information.  Do the authors consider this use case one that can be
address with BIER as it’s currently outlined, or would additional
considerations be needed?

I reviewed the “draft-ietf-bier-use-cases” document and did not see
text that specifically help or hinder the operational mode I described
above.

(3) Broadcast Video Operation. (more of a question then a point of note)

I did noticed in the use case document (as noted above in point 2),
that considers more traditional broadcast video networks was
described.  So my question is, would an operational model which
required two simultaneous M/C flows from separate sources (normally
two packagers/encryptors etc) be supported by the BIER architecture as
described?  My best estimate would be that the operator would use two
sub-domains that would allow each BFER to potentially get two of each
packet (which are sourced by two different injection points / BIFRs).
This mode of operation is common in some places to allow the M/C
broadcast feed to be “pinned” to the egress router/device to allow for
fast switchover in case of network failure (where normal network level
detection and re-routing is not sufficient).

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 6 Jul 2017 10:45:57 -0400

The status of the document is a political issue that should not impact 
the content of the document.

> The ideal BIER document for this explanation is this architecture doc.

The above is all entirely outside the scope of this document.

>      - adding new BFIR/BFER device to the domain

I am unaware of any RFC that requires such a section to be included in a 
document like this.  These topics are outside the scope of this document.

> chartered item 6 and 7.

These are outside the scope of the architecture document.

> There are some management sentences, from time to time,

Correct, I'll add some clarifying text.

> understand that this is an experiment and you might not have all the answers at

This would be the topic for a different document.

> anycast/unicast?

You could use BIER to do a unicast, by setting only one bit in the 
BitString.  However, there are other more efficient encapsulations for 
unicast tunnels.

> End of section 4 you have an example about MVPN over
> packets would take a different encap

I'm not sure what you're referring to.

>  From a troubleshooting point of view, does

Attached are my reply to Victor and his response.  I did make a few 
changes in response to his comments, but the latest revision has not 
been posted yet.

> detection and re-routing is not sufficient).

Subject: Re: Ops-Dir Review of Draft-ietf-bier-architecture-07
From: Eric C Rosen <[email-masked]>
To: Victor Kuarsingh <[email-masked]>, Warren Kumari <[email-masked]>, Benoit Claise <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Alia Atlas <[email-masked]>
Date: Fri, 30 Jun 2017 11:12:53 -0400

Victor, thanks for taking the time to do this review.

> case is addressed as noted.

The security considerations do say that every BFR must be provisioned ot 
know which of its interfaces lead to a BIER domain and which do not.   I 
can say a little more explicitly that one shouldn't accept 
BIER-encapsulated packets from outside the domain. That addresses one 
sort of threat.

The security consideratons do point out that modification of the BIER 
encapsulation through error or malfeasance cause misdelivery. I can add 
that certain sorts of modifications, such as setting all the bits in the 
BitString, are potential vectors for DoS attacks.

It is probably worth pointing out as well that when the initial BIER 
encapsulation is imposed, certain errors, such as setting all the bits 
in the BitString, can result in DoS attacks (intended or unintended).

> I was not able to find specific operations/functions which scrutinized

The only check like this is at the boundaries of a BIER domain, where 
BIER-encapsulated packets are not accepted from interfaces that lead 
outside the domain.  I'm not sure what else one would do.

> considerations be needed?

With regard to the control plane, there is a draft that explains how to 
use BGP to distribute the same information (labels, BFR-ids, 
BFR-prefixes) that is distributed via OSPF or ISIS extensions.  I don't 
think anything explicit needs to be said in the architecture; the 
architecture uses IGP-based distribution as an example, but I don't 
think there is any text there that requires the control plane to be 
IGP-based.

In the data plane, the document does focus on the case where the 
"routing underlay" is IGP-based (link-state-based), but I think it is 
clear that all the routing underlay really needs to provide is the 
mapping from BFR-id to BFR-prefix to set of next hops.  Some of the 
techniques discussed for tunneling around non-BFR neighbors or for 
routing around failed neighbors do assume link state routing, but these 
techniques are optional.

So to answer your question, I don't think anything additional needs to 
be added to the architecture to accommodate non-traditional routing 
underlays.  I'll do another read-through to make sure it's clear that 
OSPF/IS-IS are not portrayed as strict requirements.

> text that specifically help or hinder the operational mode I described

I won't comment on the "use cases" document.

> detection and re-routing is not sufficient).

If a flow enters the BIER domain at two different ingress points, and 
each ingress point knows the egress points for that flow, there is 
nothing to stop both ingress points from using BIER to multicast the 
flow to the same set of egress points.  The egress node would have to be 
able to tell when it was receiving two copies of the flow, so that it 
could choose one copy as the one to forward further.  The BIER 
encapsulations (not described in the architecture) do carry the BFIR-id 
in the BIER header, which makes this possible.  If the flow from one 
ingress node fails, the egress node could switch to the other flow.  How 
it determines when to do this is outside the scope of BIER, of course.

If it is desired that the two copies of a given flow travel through the 
network along disjoint paths, one would have to set up two different 
"routing underlays", each disjoint from the other.  This would require 
two sub-domains.  This really becomes a network design issue, but could 
certainly be handled by BIER.

So to answer your question, I believe the architecture handles these 
cases, but BIER is only a piece of the solution.

Subject: Re: Ops-Dir Review of Draft-ietf-bier-architecture-07
From: Victor Kuarsingh <[email-masked]>
To: Eric C Rosen <[email-masked]>
Cc: Warren Kumari <[email-masked]>, Benoit Claise <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Alia Atlas <[email-masked]>
Date: Fri, 30 Jun 2017 11:22:16 -0400

On Fri, Jun 30, 2017 at 11:12 AM, Eric C Rosen <[email-masked]> wrote:
> Victor, thanks for taking the time to do this review.
>
> The security considerations do say that every BFR must be provisioned ot
> know which of its interfaces lead to a BIER domain and which do not.   I can
> say a little more explicitly that one shouldn't accept BIER-encapsulated
> packets from outside the domain. That addresses one sort of threat.
>
> The security consideratons do point out that modification of the BIER
> encapsulation through error or malfeasance cause misdelivery. I can add that
> certain sorts of modifications, such as setting all the bits in the
> BitString, are potential vectors for DoS attacks.
>
> It is probably worth pointing out as well that when the initial BIER
> encapsulation is imposed, certain errors, such as setting all the bits in
> the BitString, can result in DoS attacks (intended or unintended).

Sure, I think that helps.

>
>> I was not able to find specific operations/functions which scrutinized
> The only check like this is at the boundaries of a BIER domain, where
> BIER-encapsulated packets are not accepted from interfaces that lead outside
> the domain.  I'm not sure what else one would do.
>
>>
>>
>> (2). SPF assumed.
>>
>>
> With regard to the control plane, there is a draft that explains how to use
> BGP to distribute the same information (labels, BFR-ids, BFR-prefixes) that
> is distributed via OSPF or ISIS extensions.  I don't think anything explicit
> needs to be said in the architecture; the architecture uses IGP-based
> distribution as an example, but I don't think there is any text there that
> requires the control plane to be IGP-based.
>
> In the data plane, the document does focus on the case where the "routing
> underlay" is IGP-based (link-state-based), but I think it is clear that all
> the routing underlay really needs to provide is the mapping from BFR-id to
> BFR-prefix to set of next hops.  Some of the techniques discussed for
> tunneling around non-BFR neighbors or for routing around failed neighbors do
> assume link state routing, but these techniques are optional.
>
> So to answer your question, I don't think anything additional needs to be
> added to the architecture to accommodate non-traditional routing underlays.
> I'll do another read-through to make sure it's clear that OSPF/IS-IS are not
> portrayed as strict requirements.

Sure, that makes sense.  I was just my read.  Again, not a big item.
But thanks for double checking.

> I won't comment on the "use cases" document.
>
>>
>>
> If a flow enters the BIER domain at two different ingress points, and each
> ingress point knows the egress points for that flow, there is nothing to
> stop both ingress points from using BIER to multicast the flow to the same
> set of egress points.  The egress node would have to be able to tell when it
> was receiving two copies of the flow, so that it could choose one copy as
> the one to forward further.  The BIER encapsulations (not described in the
> architecture) do carry the BFIR-id in the BIER header, which makes this
> possible.  If the flow from one ingress node fails, the egress node could
> switch to the other flow.  How it determines when to do this is outside the
> scope of BIER, of course.
>
> If it is desired that the two copies of a given flow travel through the
> network along disjoint paths, one would have to set up two different
> "routing underlays", each disjoint from the other.  This would require two
> sub-domains.  This really becomes a network design issue, but could
> certainly be handled by BIER.
>
> So to answer your question, I believe the architecture handles these cases,
> but BIER is only a piece of the solution.

Fair.  Again, no action was necessarily required per say.  Just wanted
to validate.

regards,

Victor K

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 6 Jul 2017 11:43:37 -0700

Inline:

On Thu, Jul 6, 2017 at 7:45 AM, Eric C Rosen <[email-masked]> wrote:

> The status of the document is a political issue that should not impact the
> content of the document.

I would say process over political. But I agree it should have no bearing
on the content of the document.

> The above is all entirely outside the scope of this document.

Agree. This is in the charter. If/when the the case is made to transition
all of the BIER work to the standards track the documents' contents should
not change.

> document like this.  These topics are outside the scope of this document.

 Agree. There are other documents in the WG to address some of the above
concerns. None of these seem appropriate for an architecture document.

> These are outside the scope of the architecture document.

Agree. The mgmt docs must refer to the arch not, but I don't see why the
other way around is required.

> This would be the topic for a different document.

Agree. There is other work in the WG to address this. It would seem out of
scope for an arch doc.

Greg

> changes in response to his comments, but the latest revision has not been
> posted yet.
>
>
>
> ---------- Forwarded message ----------
> To: Victor Kuarsingh <[email-masked]>, Warren Kumari <[email-masked]>,
> Benoit Claise <[email-masked]>, [email-masked],
> [email-masked], [email-masked],
> [email-masked], Alia Atlas <[email-masked]>
> Cc:
> Bcc:
> BIER-encapsulated packets from outside the domain. That addresses one sort
> of threat.
>
> use BGP to distribute the same information (labels, BFR-ids, BFR-prefixes)
> that is distributed via OSPF or ISIS extensions.  I don't think anything
> explicit needs to be said in the architecture; the architecture uses
> IGP-based distribution as an example, but I don't think there is any text
> there that requires the control plane to be IGP-based.
>
> tunneling around non-BFR neighbors or for routing around failed neighbors
> do assume link state routing, but these techniques are optional.
>
> added to the architecture to accommodate non-traditional routing
> set of egress points.  The egress node would have to be able to tell when
> it was receiving two copies of the flow, so that it could choose one copy
> as the one to forward further.  The BIER encapsulations (not described in
> the architecture) do carry the BFIR-id in the BIER header, which makes this
> ---------- Forwarded message ----------
> Cc: Warren Kumari <[email-masked]>, Benoit Claise <[email-masked]>,
> [email-masked], [email-masked],
> [email-masked], [email-masked], Alia Atlas <[email-masked]>
> Bcc:
> can
> that
> outside
> use
> each
> two
> cases,

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 6 Jul 2017 15:30:09 -0700

inline comments as chair helping out the shepherd and editor ... Cut out
tons text to abbreviate this (by now) longish text ...

> on the content of the document.

Yes, this is a process/track issue and I would not consider an architecture
document well-crafted if its text had to argue the document itself onto a
track ;-) The work either stands in its quality/adoption to present a
standards track or doesn't and then such track is meaningless. The bar set
to adopt this work on IETF standard track by Alia has been arguably very
high but the current agreement has been struck with the chairs based on her
most excellent argument that we're touching the "hourglass" and with that
more rigorous standards apply ... IMO we are all better off for it longer
term.

> all of the BIER work to the standards track the documents' contents should

Yes, the standard of adoption into standards track is entirely a charter
issue IMO and this can be formulated along e.g. lines suggested by Benoit
within the charter.

> concerns. None of these seem appropriate for an architecture document.

I am agnostic whether architecture document shall REFER to e.g. OAM
document. However, folding those documents/considerations into a detailed
architecture document  (like this one is) will make it unwieldy and loose
the forest for the trees. If anything, this architecture says too much
about things like operational details (since we want to leave the mechanism
applied @ the discretion of particular implementation, BIER can be IGP
signalled, statically configured, controller provisioned and so on without
breaking the architecture. Same applies for BFR-id). Unless specific
standards RFC dictates that those considerations must be included in a
detailed fashion in this architecture document I would also argue that they
do not belong here.

> other way around is required.

Like I said, I'm agnostic.

> Agree. There is other work in the WG to address this. It would seem out of
Agree, I see how an RFC5706 structured document for BIER could make sense
but it's outside the scope of the architecture doc. If anything, the
architecture document currently says TOO much about it in its scope.

>> BitString.  However, there are other more efficient encapsulations for
In certain scenarios people will in fact use the one-bit-equal-unicast and
pay  the encapsulation price. In others, they will follow unicast
paths/tunnels. I was told, the problem exists today already with
traditional multicast for certain applications. The architecture does NOT
prohibit a one-bit-is-unicast (as traditional multicast doesn't preclude it
from being used between a single sender-receiver pair) use and that's all
is required from the architecture.

>> To: Victor Kuarsingh <[email-masked]>, Warren Kumari <
>> [email-masked]>, Benoit Claise <[email-masked]>, [email-masked],
>> in
Actually, quite interesting observations. We could specify procedures to
deal e.g.
with packets sources from unknown BFR-ids and so on but IMO that would
quickly
overwhelm the security section in an architecture document and ultimately
may talk
about lots of things that will be never of interest. We should acknowledge
the attack
vectors and if necessary, those shall be adressed by a detailed security
draft for BIER
I think ...

>> Fair.  Again, no action was necessarily required per say.  Just wanted
BIER allows for many protection/replication schemes. We have IGP FRR built
in, we have subdomains
including IGP MT mapping and we have provisions for the future to allow
IGPs e.g. to
compute different trees (or those could be provisioned/signalled by other
mechanisms).
It is kind of implied in the architecture/current signalling and again,
detailed considerations,
if anyone so inclined, may merit a detailed separate document based on
experience in
the deployments

thanks

-- tony