Subject: [Detnet-dp-dt] BIER packet duplication question

From: Jouni Korhonen <[email-masked]>
Date: Tue, 12 Jan 2016 17:43:30 +0000

I did some "familiarization" with BIER and it is not instantly clear to me how the packet duplication in intermediate BFRs would work in a case the destination is a single BF(E)R?

- Jouni

-- 
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135,  M: +1-408-391-7160

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 12 Jan 2016 18:20:48 +0000

Hi Jouni,
you're absolutely correct, this is non-obvious how to direct replicated packets to the same downstream BFR so that it receives multiple copies. I'm thinking about that and will discuss this with BIER authors. Will update the team by the end of the week.

	Regards,
		Greg

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Tuesday, January 12, 2016 9:44 AM
To: [email-masked]
Subject: [Detnet-dp-dt] BIER packet duplication question

- Jouni

_______________________________________________
Detnet-dp-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 13 Jan 2016 00:44:19 +0000

Hi Jouni,
BIER does not allow packet duplication within the given BIER sub-domain that in case of MPLS dataplane is identified by BIER-MPLS label at the bottom of label stack. Duplication of packets can be realized by computing, centralized or distributed, distribution trees with desired level of node and link disjointness, exclusion. BIER supports use of multiplicity of tree computation algorithms.

	Regards,
		Greg

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Tuesday, January 12, 2016 9:44 AM
To: [email-masked]
Subject: [Detnet-dp-dt] BIER packet duplication question

- Jouni

---

From: Olivier Marce <[email-masked]>
Date: Fri, 22 Jan 2016 17:10:30 +0100

Hi (from Nokia now)

I certainly missed some earlier discussion but so far the link between
DetNet and BIER  is not clear for me.

Meanwhile I'm looking at time related technologies, familiarisation
only, up to now. I wonder if state of the art solutions are accurate
only to support what is expected in DetNet.

Maybe we could have a page on Git listing considered technologies and
how they can/could contribute to DetNet ?

Regards

-- 
!! Happy Nok'year !!
--
Olivier Marcé
Nokia Bell Labs France

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 23 Jan 2016 16:03:34 +0000

I visited Ice (cc) this week to discuss the applicability of BIER.

Indeed we found a great match but that will need some explaining and we'll do a write up if this team wishes to hear about it.

The catch is that the method we have in mind leverage Cisco IPR, which Cisco would announce with the usual terms as soon as we publish a draft 00. Is that acceptable?

In very short we can decline BIER-TE and use the bits to control at the source which of the possible replication points will effectively do it (setting bits associated to L2 links/L3 segments) and mark along the way which replicators effectively made a replication. The value is that it is always possible to identify which copy by which replication point a packet is, and at the point of arrival, we can determine which segment failed on a per packet basis, and use that to de/reactivate replication points (by setting the bits).

The BIER header is of variable size, we can use a model with 64 bits if 64 segments are enough for us, but we can also have 128 or 256 segments in very complex paths.

      0                   1                   2                   3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |0 1 0 1|  Ver  |  Len  |              Entropy                  |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                BitString  (first 32 bits)                     ~

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ~                                                               ~

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     ~                BitString  (last 32 bits)                      |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |OAM|     Reserved      | Proto |            BFIR-id            |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 1: BIER Header

The entropy can be used to store a wrapping packet sequence number within a flow.

That's certainly enough to encode the gap between 2 flows.

The source of the flow is indicated by the BFIR-id.

The Flow itself can be indicated in the encapsulating protocol, in which case we'd need to design one way per encaps.

An alternate is to use a Proto  to encode the Flow ID after the BIER header.

What do you guys think?

Pascal

> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of

> Olivier Marce

> Sent: vendredi 22 janvier 2016 17:11

> To: Gregory Mirsky <[email-masked]>; Jouni Korhonen

> <[email-masked]>; [email-masked]

> Subject: Re: [Detnet-dp-dt] BIER packet duplication question

> I certainly missed some earlier discussion but so far the link between DetNet

> and BIER  is not clear for me.

> Meanwhile I'm looking at time related technologies, familiarisation only, up

> to now. I wonder if state of the art solutions are accurate only to support

> what is expected in DetNet.

> Maybe we could have a page on Git listing considered technologies and how

> they can/could contribute to DetNet ?

> > BIER does not allow packet duplication within the given BIER sub-domain

> that in case of MPLS dataplane is identified by BIER-MPLS label at the

> bottom of label stack. Duplication of packets can be realized by computing,

> centralized or distributed, distribution trees with desired level of node and

> link disjointness, exclusion. BIER supports use of multiplicity of tree

> computation algorithms.

> > From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of

> > Jouni Korhonen

> > To: [email-masked]<mailto:[email-masked]>

> > I did some "familiarization" with BIER and it is not instantly clear to me

> how the packet duplication in intermediate BFRs would work in a case the

> destination is a single BF(E)R?

> [email-masked]<mailto:[email-masked]>

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 28 Jan 2016 18:03:28 +0000

Hi Pascal, et. al,
thank you for very interesting proposal. I do have concern about re-definition of the Entropy field in the BIER encapsulation for MPLS network. In my opinion it creates another class of BIER Forwarding Routers (BFRs) that interpret the field differently. As result, as I think of it, this behavior must be advertised in IGP so that non-compliant BFRs, those that interpret it exclusively as defined in draft-ietf-bier-mpls-encapsulation, be excluded from BFR role. But that doesn't mean that I don't see BIER as suitable data plane for DetNet. I do believe though that using separate BIER sub-domain with disjoint (level of disjointness may be one of constraints in path computation in addition to latency, jitter and loss ratio) paths would be appropriate way to use BIER infrastructure for DetNet. And I do believe that sequence number belong in distinct DetNet layer encapsulation (we likely find that it should have more than just Sequence Number).
I'll note that use of the Sequence Number field, as per RFC 4448, is optional as well as use of PW CW in Ethernet PW.Section 2.7 RFC 7079 gives, though by now historical view, of how generic support of PW CW in Ethernet PW been. Hence, I do believe that distinct DetNet encapsulation is justified and the right way to go.

                Regards,
                                Greg

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Saturday, January 23, 2016 8:04 AM
To: Olivier Marce; Gregory Mirsky; Jouni Korhonen; [email-masked]
Cc: IJsbrand Wijnands (iwijnand)
Subject: RE: [Detnet-dp-dt] BIER packet duplication question

      0                   1                   2                   3

     ~                                                               ~

                           Figure 1: BIER Header

What do you guys think?

Pascal

> To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>; Jouni Korhonen

> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 28 Jan 2016 19:45:24 +0000

Pascal,

Regarding the IPR as long as the IETF disclosure process is followed I do not see an issue here. At this point we are only concerned about technicalities of potential solution alternatives. The endorser solution selection is another exercise where disclosures potentially have weight..

- Jouni

From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)

      0                   1                   2                   3

     ~                                                               ~

                           Figure 1: BIER Header

What do you guys think?

Pascal

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 28 Jan 2016 20:32:18 +0000

Hi,

Few comments/thoughts inline.

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Thursday, January 28, 2016 10:03 AM
To: Pascal Thubert (pthubert); Olivier Marce; Jouni Korhonen; [email-masked]
Cc: IJsbrand Wijnands (iwijnand)
Subject: RE: [Detnet-dp-dt] BIER packet duplication question

Hi Pascal, et. al,
thank you for very interesting proposal. I do have concern about re-definition of the Entropy field in the BIER encapsulation for MPLS network. In my opinion it creates another class of BIER Forwarding Routers (BFRs) that interpret the field differently. As result, as I think of it, this behavior must be
[JiK:] In general, if some desired functionality is not readily available i.e., needs new stuff to be added or desired functionality is partial i.e., need repurposing some protocol field that is worth documenting in appropriate place where the solution criteria is listed.
advertised in IGP so that non-compliant BFRs, those that interpret it exclusively as defined in draft-ietf-bier-mpls-encapsulation, be excluded from BFR role. But that doesn't mean that I don't see BIER as suitable data plane for DetNet. I do believe though that using separate BIER sub-domain with disjoint (level of disjointness may be one of constraints in path computation in addition to latency, jitter and loss ratio) paths would be appropriate way to use BIER
[JiK:] I would like to learn in more detail how you see this working or to be enabled.
infrastructure for DetNet. And I do believe that sequence number belong in distinct DetNet layer encapsulation (we likely find that it should have more than just Sequence Number).
I'll note that use of the Sequence Number field, as per RFC 4448, is optional as well as use of PW CW in Ethernet PW.Section 2.7 RFC 7079 gives, though by now historical view, of how generic support of PW CW in Ethernet PW been. Hence, I do believe that distinct DetNet encapsulation is justified and the right way to go.
[JiK:] Agree.

- Jouni

                Regards,
                                Greg

To: Olivier Marce; Gregory Mirsky; Jouni Korhonen; [email-masked]<mailto:[email-masked]>

      0                   1                   2                   3

     ~                                                               ~

                           Figure 1: BIER Header

What do you guys think?

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 29 Jan 2016 12:34:38 +0000

Hello Greg:

The value of the BIER header in this proposal is in the replication and elimination domain, as opposed to flow identification and sequencing.  BIER is used to identify the segments that are activated (by the controller) and those where transmission failed (which can be returned to the controller for action). The value is that the replication can be controlled and monitored with the granularity of a packet and a segment.

BIER also enables to abstract what a segment is. A segment can be an Ethernet hop, and it can be an IPv6 loose source routed path. In the latter case the source route state must be provisioned in the replicator node that serves the particular bit(s), together with the timing or shaping information for that particular flow.

In more details:

-        The controller activates replication by setting bits associated with segments

-         the eliminator function strips the source route headers and performs a bitwise AND on the bitmaps from the various copies of the packet that it receives.

-        For each bit that it serves, the replicator function forms a packet where it inserts the source route header for the next segment that corresponds to the bit, inserts a BIER header (e.g. the result of the AND operation by the eliminator function), zeroes out the bit in the BIER header and transmits along the SR path.

To your points:

1)      With MPLS, the BIER behavior is identified implicitly with the MPLS label which is used to find the state associated to the BIER bits, but I agree that explicit is probably better.

2)      The association of the bit with an address (such as a loopback address in the router) does not depend on whether we use this router for DetNet or classical BIER. I would not necessarily want to change any of  this. I expect that the controller knows that the router is capable of DetNet before it makes it a segment endpoint, and only segment endpoints need to look into the BIER header which is placed after the source route header.

3)      I understand that the proto field in BIER allows us to define what the protocol inside is. The original proposal was to define a DetNet header for the flow ID (and next header), but then the new header that we define could have more, like flow ID and sequence number as I understand you are suggesting with your point on CW. In that case, we'd be independent on the encapsulation, and the flow/seq encoding would be independent on whether we use the technique above to do replication and elimination, like our proposed BIER encoding.

Does that make sense?

Pascal

From: Gregory Mirsky [mailto:[email-masked]]
Sent: jeudi 28 janvier 2016 19:03
To: Pascal Thubert (pthubert) <[email-masked]>; Olivier Marce <[email-masked]>; Jouni Korhonen <[email-masked]>; [email-masked]
Cc: IJsbrand Wijnands (iwijnand) <[email-masked]>
Subject: RE: [Detnet-dp-dt] BIER packet duplication question

Hi Pascal, et. al,

                Regards,
                                Greg

      0                   1                   2                   3

     ~                                                               ~

                           Figure 1: BIER Header

What do you guys think?

Pascal