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

[Gregory Mirsky <[e-mail]>]

Thx, will educate myself on it.

                Regards,
                                Greg

From: Antoni Przygienda
Sent: Thursday, February 18, 2016 8:02 AM
To: Gregory Mirsky; Pascal Thubert (pthubert)
Cc: [e-mail]
Subject: RE: [Detnet-dp-dt] BIER packet duplication question

Most likely referring to

https://datatracker.ietf.org/doc/draft-eckert-bier-te-arch/

thanks

--- tony
_____________________________________________
"Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior."
--- Dee Hock

From: Gregory Mirsky
Sent: Thursday, February 18, 2016 7:17 AM
To: Pascal Thubert (pthubert)
Cc: [e-mail]<mailto:[e-mail]>; Antoni Przygienda
Subject: RE: [Detnet-dp-dt] BIER packet duplication question

Hi Pascal,
thank you for the further explanation about your proposal. I haven't heard about BIER-TE and would appreciate if you can reference any draft on it as I'm not aware of any. BIER, at least what you refer to as "classical" BIER, is not traffic engineering, but multicast solution. TE, explicit routing component, can be provided to BIER through transport layer enabled, for example, by Segment Routing. Thus, in combination of Segment Routing and BIER we can construct controlled distribution domain to be used by DetNet.

                Regards,
                                Greg

From: Pascal Thubert (pthubert) [mailto:[e-mail]]
Sent: Thursday, February 18, 2016 5:50 AM
To: Gregory Mirsky
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Detnet-dp-dt] BIER packet duplication question

Hello Greg:

With the classical BIER as described in the architecture, bits indicate a destination so it is not designed for nailing down TE paths.  It can be done if we have 2 domains per flow, and a route per domain that is computed centrally, but that looks like an overkill.

This is why we are proposing a BIER-TE where the bits indicate segments. Listening to you at the call, this proposal seems to be what you are really after. I'm happy to talk more when you can.

Also,  I agree with you that overloading the entropy field is probably a bad idea.

Cheers,

Pascal

From: Gregory Mirsky [mailto:[e-mail]]
Sent: jeudi 18 février 2016 03:07
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Detnet-dp-dt] BIER packet duplication question

Hi Pascal,
thank you for providing additional context to slides. I'll comment on them in more details later.
I've talked with Tony P, Ice should have no problem identifying him, about some proposals in BIER you've mentioned earlier, e.g. re-use of Entropy field. I'll point that BIER Architecture document is explicit about interpretation of bits in the BitString. These are indexes of BFERs in the given BIER sub-domain (sub-domain is limited to 256 BFRs) and not links, logical or physical (that could be Segment Routing underlay to BIER domain). Thus we cannot reach the same BFER in the given BIER sub-domain over disjoint path or, in other words, the BFER can receive only single copy of the payload in the given sub-domain. Hence my proposal to use multiple, several BIER sub-domains overlayed over the same BIER domain.
Yes, as I've noted, I gave only an example of how BIER may be used to support DetNet packet replication and termination to improve probability of delivery within predetermined time.

                Regards,
                                Greg

From: Pascal Thubert (pthubert) [mailto:[e-mail]]
Sent: Wednesday, February 17, 2016 9:27 AM
To: Gregory Mirsky
Cc: [e-mail]<mailto:[e-mail]>
Subject: FW: [Detnet-dp-dt] BIER packet duplication question

Hello Greg:

Here's some text related to the slides in the github since the previous call. Should I place text in the document about that? Would that be a different section?

Also: I heard you saying that you talked to someone and concluded that a certain thing does not work, but I could not hear what that was. Could you please elaborate on that one -sorry for this- ?

Finally, the BIER domain can be seen as a topology information. When we use a PCE, we can do with just 2 of them, blue and red, say. Each bicasted flow will be sent twice, a blue copy and a red copy.

I wish to make sure that the text does not give the impression that the BIER domains are a physical separation, or that you have to define 2 new domains for each new flow. In the simplest case, all BIER nodes belong to both domains, but happen to participate to one only for a particular bi-casted flow (same source and destination), as long as the paths can be maintained non-congruent.

For a multicast flow, a node may have to forward both a blue and a red copy even when a full non-congruency is achieved. This is because the non-congruency needs to be per destination (which is much simpler) as opposed to a tree wide property. The whole trick is to minimize that case so as to optimize the efficiency of the multicast. That's really a PCE game, the nodes are obedient slaves.

Cheers,

Pascal

From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 29 janvier 2016 13:35
To: Gregory Mirsky <[e-mail]<mailto:[e-mail]>>; Olivier Marce <[e-mail]<mailto:[e-mail]>>; Jouni Korhonen <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: IJsbrand Wijnands (iwijnand) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Detnet-dp-dt] BIER packet duplication question

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:[e-mail]]
Sent: jeudi 28 janvier 2016 19:03
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; Olivier Marce <[e-mail]<mailto:[e-mail]>>; Jouni Korhonen <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: IJsbrand Wijnands (iwijnand) <[e-mail]<mailto:[e-mail]>>
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 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:[e-mail]]
Sent: Saturday, January 23, 2016 8:04 AM
To: Olivier Marce; Gregory Mirsky; Jouni Korhonen; [e-mail]<mailto:[e-mail]>
Cc: IJsbrand Wijnands (iwijnand)
Subject: RE: [Detnet-dp-dt] BIER packet duplication question


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





> -----Original Message-----

> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of

> Olivier Marce

> Sent: vendredi 22 janvier 2016 17:11

> To: Gregory Mirsky <[e-mail]<mailto:[e-mail]>>; Jouni Korhonen

> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

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

>

> 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

>

>

> Le 13/01/2016 01:44, Gregory Mirsky a écrit :

> > 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:[e-mail]] On Behalf Of

> > Jouni Korhonen

> > Sent: Tuesday, January 12, 2016 9:44 AM

> > To: [e-mail]<mailto:[e-mail]>

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

> >

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

> >

>

> --

> !! Happy Nok'year !!

> --

> Olivier Marcé

> Nokia Bell Labs France

>

> _______________________________________________

> Detnet-dp-dt mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/detnet-dp-dt