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

[Tony Przygienda <[e-mail]>]

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

On Thu, Jul 6, 2017 at 11:43 AM, Greg Shepherd <[e-mail]> wrote:

> Inline:
>
> On Thu, Jul 6, 2017 at 7:45 AM, Eric C Rosen <[e-mail]> wrote:
>
>> On 7/6/2017 9:13 AM, Benoit Claise wrote:
>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> 1. I want to come back to the experimental status.
>>>
>>
>> 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.
>

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.


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

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.


>
>
>>
>> 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.
>>>
>>
>> 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.
>
>
>  Agree. There are other documents in the WG to address some of the above
> 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.


>
> There are also two other management documents that should be referenced:
>>> chartered item 6 and 7.
>>>
>>
>> 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.
>

Like I said, I'm agnostic.


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


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


>>
>> ---------- Forwarded message ----------
>> From: Eric C Rosen <[e-mail]>
>> To: Victor Kuarsingh <[e-mail]>, Warren Kumari <
>> [e-mail]>, Benoit Claise <[e-mail]>, [e-mail],
>> [e-mail], [e-mail],
>> [e-mail], Alia Atlas <[e-mail]>
>> Cc:
>> Bcc:
>> Date: Fri, 30 Jun 2017 11:12:53 -0400
>> Subject: Re: Ops-Dir Review of Draft-ietf-bier-architecture-07
>> Victor, thanks for taking the time to do this review.
>>
>> (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.
>>>
>>
>> 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
>>> 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.
>>>
>>
>> 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.
>>>
>>>
>>> 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?
>>>
>>
>> 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.
>>
>> 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.
>>>
>>
>> ...
>>
>>
>> ---------- Forwarded message ----------
>> From: Victor Kuarsingh <[e-mail]>
>> To: Eric C Rosen <[e-mail]>
>> Cc: Warren Kumari <[e-mail]>, Benoit Claise <[e-mail]>,
>> [e-mail], [e-mail],
>> [e-mail], [e-mail], Alia Atlas <[e-mail]>
>> Bcc:
>> Date: Fri, 30 Jun 2017 11:22:16 -0400
>> Subject: Re: Ops-Dir Review of Draft-ietf-bier-architecture-07
>> On Fri, Jun 30, 2017 at 11:12 AM, Eric C Rosen <[e-mail]>
>> wrote:
>> > Victor, thanks for taking the time to do this review.
>> >
>> >> (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.
>> >
>> >
>> > 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.
>>
>
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 ...


>>  ...
>> >
>> >> 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.
>> >
>> >
>> > I won't comment on the "use cases" document.
>> >
>> >>
>> >>
>> >> (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).
>> >
>> >
>> > 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.
>>
>
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