Subject: Re: [Bier] ????: Scope of alternate encap work / eg: draft-xu-bier-encapsulation

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Sep 2016 08:52:10 +0200

On Thu, Sep 22, 2016 at 03:15:51AM +0000, Xuxiaohu wrote:
> [Xiaohu2] IMHO, the BIER layer is another network layer. Hence it seems unnecessary to add one more network layer header (i.e., IPv6 header). Whether or not IPv6 would be used in the IoT world is a uncertainty:)  Hence it seems too early to take the IoT stuff into account when designing a transport-independent BIER header. Of course, you firmly believe that IoT is a valid use case for BIER, it'd better to proposal some text to the BIER use case draft or write another IoT-specific use case draft.

No strong opinions from my side, just personal preferences, but i was mostly
trying to figure out what you thought to be important.

The statement that your encap considers BIER as a "full" network layer comparable
to IP should also go into the document. And that encaps into eg: IP or other network
layers are just "tunnel" cases - which would not justify to strip fields from
your proposed BIER header. It's a main difference over the MPLS BIER header, so it's
good to write down the reasoning.

Maybe even call the encap proposal IP-BIER or the like. In comparison, if you wanted
BIER encap across an L2 network, eg: for L2-switches, you would not have TTL (STP
takes care of loops), you wouldn't have IP like DS, and you'd have some L2-next-proto
fields instead of the value from the IP header.

IPA-Bier ? ;-)) (IP Alternative BIER).

> There should be some good text why the TTL field is necessary
>  - It is not necessary for loop prevention within the BIER domain, BIER does
>    that well by itself.
>  - TTL scoping is disliked.
>  - The payload itself wuld also have a TTL field if it needs one.
>  - What good reason am i missing ?
> 
> [Xiaohu2] Assume that only one bit of the Bitstring is set, it's equivalent to the usage of a unicast IP tunnel. Do you need a TTL field within an IP tunnel?

I think i was confused. In BIER-TE there is loop prevention by BIER-TE itself,
not relying on other header fields. If i now remember it correctly, in BIER,
packets can loop if there is an IGP loop, so TTL should be fine/necessary.

Cheers
    Toerless

> > [Xiaohu] See the above.
> 
> If you want UDP inside your encap to be out of scope, please write that up, see suggested text above.
> 
> [Xiaohu2] Sure, thanks again for your suggested text.
> 
> Best regards,
> Xiaohu
> 
> Cheers
>     Toerless
> 
> > Best regards,
> > Xiaohu
> > 
> > 4. Can support for BIER-TE be in scope ? Would like a life-insurance bit:
> >    "BIER-TE" in header. I hope we can keep all BIER header fields with same
> >    semantic for BIER-TE, but if not, this bit would allow us to later on 
> >    modify how specific fields operate under BIER-TE.
> > 
> > 
> > 5. Tracing. In DetNet, the idea to use BIER-TE was brought up, and tracing of
> >    the packet path was given as key reason. With just resetting bits. Which doesn't
> >    help much to trace. Lets assume we have a "trace-bit" in the header. Only
> >    lower 50% of bitstring get allocated. Every time BFR resets bits in lower
> >    50%, it sets same bits in upper 50%. Gives great tracing.  Applicable to BIER
> >    and BIER-TE.  Oh, and keeps UDP checksum of BIER header unchanged.
> > 
> > Toerless
> > 
> > On Wed, Jul 20, 2016 at 05:17:14PM -0700, Greg Shepherd wrote:
> > > *,
> > > 
> > > Thank you to all who attended and contributed to the lively 
> > > discussion at the WG meeting in Berlin this week. This is what WG 
> > > meetings should be - and some would say, used to be.
> > > 
> > > >From a poll in the room, there was consensus to pull together a 
> > > >volunteer
> > > design team to look at the various encap options, and based on 
> > > use-case/operational considerations/support the team will pick one 
> > > additional encap to document and offer as a WG item. The expectation 
> > > is the list of volunteers will attend an interim WG meeting were we 
> > > will work together for 2-3 days to hash out the direction and details.
> > > This will be a physical meeting, but will accommodate remote participation as well.
> > > 
> > > I would like to see this work published and available for further 
> > > discussion to the group at large on the list before and in the room 
> > > during the next WG meeting in November. Considering the requirements 
> > > for interim meeting announcements, the soonest we can reasonably 
> > > target an interim meeting is Sept.
> > > 
> > > Anyone wanting to volunteer as a member of the BIER Encap Design 
> > > Team, please send email to the WG chairs. We will compile the list, 
> > > then target a suitable location and dates from there. We look 
> > > forward to pulling this enthusiastic team together in one direction.
> > > 
> > > Thanks,
> > > Greg