Re: [Detnet] Implementing the discussion at IETF 97 on architecture doc

Hi Jouni,

Recently, the relationship between DetNet Service Model and data plane design is being discussed in the mailing list. To make it clear, I have reviewed the related discussion before and make a simple summary：

In IETF 94th, “DetNet Data Plane using PseudoWires” gives a basic idea of the classification of the service model (although the word “service model” is not mentioned in the slides): 
1.	Ethernet over MPLS for 802.1CB packets
2.	Ethernet over MPLS for non-802.1CB Ethernet packets
3.	Packet PW encapsulation over an MPLS PSN for IP packets
The data plane solution of 1 is different from 2 and 3

In IETF 97th, “DetNet Data Plane Discussion” gives four types of service models:
1.	DetNet End-to-end
2.	TSN interconnect, connecting two L2 TSN islands
3.	Service translation, from L2 TSN to DetNet and vice versa
4.	Service interworking ,connecting TSN end systems to DetNet end systems
And the data plane solution of these four cases are different from each other.

In IETF 97th, “DetNet Service Model” gives service models based on three types of the flows:
1.	App-flow: native format of a DetNet flow. It does not contain any DetNet related attributes
2.	DetNet-s-flow: specific format of a DetNet flow.  It is an App-flow extended with some DetNet service related attributes (i.e., Flow-ID and/or Seq-num).
3.	DetNet-st-flow: specific format of a DetNet flow.  It is an App-flow extended with both DetNet service layer and DetNet transport layer attributes, i.e., encapsulated according to the forwarding paradigm of the DetNet domain.

So I am confused whether we have already got to a conclusion about the service model classification, especially the influence it may have on the data plane.

If not, I think we should get to some degree of agreement about the service model before data plane design, or the data plane may not comfort to the DetNet service model in the current draft.

Emma

-----Original Message-----
From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, March 10, 2017 2:39 AM
To: Lou Berger; Pascal Thubert (pthubert); detnet@ietf.org
Cc: draft-ietf-detnet-architecture@ietf.org
Subject: Re: [Detnet] Implementing the discussion at IETF 97 on architecture doc

3/9/2017, 8:23 AM, Lou Berger kirjoitti:
>
>
> On 3/9/2017 11:11 AM, Pascal Thubert (pthubert) wrote:
>> Hello Lou:
>>
>> Did  section 3 evolve since the publication in September?
> Not that I know of - but Jouni would know for sure.

Nope.

>
>> Will there be an 01 of the dp alt draft before cutoff Monday?
> I don't expect on.

and nope. i do intend to finish the -alt draft but not for the next meeting.

- Jouni

>
> Lou
>
> PS for source, see
> https://github.com/jounikor/draft-dt-detnet-dp-alt/blob/master/draft-i
> etf-detnet-dp-alt-00.xml
>
>> Take care,
>>
>> Pascal
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: jeudi 9 mars 2017 15:13
>> To: Pascal Thubert (pthubert) <pthubert@cisco.com>; 
>> jouni.korhonen@broadcom.com; detnet@ietf.org
>> Cc: draft-ietf-detnet-architecture@ietf.org
>> Subject: Re: [Detnet] Implementing the discussion at IETF 97 on 
>> architecture doc
>>
>> Pascal,
>>
>>     Another thing to consider bringing into the Architecture document are some of the diagrams and related text from Section 3 of 	.  I think the whole section, with the exception of the last two paragraphs on page 5, is good text to bring over.
>>
>> Lou
>> (as contributor, co-author of dp-alt)
>>
>> On 3/9/2017 3:06 AM, Pascal Thubert (pthubert) wrote:
>>> I agree, Jouni,
>>>
>>> we seem to be placing the horses before the cart.
>>> Let us comment out that text for now.
>>>
>>> Take care,
>>>
>>> Pascal
>>>
>>> -----Original Message-----
>>> From: Jouni Korhonen [mailto:jouni.korhonen@broadcom.com]
>>> Sent: mercredi 8 mars 2017 21:37
>>> To: Pascal Thubert (pthubert) <pthubert@cisco.com>; detnet@ietf.org
>>> Cc: draft-ietf-detnet-architecture-all@tools.ietf.org
>>> Subject: Re: [Detnet] Implementing the discussion at IETF 97 on 
>>> architecture doc
>>>
>>> Hi,
>>>
>>> [snip]
>>>
>>>> 4.9.2.  Flow attribute mapping between layers
>>>>
>>>>
>>>>    Transport of DetNet flows over multiple technology domains may
>>>>    require that lower layers are aware of specific flows of higher
>>>>    layers.  Such an "exporting of flow identification" is needed each
>>>>    time when the forwarding paradigm is changed on the transport path
>>>>    (e.g., two LSRs are interconnected by a L2 bridged domain, etc.).
>>>>    The three main forwarding methods considered for deterministic
>>>>    networking are:
>>>>
>>>>    o  IP routing
>>>>
>>>>    o  MPLS label switching
>>>>
>>>>    o  Ethernet bridging
>>>>
>>>>    The simplest solution for generalized flow identification could be to
>>>>    define a unique Flow-ID triplet per DetNet flow (e.g., [IP: "IPv6-
>>>>    flow-label"+"IPv6-address"; MPLS: "PW-label"+"LSP-label"; Ethernet:
>>> The discussion on this part has not yet completed in DP design team. I am a bit worried writing this specific part down before we actually know how we are going to implement on the data plane. The above is not, as far as I understand, aligned with the DT progress. To get around the chicken-egg thing here either defer documenting for now or emphasize more that the above is an example.
>>>
>>> - Jouni
>>>
>>>>    "VLAN-ID"+"MAC-address").  This triplet can be used by the DetNet
>>>>    encoding function of technology border nodes (where forwarding
>>>>    paradigm changes) to adapt to capabilities of the next hop node.  It
>>>>    means that a packet may contain multiple (forwarding paradigm
>>>>    specific) Flow-IDs during its transport.  Technology border nodes may
>>>>    add / remove a (forwarding paradigm specific) Flow-ID.
>>> [snap]
>>>
>>>> What do you think?
>>>>
>>>>
>>>>
>>>> Pascal and Norm
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> detnet mailing list
>>>> detnet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>
>>> _______________________________________________
>>> detnet mailing list
>>> detnet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/detnet
>>>
>>
>

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet