Subject: [Detnet-dp-dt] Quick notes from 4/11/17 call

From: Jouni Korhonen <[email-masked]>
Date: Wed, 12 Apr 2017 13:35:37 -0700

Present: Jouni, Janos, Balazs, David, Loa, Norm, Yuanlong

Agenda:
* recap of the IETF98 corridor discussions & descisions
* list of things to do

Discussion & decision:
* Jouni sent out RFC6621 pointer for Simplified Multicast Forwarding that does duplicate detection and elimination
* Solutions draft:
 - update the PW encapsulation i.e., no Flow-ID and incoming PW labels have to be the same to trigger the duplicate detection. 
 - IPv6 use flow label for detnet flow identification, new extension header for seqnum.
 - on IPv6 path stitching policy routing, multicast with with proper distribution tree and segment routing were discussed as possible alternatives instead of tunneling. Needs more discussion.
 - no good solution for IPv4. Just left it out. One can use PWs to transport IPv4 as a packet PW.
 - CoS/QoS update to be done. CoS is “easier” to start with.. first describe how the TC or DSCP bits need to be brought all the down to the most outer level.
* Alternatives draft (now expired):
 - update the conclusions to state PW + IPv6 (native IP mode) are way to go. No good solution for IPv4.
* Problem Statement:
 - Norm will ship an update.
* Webex time will change. It will be Tuesday 6AM Pacific starting from next call.
* solutions and alternative draft updates hopefully out this week.

Next call:
 no call next week 4/18/17.

-- 
Jouni Korhonen, Broadcom, Core Switching Group
+1-408-391-7160

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 13 Apr 2017 01:31:01 +0000

Hi Jouni,

Many thanks for the notes. It is quite a good progress IMO.
But could you give some more hints on the point "incoming PW labels have to be the same to trigger the duplicate detection"?
I missed the discussion on this point, but as shown in my previous slides:
1. Multiple PW labels can be mapped to the same duplicate detection module.
2. If a DA-S-PE receives the same PW label from both DA-T-PE and its peer DA-S-PE, the traffic from them will be indistinguishable, and traffic from the peer DA-S-PE will be looped on the S-PE in some cases. As a result, duplicate detection on the peer S-PE will become more challenging.

Thanks,
Yuanlong

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Thursday, April 13, 2017 4:36 AM
To: [email-masked]
Subject: [Detnet-dp-dt] Quick notes from 4/11/17 call

Agenda:

Discussion & decision:

Next call:

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

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 13 Apr 2017 08:36:05 -0700

Hi Yuanlong,

Comments inline.

> On Apr 12, 2017, at 6:31 PM, Jiangyuanlong <[email-masked]> wrote:
> 
> Hi Jouni,
> 
> But could you give some more hints on the point "incoming PW labels have to be the same to trigger the duplicate detection”?

In Chicago discussion we agreed that incoming PWs for a given detnet flow need to have the same PW labels to trigger PREF. Labels can be different on each segment and direction, though. This is what we agreed.

> 2. If a DA-S-PE receives the same PW label from both DA-T-PE and its peer DA-S-PE, the traffic from them will be indistinguishable, and traffic from the peer DA-S-PE will be looped on the S-PE in s…

The labels below PW label are still different when a packet arrives from DA-T-PE and peering DA-S-PE. I do not see the issue.
Also, what are “some cases” for looping you refer here?

Thanks,
	Jouni

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 14 Apr 2017 06:06:53 +0000

Jouni,

I have some slides for your consideration. The loopback will be introduced if we use the same PW labels to trigger PREF.
My opinion is, we can regard the PW between peering DA-S-PEs as the normal segment PW, and it is unnecessary to use the same PW label.

Thanks,
Yuanlong

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Thursday, April 13, 2017 11:36 PM
To: Jiangyuanlong
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] Quick notes from 4/11/17 call

Hi Yuanlong,

Comments inline.

Thanks,
	Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 13 Apr 2017 23:31:27 -0700

Thanks,

Comments following.  Current draft actually defines the serial model for PREF because I do not see how the parallel model would work. If that is not immediately visible, then the text is just not clear enough.

I do not understand the slide 5. If the replicated traffic is supposed to be going out from  port 2, d-pw1 failure appears as “packets coming always late” and should not make any difference to the elimination & replication logic. What is the issue?

Another thing is that we agreed packets for elimination to have the same label i.e., packets coming from port 3 for elimination should have d-pw1 as their label. 

- Jouni

> On 13 Apr 2017, at 23:06, Jiangyuanlong <[email-masked]> wrote:
> 
> Jouni,
> 
> <detnet-Yuanlong4.ppt>_______________________________________________

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 14 Apr 2017 08:07:01 +0000

Thanks,

Comments following.  Current draft actually defines the serial model for PREF because I do not see how the parallel model would work. If that is not immediately visible, then the text is just not clear enough.
[JY] Yes, we only need to consider serial mode. Perhaps we need some text or a figure to clarify it.

I do not understand the slide 5. If the replicated traffic is supposed to be going out from  port 2, d-pw1 failure appears as “packets coming always late” and should not make any difference to the elimination & replication logic. What is the issue?
[JY] No problem for port 2 indeed. The concern is on port 3, slide 6 gives an analysis. If the sequence numbers of the loopback packets overrun the new packets on DA-S-PE2, all new packets may be filtered by the Elimination.  
Therefore, the consequence is a severe restriction on the maximum Detnet flow rate.

[JY] slide 8 part 2 gives a summary: 
If the same label value is used:
- It is impossible to implement this "Replicate first and then Eliminate" in a single PW layer for FRER 
- Though we can use the underlay LSP/tunnel or even physical interfaces as a differentiator
  - But it needs to map 2-tuple (LSP, PW) to FRER index, and needs inter-layer processing which may be somewhat complex
I think it may be worthwhile to reconsider these two options. 

Thanks,
Yuanlong

- Jouni

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 14 Apr 2017 08:44:32 +0000

In a VPLS, all incoming PW labels for a PE can be different, and the PE can direct all these incoming PWs to the same VSI.
I can't see why Detnet must use the same PW label. Are we trying to save some labels or some mapping table items (i.e., PW lable->FRER index)?

Thanks,
Yuanlong

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jiangyuanlong
Sent: Friday, April 14, 2017 4:07 PM
To: Jouni Korhonen
Cc: Lou Berger; [email-masked]
Subject: Re: [Detnet-dp-dt] Quick notes from 4/11/17 call

Thanks,

  - But it needs to map 2-tuple (LSP, PW) to FRER index, and needs inter-layer processing which may be somewhat complex I think it may be worthwhile to reconsider these two options. 

Thanks,
Yuanlong

- Jouni

>> * Jouni sent out RFC6621 pointer for Simplified Multicast Forwarding 
>> that does duplicate detection and elimination
>> * Solutions draft:

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 17 Apr 2017 11:07:36 -0700

Hi,

More stuff inline ;)

> On Apr 14, 2017, at 1:07 AM, Jiangyuanlong <[email-masked]> wrote:
> 
> Thanks,
> 

Honestly, I am still unclear about your issue. Two things first:
1) it should not be specified in IETF in which order you do the elimination and replication. As long as the external behavior i.e., packets on-wire appear correctly and in right amounts it is up to the implementation to define its internal operations.
2) sequence number size is another discussion. So far we settled for 16 bits due backward and other interoperability concerns. I defer to Norm here mostly when it comes to “why”.

From slide 6:
It seems “Eliminate first and then replicate” has some disadvantages:
 * Traffic loopback happens on both DA-S-PE1 and DA-S-PE2 (if d-pw1 fails)
  o There is no harm to DA-S-PE1 except normal bandwidth expense

[JiK] you any way need to have these two flows going both directions (in this ladder scenario, I recall) so the total bandwidth seen by the system should be the same.

  o But, DA-S-PE2 needs to eliminate the looped detnet flow by its sequence number

[JiK] All packets that belong to the same detnet flow share the same sequence number space - pw labels may differ for the same detnet flow on each segment, though. So whether the packet is looped back or not has the sequence number from the same number space.

    - if the delay of the loopback packets is large enough (e.g., in 10us), then the sequence number (16bits) may wrap up easily on DA-S-PE2 (if detnet flow rate > 100Mbps)!

[JiK] Size of the sequence number is another larger topic, and not specific to this issue.

    - the loopback packets provide no enhancement to the service (all packets are already seen by DA-S-PE2, thus should be eliminated as soon as possible)

[JiK] The figure in slide 5 shows d-pw5 going up and down between DA-S-PE1 and -PE2. This does not need to be the case and most likely is not the case. It would be more appropriate to name them e.g., as d-pw5 and d-pw6.

> - It is impossible to implement this "Replicate first and then Eliminate" in a single PW layer for FRER 

[JiK] That’s then a shortcoming for the solution you propose..? Again, the ordering of the elimination & replication should not be standardized by IETF as it is internal behavior. 

> I think it may be worthwhile to reconsider these two options.

[JiK] Well.. we had all these discussions how to identify the flow at the PW layer and how to associate the sequence number to the proper instance. Explicit flow-id exactly did this in a uniform manner but it was voted down in IETF98 discussions.

[JiK] Also, remembering the “label stack” history does not help.. the same 20 bit labels space independent how many labels your stack has, just think e.g., how FRR works. The safe way is just assume that only the last label (the PW label) maps to the PREF index. 

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 17 Apr 2017 15:00:36 -0700

I have been editing the solutions draft.. I am stuck again on the “native detnet flow”. I am not too happy about having two solutions for the sequencing part. IMHO is it a already enough we have two different PSNs. What we agreed below means:

+-------------------------+
| Payload e.g. UDP or TCP |
+-------------------------+
|   SeqNum DST(?) option  | (min 8 octets) -> not seen by the application
+-------------------------+
| IPv6 (flow label for id)|
+-------------------------+
|        Data-Link        |     
+—------------------------+
|        Physical         |     
+-------------------------+

Would it be desired to do PREF on each router how? Or only on desired designated hops? For the former the seqnum would be a HBH and the latter a DST option. A destination option could be replaced by a SR option’s TLVs. However, SR option as such is a monster and I would avoid a normative reference to it. I have also some difficulty seeing how this approach would work nicely with policy routing in a deployment where there are multiple replication/elimination points in the network between end hosts. You would need something like SR option for that to work and then your packet size would explode.

Using MPLS in IP encaps for the native detnet flow:

+-------------------------+
| Payload e.g. UDP or TCP |
/-------------------------\
H        DetNet CW        H (4 octets)  -> not seen by the application
+-------------------------+
H        PW Label         H (4 octets - redundant but for the consistency) -> not seen by the application
+-------------------------+
H     Optional Labels     H (0 to 4*n octets) -> not seen by the application
\-------------------------/
| IPv6 (flow label for id)|
+-------------------------+
|        Data-Link        |     
+—------------------------+
|        Physical         |     
+-------------------------+

No difference on the minimum overheads. 

Based on the fact that both approaches need “new stuff” they would fail equivalently on non-upgraded intermediates. The application programming model for the MPLS over IP is a bit different than usual, since the final “next header” is based on the bottom of the stack label, not the next header fields. I would say it is transparent to the developer, though.

Any thoughts?

- Jouni

> On Apr 12, 2017, at 1:35 PM, Jouni Korhonen <[email-masked]> wrote:
>

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 19 Apr 2017 08:38:53 +0000

Hi Jouni,

Please see my further comments inline:)

Thanks,
Yuanlong

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Tuesday, April 18, 2017 2:08 AM
To: Jiangyuanlong
Cc: Lou Berger <lberger@labn. net>; [email-masked]
Subject: Re: [Detnet-dp-dt] Quick notes from 4/11/17 call

Hi,

More stuff inline ;)

[JY] I think the problem is, whether we should give some details on the PREF scenario, the PREF function and the on-wire appearance. Currently our draft gives no hint how two DA-S-PEs protect the Detnet flow, the value of PREF on DA-S-PE is unclear, the function itself is also ambiguous.
From my slide, it clearly shows packets on-wire will be abnormal (i.e., packets are looped) if an implementation uses "Eliminate first and then replicate". I have no issue with a 16-bit sequence number, since we can restrict the maximum of the LSP's fiber length so that the influence of physical paths can be minimized.

From slide 6:

[JY] Agreed.

[JY] Agreed.

[JiK] Size of the sequence number is another larger topic, and not specific to this issue. 
[JY] But loopback can be avoided if "Replicate first and then Eliminate". 

[JiK] The figure in slide 5 shows d-pw5 going up and down between DA-S-PE1 and -PE2. This does not need to be the case and most likely is not the case. It would be more appropriate to name them e.g., as d-pw5 and d-pw6.
[JY] In control plane, they can be regarded as a bidirectional PW. Though in data plane, I agree with you that naming them as d-pw5 and d-pw6 is appropriate.

[JiK] That’s then a shortcoming for the solution you propose..? Again, the ordering of the elimination & replication should not be standardized by IETF as it is internal behavior. 
[JY] Not sure what particular solution you are referring to. My favorite would be using different PW values for d-pw1 and d-pw5, and "Replicate first and then Eliminate". 
But I am open to other solutions if they are valid. The discussion is mainly around whether we should mandate using the same label for d-pw1 and d-pw5, and my slides shows its implication on the PRER function ("Replicate & Eliminate"), not proposing to include the ordering in the draft. 

>  - But it needs to map 2-tuple (LSP, PW) to FRER index, and needs 
> inter-layer processing which may be somewhat complex I think it may be worthwhile to reconsider these two options.

[JY] Yes

[JiK] Also, remembering the “label stack” history does not help.. the same 20 bit labels space independent how many labels your stack has, just think e.g., how FRR works. The safe way is just assume that only the last label (the PW label) maps to the PREF index. 
[JY] Agreed, this will be simpler.

- Jouni