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

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Sep 2016 19:02:31 +0200

On Thu, Sep 22, 2016 at 07:08:43AM +0000, Xuxiaohu wrote:
> [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.

I am trying to figure out how we/the draft could better explain
what the logical behavior of a BFR is when it uses your draft.

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

If a BFR uses MPLS-BIER encap, the BFR becomes an LSR, and BFR-ID
and BitString addressing is similar to eg the MPLS FEC. Aka: BFR
is an L2.5 element with some novel L2.5 addressing.

When we use your draft, and as you said 'native' encap being to put
these BIER packets directly over eg: ethernet/MAC encap, then
the semantic of BIER/BFR is probably still best described as
L2.5 - there is still no end-to-end-network layer addressing,
we still only have BFR-ID/Bitstring, but the hop-by-hop forwarding with
DS instead of EXP is more like IP.

If we allowed for your encap to go all the way from application source
to application receiver, then it could be new network layer, and we'd
elevate BFR-ID/Bitstring to a new type of network layer addresses,
and then your encap could be called L3/network-layer BIER. This is
the big difference to Pierres draft which solves that end-to-end
piece by using the existing IPv6 addresses.

If i would take your encap, strip away the TTL and DS fields, replace
the (IP-)Protocol  field with an Ethernet-Protocol field and use this
form of BIER on an L2 switch, we would have an L2/Bridge version of BIER.

Aka: BIER could be L2, L2.5, L3.

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

I think it would help to add a sentence explaining what "transport-independent"
means in the case of your draft: 

-> In the BIER architecture, there are two "contextual fields" for
   the BitString: SI and Sub-Somain. With the BIER-MPLS encap,
   this context is established by MPLS. That ties the MPLS-BIER
   encap to not only some preceeding MPLS header with a label, but
   also to MPLS label binding procedures.

-> By folding these fields into the BIER header, this dependency against
   MPLS is removed. That is what this draft calls "transport independent".

Overall, the encap proposes an 'IP-like' L2.5 BFR/BIER-domain model:

   - It's IP-like because it proposes IP like QoS and encap (IP protocol).

   - It is not L3, because so far there are no attempts to make
     BFR-ID/BitString available as end-to-end L3 addresses, so
     prime target use of this encap is for networks with "transport
     services' on the edge, eg: like MPLS networks (without MPLS ;-).

Cheers
    Toerless
> 
> Best regards,
> Xiaohu
> 
> 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
> > >

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 23 Sep 2016 03:24:55 +0000

Hi Toerless,

Thanks again for you good suggestions. To clarify the "tunnel" usage of the BIER encapsulation, I had added more text as follows:

OLD:
      Protocol: a one-octet field indicating the protocol type of the
      BIER payload as per the protocol numbers used in the Protocol
      field [RFC5237]of the IPv4 header and the Next Header field of an
      IPv6 header.  The valid BIER payload types include (but are not
      limited to) IPv4, IPv6, MPLS, VXLAN [RFC7348],VXLAN-GPE
      [I-D.ietf-nvo3-vxlan-gpe].  The corresponding IP Protocol numbers
      for VXLAN and VXLAN-GPE are to be allocated by IANA.

NEW:
      Protocol: a one-octet field indicating the protocol type of the
      BIER payload as per the protocol numbers used in the Protocol
      field [RFC5237] of the IPv4 header and the Next Header field of an
      IPv6 header.  Theoretically, with the use of the IPv4/IPv6
      equivalent Protocol/Next-Header field, the payload of a BIER
      packet could be any type of payload permitted within the IPv4/IPv6
      packet.  However, this document currently only consider the use of
      the BIER encapsulation for "transport" type services where the
      encapsulated packets are either L2.5 (e.g., MPLS) or L3 (e.g., IP)
      packets . The valid BIER payload types include (but are not
      limited to) IPv4, IPv6, MPLS, VXLAN [RFC7348],VXLAN-GPE
      [I-D.ietf-nvo3-vxlan-gpe].  The corresponding IP Protocol numbers
      for VXLAN and VXLAN-GPE are to be allocated by IANA. 

Please check whether the above text is now OK.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Toerless Eckert [mailto:[email-masked]]
> 发送时间: 2016年9月23日 1:03
> 收件人: Xuxiaohu
> 抄送: Toerless Eckert; [email-masked]
> 主题: Re: [Bier] Scope of alternate encap work / eg: draft-xu-bier-encapsulation
> 
> > [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.
> 
> I am trying to figure out how we/the draft could better explain what the logical
> behavior of a BFR is when it uses your draft.
> 
> > [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.
> 
> If a BFR uses MPLS-BIER encap, the BFR becomes an LSR, and BFR-ID and
> BitString addressing is similar to eg the MPLS FEC. Aka: BFR is an L2.5 element
> with some novel L2.5 addressing.
> 
> When we use your draft, and as you said 'native' encap being to put these BIER
> packets directly over eg: ethernet/MAC encap, then the semantic of BIER/BFR
> is probably still best described as
> L2.5 - there is still no end-to-end-network layer addressing, we still only have
> BFR-ID/Bitstring, but the hop-by-hop forwarding with DS instead of EXP is more
> like IP.
> 
> If we allowed for your encap to go all the way from application source to
> application receiver, then it could be new network layer, and we'd elevate
> BFR-ID/Bitstring to a new type of network layer addresses, and then your
> encap could be called L3/network-layer BIER. This is the big difference to
> Pierres draft which solves that end-to-end piece by using the existing IPv6
> addresses.
> 
> If i would take your encap, strip away the TTL and DS fields, replace the
> (IP-)Protocol  field with an Ethernet-Protocol field and use this form of BIER on
> an L2 switch, we would have an L2/Bridge version of BIER.
> 
> > [Xiaohu3] Since the generic BIER is designed to be
> > transport-independent, it seems confused to couple it with IP:)
> 
> > > > > discussion at the WG meeting in Berlin this week. This is what
> > > > > WG meetings should be - and some would say, used to be.
> > > > >
> > > > > use-case/operational considerations/support the team will pick
> > > > > one additional encap to document and offer as a WG item. The
> > > > > 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.
> > > > >

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 23 Sep 2016 07:46:36 -0700

If you include references to VXLAN then you should also add references to RFC6830 LISP. 

Dino

> On Sep 22, 2016, at 8:24 PM, Xuxiaohu <[email-masked]> wrote:
> 
> Hi Toerless,
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 23 Sep 2016 20:49:37 +0200

Sounds good. Thanks.

On Fri, Sep 23, 2016 at 03:24:55AM +0000, Xuxiaohu wrote:
> > -----????????-----
> > ??????: Toerless Eckert [mailto:[email-masked]]
> > ????????: 2016??9??23?? 1:03
> > ??????: Xuxiaohu
> > ????: Toerless Eckert; [email-masked]
> > ????: Re: [Bier] Scope of alternate encap work / eg: draft-xu-bier-encapsulation
> > 

-- 
---
[email-masked]

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 24 Sep 2016 00:46:55 +0000

Sure. I would add that reference in next revision.

Best regards,
Xiaohu

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

Dino

On Sep 22, 2016, at 8:24 PM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Toerless,

OLD:

NEW:

Best regards,
Xiaohu

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

I think it would help to add a sentence explaining what
"transport-independent"
means in the case of your draft:

Cheers
   Toerless

Best regards,
Xiaohu

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.

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

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.

Thanks,
Greg

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