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

[Pierre Pfister <[e-mail]>]

Hello Eric,

Thanks for those comments.

You found a few quite interesting ambiguities that I will clarify in the next iteration.
But the good news is that those nits did not led you to not understand something.

See the rest inlined.

Cheers,

- Pierre


> Le 12 sept. 2016 à 21:26, Eric C Rosen <[e-mail]> a écrit :
> 
> Here are some comments and questions on draft-pfister-bier-over-ipv6.
> 
> Despite the title and abstract, the draft has nothing to do with the routing underlay.  It's about procedures for the BIER layer. Section 4 is about BIER layer functions at the BFIR, and section 5 is about BIER layer functions at other BFRs.

Indeed. This is all about BIER Layer. It will get fixed.

> 
> The draft says in some places that BIER packets are "regular" IPv6 packets, but it says in other places that they are not "regular" IPv6 packets.  "Regular" is never defined, but it should be used consistently.

The point is to explain that such packets look like IPv6 packets, but are not to routers that have been configured to perform BIER operations on the BIER packet (And it knows that by matching the destination address to one of the BIER prefixes).
I will try to find a better wording than 'regular'. 

> 
> The term "BIER bits" occurs in contexts where it seems to mean "BIER BitString".  (The bits representing the SI are also "BIER bits", but don't seem to be included as "BIER bits" in this draft.)

I looked at the architecture draft but didn't find any place where SI value is referred as 'bits'.
If your point is that 'BIER bits' is not defined, I can live with it and change it to "BIER BitString" in the document. For the sake of clarity.

> 
> The draft says that the high-order 64 ("p+i") bits of the IPv6 destination address field are "left untouched".  But it proposes using the high-order 56 ("p") bits to hold a special prefix meaning "BIER", and it proposes using the next 8 ("i") bits to represent the SI.  That doesn't seem like leaving the high-order bits untouched. But perhaps "untouched" means "the bits are not modified by the forwarding plane" rather than "the functionality of the bits is not modified".

They are left 'untouched' as in 'not modified after initialization'. Of course the bit is touched by the sender of the packet. But if you find it unclear, I will also try to clarify.

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

> 
> 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.
I guess we could use the IPv6 prefix for that as well.

> 
> 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".
But you have a point. I could add "it doesn't use an IPv6 extension header" too.

> 
> The draft seems to suggest that if the payload is an IPv6 packet, one can use BIER to multicast it without encapsulating the payload at all.  Rather, all one has to do is overwrite the enduser's destination address with an "address" value that contains the BIER prefix, SI, and 64-bit BitString.  Do I understand that correctly? If so, this seems to create a number of issues that are not discussed.
> 
> Suppose, for example, that the original payload has an IPv6 multicast address in its destination address field.  If that is overwritten, then when the packet reaches a BFER, the BFER will have no way of knowing what the original destination address was.  But the multicast flow layer needs that information in order to further process the packet!
> 

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

> 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.
- Have a convention that the packet is checksumed with BitString set to all-zeroes.

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

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

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

> 
> 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. 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 ? It seems to me that a BIER packet could be very-well routed as unicast based on the destination BIER prefix up to the BIER domain.

> 
> The draft talks about "configuring" a BIER router with the rules needed to interpret a given IPv6 destination address field.  Does this mean that IGP/BGP extensions for signaling BFR-ids and other BFR parameters will not be used?  Why?  Or is it allowable for these parameters to be signaled as well as configured?  And if we are going to talk about inter-domain BIER, how is the inter-domain signaling done?

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.

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

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

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

> 
> 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. ?
Or are you saying we should have a different encap ?