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

From: Toerless Eckert <[email-masked]>
Date: Wed, 21 Sep 2016 01:22:00 +0200

What is the scope of work for the alternative encap work ? Sorry if i missed a memo..

Some xample questions based on draft-xu-bier-encapsulation:

1. I want to use this encap "natively" over IP, aka: hop-by-hop replication.
   How do i set the fields of the IP header like source/dest address ? Which
   document would that ultimately be defined in ?

2. Now i want to use the encap over UDP because i want end-to-end BIER
   from my app, and apps can only do eg: UDP. So i really would like such an encap.
   Is this already out of scope as a use-case because end-to-end (host/app) BIER is
   not in charter scope ?

3. Lets assume some use case with UDP was in scope. What do we do about our
   best friend the UDP checksum on a BFR ? Pending on 1., the IP header may
   change. And bits in the bitstring will get reset. Force UDP checksum to 0 ?
   (given how payload will likely be UDP again).   Shadow checksum in BIER header, ?...

   If questions like these are out of scope (subject for followup work how to
   apply common encap to FOO), then we run the risk of misdesigning a common
   header.

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

> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
[email-masked]
/C=de/A=d400/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless/

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 21 Sep 2016 09:57:06 +0000

Hi Toerless,

-----邮件原件-----
发件人: BIER [mailto:[email-masked]] 代表 Toerless Eckert
发送时间: 2016年9月21日 7:22
收件人: [email-masked]
主题: [Bier] Scope of alternate encap work / eg: draft-xu-bier-encapsulation

[Xiaohu] If you want hop-by-hop replication, why not encapsulate the BIER directly over Ethernet or PPP directly? Of course, if you want to tunnel a BIER packet over an IP-based (unicast) tunnel for a certain reason (e.g/. traverse non-BIER transit routers), you can (please see Section 4 of for draft-xu-bier-encapsulation-05 more details). 

[Xiaohu] How to transport BIER packet over UDP tunnels is also mentioned in Section 4 of draft-xu-bier-encapsulation-05. Or are you talking about encapsulating UDP datagram over BIER? If so, I don't believe it's an urgent use case due to the deployment complexity.

[Xiaohu] See the above.

Best regards,
Xiaohu

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

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 22 Sep 2016 03:15:51 +0000

Hi Toerless,

Please see my response inline with [Xiaohu2]

-----邮件原件-----
发件人: Toerless Eckert [mailto:[email-masked]] 
发送时间: 2016年9月22日 3:26
收件人: Xuxiaohu
抄送: Toerless Eckert; [email-masked]
主题: Re: [Bier] Scope of alternate encap work / eg: draft-xu-bier-encapsulation

Inline

> [Xiaohu] If you want hop-by-hop replication, why not encapsulate the BIER directly over Ethernet or PPP directly? Of course, if you want to tunnel a BIER packet over an IP-based (unicast) tunnel fo…

I asked first ;-))

But fine, let me add your option: Whether the IP next-hop is
L2 connected or remote: Which document should describe how to set up the next hop and build out a solution with this encap over IP ?  I just feel uncomfortable with judgement calls about the encap if i have no spec of how its supposed to be used.

[Xiaohu2] If the next-hop is an adjacent node, use BIER-over-Eth or BIER-over-PPP according to the outgoing interface type. If the next-hop is a remote node (i.e., a tunnel), use BIER-over-IP. In fact, there is almost no difference from the procedure of sending unicast IP packets. 

To answer your question: Encap over ethernet is typically better/more efficient if you can build it into the target products. Encap over IPv6 link-local is a great way for an L2-technology independent encap. Think about all those platform dependencies and L2 technology differences when you go into IoT with all its crazy link options.

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

> [Xiaohu] How to transport BIER packet over UDP tunnels is also mentioned in Section 4 of draft-xu-bier-encapsulation-05.

The question again is how much more considerations/etails should be in scope for the encap work besaide your 1 line "mentioning" -- "encap is transport independent, can be used across ANYTHING".

Eg: If i want to build a BFR receiving UDP encapped BIER packets, replicating and sending out to one or more outbound links with UDP encap. How do i do this ?
Without more thougt it would not be efficient because of UDP checksum. So is this case out of scope ?

[Xiaohu2] very good question. Once the WG had reached a certain consensus on the generic BIER header format, it becomes necessary for us to specify more details about how to encapsulate BIER over certain transport, especially the UDP tunnel, just like what we had done with MPLS-in-UDP (RFC7510). 

> [Xiaohu] Or are you talking about encapsulating UDP datagram over BIER? If so, I don't believe it's an urgent use case due to the deployment complexity.

Haha, ok. I was immediately reading this option into the draft because i think it is a very interesting option. So would be good if it was clear if this would be in scope or not.

Assuming it would not be in scope, then it would be good to expand on the text with something like these explanations:

  - This header includes IP/IPv6 header equivalent fields Protocol/DS/TTL
    to allow building BFR where encapsulation, QoS and loop prevention
    of BIER packets can be done in the same fashion as for IP/IPv6 packets.

  - With the use of the IP/IPv6 equivalent Protocol field, the payload of
    BIER packets could be any type of packet permitted also inside of IP/IPv4.
    Currently, this draft considers primarily the use of the encapsulation
    for "transport" type services, eg: where the encapsulated packets are
    L2/L2.5 such as MPLS, VXLAN [RFC7348],VXLAN-GPE or L3, eg: IPv4/IPv6
    (unicast or multicast). It would equally be possibble to directly encapsulate
    L4 such as UDP, but the full considerations for this are currently out
    of scope.
  
[Xiaohu2] very good suggestion. I would add it into the next reversion.

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?

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

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

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 22 Sep 2016 07:08:43 +0000

Hi Toerless,

Please see my response inline with [Xiaohu3]

-----邮件原件-----
发件人: Toerless Eckert [mailto:[email-masked]] 
发送时间: 2016年9月22日 14:48
收件人: Xuxiaohu
抄送: Toerless Eckert; [email-masked]
主题: Re: ????: [Bier] Scope of alternate encap work / eg: draft-xu-bier-encapsulation

> [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…

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

[Xiaohu3] OK, I see. Thanks.

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.

[Xiaohu3] If I understand it correctly, both the generic BIER encapsulation and the MPLS-BIER encapsulation are targeted for the tunnel case. Maybe I misunderstand your point.

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.

[Xiaohu3] BIER is at the network layer. Hence to transport BIER packets across an L2 network (e.g., Ethernet network), the BIER packets need to be encapsulated with an L2 header (e.g., Ethernet header) before entering that L2 network. In fact, you could look it as something like TRILL.

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

[Xiaohu3] Since the generic BIER is designed to be transport-independent, it seems confused to couple it with IP:)

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

[Xiaohu3] OK. Thanks a lot again for your valuable suggestions on the generic BIER encapsulation proposal.

Best regards,
Xiaohu

Cheers
    Toerless

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