Re: [Bier] New Version Notification for draft-pfister-bier-over-ipv6-00.txt

[Pierre Pfister <[e-mail]>]

> Le 15 sept. 2016 à 17:16, Eric C Rosen <[e-mail]> a écrit :
> 
> 
>>> It is worth emphasizing that, unlike other proposed encapsulations, this encapsulation only supports BitStrings of length 64.  Well, 128-p-i.  I guess one could use a /40 prefix and a single SI to get a BitStringLength of 88 if one doesn't need any more than 88 BFR-ids in the domain.  It still seems rather restrictive when compared to the other encapsulations that have been proposed.
>> IMHO, what really matters is the ratio of packets sent over the number of reached destinations. From that regard, a case with 1024 long BitString and 1M destinations with random access will not be very efficient. In some cases, 64 destinations are far enough. As you noted, we already have an encapsulation which can handle longer BitString, so I guess we'll have to evaluate whether other use cases, 1., need more bits, 2., can use the existing MPLS encap.
> 
> You should point out then that your encapsulation does not support the full functionality of the BIER architecture as specified by the WG, but only an arbitrarily chosen subset of it.

You may see an arbitrarily chosen subset of features where others may see applicability to different use-cases such as enterprise or home networks, and IP networks rather than MPLS networks. 
The purpose of a new encapsulation is not to provide a second solution addressing the exact same issue and use-cases but rather see the areas where the first encap is not applicable.

The BIER architecture document is a draft. The working group may realize than it does not fully handle certain use-case yet.

> 
>>> I don't see how the sub-domain is identified in this encapsulation.
>> It is not addressed by the document indeed. Just for the sake of making a short document.
>> 
> 
> This is another way in which your proposal fails to support the BIER architecture.

No. 
This is a way to say that the proposal is a first iteration which will be improved and include sub-domains in further iterations if people think it is necessary.

You removed part of my answer too: "I guess we could use the IPv6 prefix for that as well.".
Any useful technical comments on this proposal ?

> 
>>> The draft says: "It makes use of a typical IP longest match in order to decide whether a packet is a BIER packet or not, which means hardware and software existing solutions may be used for that purpose."  But existing/deployed hardware and software solutions cannot do the BIER forwarding!  So I don't see what advantage is being claimed here.  Or is this just a way of saying "at least we don't use IPv6 extension headers" ;-)
>> It is a way to say "Hey, you will be able to reuse bits of hardware and code rather than restart everything from scratch".
> 
> I don't think there is any proposed encapsulation whose implementation cannot make use of some existing logic.  So this "advantage" does not distinguish your proposal from any other.

Please read carefully. I am not saying that the proposal "can make use of some existing logic". I am saying it makes use of longest match on the destination address in order to determine whether the packet is a BIER packet, the Set ID, and possibly the sub-domain.
Longest match prefix is not just a random piece of existing logic. It is widely optimized on both hardware and software.
In addition, it means that packet classification can be achieved by the use of the already existing routing operation. Which will simplify development and deployment.
Hence, this is an advantage.

> 
> If your encapsulation requires that the forwarders look at layer 4, I'd say that is a pretty big disadvantage.
> 
> I don't think a BIER encapsulation should require that UDP be modified.

Which means we shouldn't use encapsulation within UDP either.
But you also mention that we shouldn't use IPv6 Extension Headers.
So this leaves us only encapsulation over Ethernet.
Can you elaborate if you think this is a better alternative ?

> 
>> 
>>> The draft says: "It is possible to configure a host with an address which corresponds to a BIER address with a single bit set.  From the host perspective, such address is not different from a regular IPv6 address."  Well, what will then stop the host from using that address as an IPv6 source address?
>> It is a feature, not a bug. A BIER IPv6 address with a single bit set is a valid unicast address.
> 
> No it isn't.  See my comments on using a "BIER IPv6 address" in the source address field.

See my answer.

> 
>>> Packets carrying such an IPv6 source address may get dropped for using a prefix that has not been delegated to the host's subnet.
>>> 
>>> If a host uses a "BIER address" as its source address in a given packet, and the packet doesn't get dropped, the packet may elicit responses that put the BIER address in their destination address fields.  This seems like a security issue, as it creates an attack vector that can create 64 responses to a single probe.
>> Are you talking about BCP38 ? Ingress filtering means that a host cannot send a packet with any source address. Of course, if the host is assigned a BIER address, adjacent routers will have to be configured to not drop the packets that are originated with this source address.
> 
> The need to configure adjacent routers this way doesn't seem like much of an advantage.

Yes. Routers that are adjacent to hosts will have to run or relay DHCPv6.
Which is pretty much necessary when you deal with hosts.

> 
>> It doesn't mean that you allow the host to use any BIER address though. The first-hop router (or any other routers) can be configured to do a source address filtering (just like BCP 38) to make sure that the source address is not a BIER address with more than one bit set.
> 
> More special case configuration needed in order to use this encapsulation.

Just DHCPv6.

>>> The draft suggests that the BIER prefix can be treated by BFRs outside a given domain as a routable unicast prefix, presumably leading towards one or more BFRs that serve as border routers for a given BIER domain.  (At one point, the draft even says that BIER packets are IPv6 unicast packets, which seems a bit misleading. ;-)) That's interesting, but putting this feature to use requires one to work out quite a few details that are not mentioned.  And I don't think it will work for non-BFRs within the BIER domain.  To pass BIER packet through non-BFRs within the destination BIER domain, one still needs additional encapsulation.
>> The document does not claim that you can have non-BFR routers within the BIER domain.
> 
> That feature is supported by the architecture, so I guess this is another feature of the architecture that is not supported by your proposed encapsulation.

Are you referring to this sentence ?
"BIER would then have to be run in a
   sub-domain that is bound to this topology.  If unicast tunnels are
   used to bypass non-BFRs, either the tunnels have to be restricted to
   this topology, or the tunnel endpoints have to be BFRs that do not
   have any non-BIER-capable interfaces."

It seemed pretty obvious to me that an IP based solution could use tunneling to solve this issue.

> 
>> It just claims that you can use regular unicast forwarding between the source and the BFIR.
>> What sort of details do you think are not mentioned ?
> 
> The description of the procedures that cause the FIBs to be set up appropriately in all the routers outside the BIER domain.

From the draft:
If the BIER IPv6
      Prefix is a globally unique IPv6 prefix, reachable from outside
      the BIER domain, it is possible to send a packet from outside the
      BIER domain to multiple destination within the BIER domain.

I don't think it is necessary to describe in more details the many ways a unicast prefix can be made reachable from
a private or public part of the internet.

> 
> Also, don't forget to consider the case of hosts that are multi-homed to several BIER domains.

I don't think bier WG is exactly chartered to solve host multi-homing. ;-)

> 
> And the case of a host that is not directly connected to its BIER domain.  If the BIER prefix leads a packet (via unicast forwarding) from the host to a distant BFIR, how will that same prefix lead a packet (via unicast forwarding) from the distant BIER domain to the host?

I don't claim it does.

> 
>> You can ! You can ! :-)
>> "Configured" means, "as far as the BIER Layer is concerned", whether this comes from an educated system administrator, a running process, or a monkey, I couldn't care less.
>> I will clarify in the next iteration.
> You have a companion draft describing the ISIS/OSPF/BGP extensions for doing the necessary signaling?

I don't think it should be any different from the documents related to the other encaps.
At least, I think those extensions should be agnostic.
If you see reasons or cases where they are not, I would be interested to know more.

>>> It is not clear from the draft whether the value of i (number of bits in the SI field) and the set of BFR-ids is specific to a given prefix, or whether it is the same for all prefixes.  (Or for all prefixes corresponding to a given domain.  Or perhaps sub-domain?)
>> Well. This clearly is the kind of things that can be discussed, right ?
>> When I first thought about this approach, I made an experimental implementation for Linux. I ended up not caring about these. I didn't even implemented the concept of S.I., but rather decided that every BIER prefix would use a different 'bit index to next-hop' mapping table. So, I would say that the set of BRF-ids is specific to a given prefix. I would even say we can remove the concept of domain and S.I. But that is the sort of things that I would need BIER experts to discuss with.
> It seems like your "experimental implementation" does not comply with the BIER architecture.

It does. Because it implements the required features and behaves in a way that is in agreement with the BIER architecture draft.
I am just giving implementation feedback stating that, in this particular case, the implementation does not need to explicitly consider the notion of S.I. in order to be compliant.

> 
>>> Another "advantage" is that the proposal "may be used for transporting IP multicast packets, but also for sending IP payloads directly to multiple destinations".  Does this "advantage" distinguish it from some other proposal?  I'd have thought that any multicast encapsulation can cause any packet to sent to multiple destinations.
>> Only if the destination implements BIER. In this proposal, the destination does not need to decap anything. It directly receives a unicast packet.
> 
> In most BIER encapsulation proposals, the decapsulation is done by the BFER, not by the destination host.

Nothing prevents a BFER to be the destination of a packet though.
So I don't exactly see your point.

> 
>> 
>>> Of course, maybe the first question is whether we really have a need for an encapsulation that is IPv6-specific.  The draft doesn't actually seem to address this question.
>>> 
>> Do you think we shouldn't have another encap. ?
> 
> It's true that I don't see a need for another encapsulation.  But ...
> 
>> Or are you saying we should have a different encap ?
>> 
> But if we do have another encapsulation, it shouldn't be IPv6-specific, and it shouldn't require hop-by-hop modification of the IP destination address field, and it shouldn't require the BFRs to inspect layer 4, and it shouldn't require changes to layer 4, and

> it shouldn't allow a multicast address to be put in the IP source address field
Where did you see this ?!

As stated in a previous comment. You say no Layer 4, no extension headers, no IP header. 
This just leaves us to Ethernet layer.

Which one is more specific ? Ethernet or IPv6 ?

> , and it shouldn't assume that bits never get set incorrectly,

Can I assume that the BIER BitString and the IP version number are set correctly ?

> and it shouldn't require changes in source address filtering procedures.  

It doesn't.