[Detnet-dp-dt] call 2/28/17 notes

[Jouni Korhonen <[e-mail]>]

Present: Jouni, Janos, Balazs, Loa, Norm, Carlos, Yuanlong, David (short time)

Agenda:
Loa’s updated slides and Norm’s multicast+ring slides (wheels v03.pptx - updated version attached)


Discussion/notes:
We were supposed to spend a short time on Norm’s slides but ended up spending all time plus some extra on this one slide.
How to read the slide:
 - yellow and blue nodes are Detnet aware MS-PW PEs that implement FRER
 - grey nodes are (DetNet aware) end stations 
 - green nodes are just LSRs (note that ‘E’ does PHP)
 - ring going east and its packets are outside the ring
   ring going west and its packets are inside t right
 - two PWs pw1 and pw2
 - grey node 0 is the source of the multicast _tree_.
   other grey nodes are receivers of the multicast

Agreed FRER processing when a packet arrives from both east and west.. take an S-PE ‘D’ as an example:
 - Assume packets from east arrive first (pw1 and pw2 from 0->A->B->C->D)
   * replicate copies to ‘3’ and ‘4’ accordingly
     replicate copies toward D->E link
 - Packets arrive later from west ((pw1 and pw2 from 0->A->F->E->D)
   * both have been seen already -> eliminate
 - As a conclusion, if packets have been seen earlier independent of the ingress ring direction they get eliminated.

Multicast distribution in a ring is still a multicast _tree_ distribution. This means that if a packet for some reason manages to make a full round around the ring, it will be dropped. Example a packet from 0->B->C->D->E->F won’t anymore be forwarded from F to A.

More on the agreed label & naming conventions (also reflected in the update slides from Norm):
 - L-labels connect MS-DetNet-PW PEs. They can also be implicitly used to “code” the ring direction or whether FRER processing takes place or not. There is no need to have a specific indication whether some labels are going east or west (like in some protocols sequence numbers carry such information).
 - T-labels (or label stack) are “just” transport tunnel labels
 - d-id labels are identity labels that are _unique_ to each PW source system wide. There’s _one_ d-id per MS-DetNet-PW PE, which is configured by the network administration. These d-id labels are supposed to be used to avoid d-pw collisions in dynamic control plane cases.
- d-pw labels are PW labels.

Regarding d-id labels we had a short discussion why they were needed again. Loa & Jouni explained how something is needed to avoid collision of d-pw labels in a case dynamic control plane. Loa has that with animation in his slides. Having d-pw ranges configured in MS-DetNet-PW PEs would do the same (this is the approach used by segment routing anycast - see draft-ietf-spring-mpls-anycast-segments) and not needing the d-id label. d-pw ranges have had the concern of not scaling in a large metro environment. On the other hand d-id “identity” labels are not defined in IETF _yet_. There is a framework coming up (see draft-ietf-mpls-flw-ident).

Jouni expressed a quick concern about the stack depth. The minimum we have now is three labels.

Jouni reminded again to think again whether 16 bit sequence number is enough in high link speeds. However, we’ll keep the sequence number as 16 for now.

The draft of the DT draft has been in github for a while. Obviously it is a bit behind the current discussion.


-- 
Jouni Korhonen, Broadcom Ltd., Core Switching Group
M: [phone]