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

[Greg Shepherd <[e-mail]>]

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.


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


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

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.


>
> 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?
>>
>
> Correct, I'll add some clarifying text.
>
>
>> 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.

Greg


>
>
>>
>> ----------------------------------------------------------------------
>> 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?
>>
>
> 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
>> ingress/egress PEs. Some multicast packets would take BIER encap, while
>> others
>> packets would take a different encap
>>
>
> I'm not sure what you're referring to.
>
>  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.
>>
>
> 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.
>
>
>
>> 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).
>>
>>
>>
>
>
> ---------- 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.
>>
>
> 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.
>
>
>
>
> ---------- 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.
>
>
> >
> >> 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.
>
> Sure, that makes sense.  I was just my read.  Again, not a big item.
> But thanks for double checking.
>
>
> >
> >> 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.
>
> >
> >
>
>
> regards,
>
> Victor K
>
>