Subject: [Bier] DISCUSS: suggestions/Q for draft-ietf-bier-mpls-encapsulation-02

From: Toerless Eckert <[email-masked]>
Date: Tue, 13 Oct 2015 11:37:34 -0700

Couple of comments/Q:

Q1. draft-xu-bier-encapsulation vs. draft-ietf-bier-mpls-encapsulation

    Was this meant to be for BIER over non-MPLS, is this still pursued ?

C2: draft-ietf-bier-mpls-encapsulation-02

    IMHO, this can perfectly be used to carry BIER over non-MPLS,
    the first four bits even make it compatible with encaps without
    next-proto field that only support IPv4/IPv6.

    All the MPLS header elements are IMHO required for BIER-over-whatever.
    I don't think this header should be reinvented over and over again
    in other drafts. 
    
    If BIER-over-something-else requires ADDITIONAL header elements,
    eg: MT-ID or the like (as suggested by draft-xu), then these could
    go into extension headers. Simple way for extension header:
    Set "Proto" to "extension header N", define that extension header in
    another draft.

C3: The discussion with Caitlin re. BIER in DC brought up IMHO the
    cool thought of running BIER end-to-end into apps.

    Today, the MPLS header only support next-proto for "transport services",
    aka: encap of MPLS, IPv6/IPv6, Ethernet and for OAM. With these
    options, one would need to run eg: UDP/IP/BIER. IMHO, the IP
    header, especially IPv6 is fully redundant wastes 60? bytes and
    creates unnecessary confusion (what addresses to use). The sender/receiver
    IP addresses are simply the BFR-prefixes that are known from routing
    underlay without need to be carried in a packet header (BFIR-ID
    in packet indicates BFIR-prefix).

    Aka:
    a) Allocate one code-point for UDP.
    or:
    b) allocate a code-point for "IP-transport", and put the 8-bit
       ip transport protocol into the reserved field.
    
    If course, this is just a "would be cool to have". If somebody really
    wants to implement end-to-end BIER sockets, he could certainly manage to
    send/receive also a redundant IP header.

Cheers
    Toerless

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 13 Oct 2015 18:53:17 +0000

>        ip transport protocol into the reserved field.

[Tony saiz:] 
Intriguing but flattening layers in networking has its own perils and it's trivial for an application to carry in first byte the protocol-demux (like UDP) so I don't think it's wise to crowd BIER MPLS header with that. Moreover, the advantage of indicating 'IP frame' and then encasing a proper IP UDP frame is that deep inspection remains possible with all kind of funky stuff contrary to every application putting their own internal demux on it. 

One could surely imagine raw-BIER-sockets and then just grabbing a sub-domain per application (which is in fact what is meant by 'service' in the architecture, subdomain is nothing else but  a service-access point delineation in something like CORBA while SI or MPLS labels is simply encapsulation that is stripped before the service-access-point boundary is crossed. I hope I make sense to people not steeped in enterprise architecture patterns).  But a user can think of BIER itself as service and use first bytes of the frame for service-access-point demuxing of course. This will happen in a sense anyway since the subdomain demux is small (1 byte) given the network is aware of it to provide service separation so running each App on its own sub-domain ain't gonna get far, there will be sub-service-access-points (SSAPs)  ;-)  

I didn't even start to think how e.g. mTCP would work with all that.  

-- tony

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 13 Oct 2015 13:00:15 -0700

Thanks, Tony

Inline...

On Tue, Oct 13, 2015 at 06:53:17PM +0000, Antoni Przygienda wrote:
> [Tony saiz:] 
> Intriguing but flattening layers in networking has its own perils

True. The question is really if this would be flattening or
avoiding duplication. I'd argue BIER replaces the network IP
multicast layer when used end-to-end, so it's not flattening
but avoiding duplication.

> and it's trivial for an application to carry in first byte the protocol-demux (like UDP)

Not sure i understand what you mean to imply with that. Rephrase please ?

In both cases (BIER/IP/UDP), (BIER/UDP) there is the UDP header.

An application layer API can not be at the layer of just BIER
or IP (multicast) (with/without BIER underneat), because neither
BIER(MPLS encap), nor IP have an application demultiplexing element.

Eg: Try to figure out how multiple independent apps on the same host
would use BIER (see below for subdomain) Whether we have BIER/IP/UDP
or BIER/UDP doesn't matter. Same issue.

> so I don't think it's wise to crowd BIER MPLS header with that.

The BIER header would not be crowded with UDP or any other transport
layer specifics. I am just arguing that BIER, if it means to replace
IP multicast layer also needs to have the normal next-protocol options
that IP multicast packets have (or for that matter IP unicast).

> Moreover, the advantage of indicating 'IP frame' and then encasing a proper IP UDP frame is that deep inspection remains possible with all kind of funky stuff contrary to every application putting their own internal demux on it. 

In both cases we have a proper UDP packet (UDP + payload).

Keeping a redundant IP header in packets to simplify DPI....
I'd first like to understand a practical use case benefit. I like
inspection/analysis of RTP and SPUD, for IP header i don't know
a need and worry about bringing in downides:

In both the API proposals you and i posted to the list we just
spoke of list of receivers, not of multicast groups (or SSM channels).
We just need to argue whether apps need to know BFR-ids, or just
BFR-prefixes.

I'd hate if we'd force the concept of multicast group addressing
into BIER application services/APIs (unless desirable for some reason)
just because we  need to fill some redundant IP header with some destination
address. And if there is ANYTHING that DPI could get from a redundant
IP header, it's source and destination address. So if we just fill it 
with some useless group address, then that would even further reduce any
DPI benefits of the header.

> One could surely imagine raw-BIER-sockets and then just grabbing a sub-domain per application (which is in fact what is meant by 'service' in the architecture, subdomain is nothing else but  a service-access point delineation in something like CORBA while SI or MPLS labels is simply encapsulation that is stripped before the service-access-point boundary is crossed.

Sure, but an API to raw BIER is not an application layer service but a network
layer API into BIER where you'd have to put a transport (layer) services on top
of it.

> I hope I make sense to people not steeped in enterprise architecture patterns).  But a user can think of BIER itself as service and use first bytes of the frame for service-access-point demuxing of course.

Which is why i was suggesting UDP as the transport layer service for
applications. No need to modify reinvent this unnecessarily.

> This will happen in a sense anyway since the subdomain demux is small (1 byte) given the network is aware of it to provide service separation so running each App on its own sub-domain ain't gonna get far, there will be sub-service-access-points (SSAPs)  ;-)  

subdomain is part of the ultimate transport service
point address, but as said in before, would like to see
how we can ensure efficient / limited use of it to ensure
as little BIER space in network as necessary. 

> I didn't even start to think how e.g. mTCP would work with all that.  

Whats mTCP ?

Cheers
    Toerless

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 13 Oct 2015 22:10:27 +0000

Cutting points short, no cycles ... inline ... 

There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded.
~~~ Mark Twain

[Tony saiz:] 

I missed something on quick read then. I thought you're advocating putting 
UDP indicating directly into MPLS encaps to shortcut IP headers. 

> I'd first like to understand a practical use case benefit. I like inspection/analysis
> of RTP and SPUD, for IP header i don't know a need and worry about bringing in
> downides:
[Tony saiz:] 

So it looks like you want to cut IP header out. Yes, addresses superfluous and I 
Don't see WHY we'd _really_ need an IP header on it (TTL's not needed) _except_ 
UDP checksum  which cannot be calculated if IP is not on it (and otherwise 
we don't have one which is dangerous state of affairs). 
But it's more silicon vendor discussion now. They have large blocks of IP processing 
In place with all the csum/ttl magic and once they strip BIER off they will be probably
really lost with  a /naked/ UDP and not enough data for checksum.  Albeit from
little I know about hardware no'one cares for UDP csum these days. 

> 
> In both the API proposals you and i posted to the list we just spoke of list of
> receivers, not of multicast groups (or SSM channels).
> We just need to argue whether apps need to know BFR-ids, or just BFR-prefixes.
[Tony saiz:] 

Nope, I agree fully that introducitng need for S/G style multicast addresses on packets
will be detrimental for BIER.  BFR-prefixes or IDs should be the matter of discourse
on the network packets/control only (i.e. within BIER layer).

FEC 128/9 or similar which is really just PMSI is needed and BIER overlay can work
with either group addresses or BFR-prefixes+subdomain. 

> 
> I'd hate if we'd force the concept of multicast group addressing into BIER
> application services/APIs (unless desirable for some reason) just because we
> need to fill some redundant IP header with some destination address. And if
> there is ANYTHING that DPI could get from a redundant IP header, it's source
> and destination address. So if we just fill it with some useless group address,
> then that would even further reduce any DPI benefits of the header.
[Tony saiz:] +1 when we talk BIER layer. BIER overlay should be completely
free to do whatever they
want including simulating S,G obviously. 

[Tony saiz:] 

http://www.nesc.ac.uk/events/ahm2004/presentations/50.pdf

Varghese did stuff before that even. 

Some people thought about "what would transport do if we'd have a real large-scale, cheap IP multicast" a while ago already and all of a sudden it could become warmed up again ... 

--- tony