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

[Eric C Rosen <[e-mail]>]

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

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

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

> But you have a point. I could add "it doesn't use an IPv6 extension header" too.

Well, there's lots of things it doesn't do.  This particular point is 
only interesting if you are comparing your proposal to another proposal 
that does use IPv6 extension headers.

Of course, if there were such a proposal, it would probably claim as an 
advantage "it doesn't modify the destination address field of a packet 
while the packet is in flight", thereby avoiding a whole set of 
unintended side-effects.

(I do think it is good to avoid IPv6 extension headers, but none of the 
encapsulations that have been proposed to the WG use IPv6 extension 
headers, so this doesn't seem like much of an issue.)

> I do not suggest to overwrite the destination address sent by the source. If you don't want to restore it later, it is possible. But this is obviously a bad idea if you need to restore it.
> I was rather saying that the source can directly originate a packet which destination is a BIER IPv6 address.

There is nothing to prevent a source from originating a packet with any 
kind of encapsulation whatsoever.

> Or if the source sends an IPv6 multicast packets that you need to be sent through the BIER domain, you can encapsulate it inside the IPv6 BIER packet.

Same as any other encapsulation.

>
>> If an enduser's UDP packet is carried as the payload of an IPv6 BIER packet, and the UDP packet has non-zero checksum, then, as the draft says, "the UDP checksum must be recomputed when the BIER bits are changed."  So the BIER forwarding plane now has a new function -- it has to look to see what the payload is, and whether the the payload has a checksum that needs to be adjusted.  Does that sound like a good idea?
> I see at least two possibilities here:
> - Update checksum at every BitString change. This is actually not so expensive given that the IP checksum is linear (i.e. support updates). Obviously this requires looking at layer 4.

If your encapsulation requires that the forwarders look at layer 4, I'd 
say that is a pretty big disadvantage.

> - Have a convention that the packet is checksumed with BitString set to all-zeroes.

I don't think a BIER encapsulation should require that UDP be modified.

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

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

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

>
>> Hopefully hosts will not treat the BIER prefix as a delegated prefix that they can use to compute their own "privacy addresses"; if any of those computed addresses make it to the source address field of an IPv6 packet, and the packet does not get dropped, chaos could ensue.
> Why would you advertise an IPv6 BIER prefix with the M bit set to 0 (enabling SLAAC) in your RAs ?! I mean, there is no way SLAAC could be used for that purpose. You would use DHCPv6 (or some other equivalent) for address configuration anyway.

Ahh, the old "it will never happen" defense.  After all, bits never get 
set incorrectly, or in a way not anticipated by the authors of a 
specification ;-)

Actually, every network disaster is preceded by a developer saying "that 
will never happen" because "no one would ever do that".
>> 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.

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

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

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?

> 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?
>> 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.
>> Section 6 gives the "advantages" of the proposal, but it is not clear what the proposal is being compared to.  For instance, one of the advantages is claimed to be that the proposal doesn't use IPv6 extension headers.  Is the proposal being compared to another proposal that does use IPv6 extension headers?  If so, where is that proposal described?  (None of the proposals I've seen so far use IPv6 extension headers.)
> Okay. What encap should I compare it to ?

There's not much point comparing it to a strawman that has neither been 
proposed to the WG in another draft nor described in this draft.

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

>
>> 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, and it 
shouldn't assume that bits never get set incorrectly, and it shouldn't 
require changes in source address filtering procedures.  In addition, it 
should be possible to use it to support the entire BIER architecture, 
including those features that didn't make it into your experimental 
Linux implementation.