Re: [Bier] comments for draft-xie-bier-ipv6-encapsulation

[Toerless Eckert <[e-mail]>]

Jingrong, *:

Some higher level Q)uestions P)oints hopefully we can circle in on the probably
most important issues for the details before getting back to my
nitpicking on details.

Q1: Why is https://tools.ietf.org/html/draft-xie-bier-ipv6-mvpn-02 expired
and not even referenced in draft-xie-bier-ipv6-encapsulation ?

If i wanted to understand why the encap does the BFIR-to-BFER IPv6
encap with option header, then the reason really is to enable 'MVPN'
over BIER, right ? So one would like to know where that is specified,
which seems to be that mvpn draft of yours, right ? Aka: should be
refreshed and referenced ?

Q2: I am totally not on top of BESS, but it seems thats where the SRv6
version of e.g.: MVPN (over MPLS) is defined ? And those solutoins are
called 'overlay' because there are on top of IPv6, but functionally its
mostly equialent to what we've done over MPLS forever without calling
it overlay, right ? (sorry, just trying to unconfuse myself, not really
about your draft, but more the question what makes a soution 'overlay',
and it seems just : replace MPLS with IPv6 and stuff running on top of
it must be named overlay ?).

P3: The ability of the choosen header to pass 6man RFC8200 police
seems quite important. See how long SRH draft was hold up in the discuss.
I am not aware whether there is evidence that any other destination
option today does what the routing header, e.g.: RFC6554/SRH are
doing, keeping the source address while changing the dest address.

If they do not like destination option header, it could become a
routing header. If anyone in 6man has rfc8200 concerns, its always
possible to make this doc an update to rfc8200, which shouldn't be
such a blood bath as for SRv6 given how its about effectively multicast
packets, and there was very little multicast expertise involved
in writing these IPv6 documents.

Aka: present/discuss at 6man WG IMHO if not already done.

P4: Wrt. SRv6: As soon as you embody SRv6 SID semantic into IPv6 addresses, 
i think you are doing SRv6 architecture. Only a minority (40% by a cisco
estimate) of SRv6 use cases ever need SRH, the rest is just
SID semantics and non-LDP routing for simple IPv6 packets.  

P5: Wrt. SIDs: I was mostly worried about manual or SDN controller assignment of the
SIDs (like source addresses in BIERv6), but it seems the appropriate
BGP signaling mechanisms in BESS documents similar to those done in the
past for MVPN with MPLS (in other WGs) would allow for automatic allocation and
signaling. I think some sentences to the point that this is
designed to be easily autoconfiguring the addresses it needs or the
like would help to counter such concerns as i had first reading it.

P6: The main concern by the WG seems to be how simple the lookup can
be made. We already discussed this our last email round:
Ability to do a FIB lookup (because its a BIER SID) that results
in an lookup entry of an unchanged BIER header doing unchanged
BIER operations, followed just by a different adjacency than for
MPLS. In MPLS you would swap the destination label (but keep the),
here you would swap the destination IPv6 address.

Have you tried building a P4 reference implementation ?
Typically, when something is shown to be implementable in P4,
then its harder for higher end NPU vendors to argue their NPU
can not do this efficiently ;-)

Overall, i think it might help to think about summarizing the key
parts of relevance to the WG to decide somewhere up front in the doc:

- Support for L3VPN and 'Internet' multicast services via IPv6 with BIER.
- Single FIB lookup to unchanged BIER header and processing
- Swap MPLS label replaced by swap IPv6 destination addess
- Leverages simple subset of SRv6 architecture for SID addressing,
- No SRH used.

Cheers
    Toerless