Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Thu, 17 Mar 2016 03:34:40 +0000

Thanks for the review!  Responses in-line.

— Norm

-----Original Message-----
From: detnet <[email-masked]> on behalf of zhayiyong
<[email-masked]>
Date: Wednesday, March 16, 2016 at 15:32 PM
To: Norman Finn <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??

>Hi Norm,
>
>Thank you for your effort on architecture draft. I believe it is a good
>work that covers almost every aspects of a working system of DetNet. I
>have some questions as follows.
>Section 3:
>Three candidate techniques are listed. Does that mean the WG is focused
>how to use these techniques to guarantee for example delay and loss? For
>pinned path, are we going to define routing mechanism to setup redundant
>paths or just utilize existing management protocols to manage? Maybe
>first step we can focus on a fixed path scenario.

I think a lot of people already have a pretty good idea how to use these
techniques; there are several standards out there from IEEE 802 and IEC
SC65C that are deployed, already.  Architecture and WG focus are two
different things.  Pinned paths are needed by the architecture.  I think
it’s up to other WG documents to define by which and how many ways we get
them.  I’m biased towards defining nothing ourselves, and just calling out
others’ work.

Is there something in the document text that you think should be changed,
here?

>Section 4:
>4.1: 
>There are a lot of models been discussed here. In my opinion, some of
>them are close related that can be represented using one model, some are
>dependent on specific technique being used which is not easy to model. So
>maybe all the models can be classified as: service model to define the
>northbound interface for service provisioning; device model/configuration
>model to define the southbound interface; information model and data
>model of DetNet flow to represent the DetNet flow that is used by control
>plane. Thus, YANG can be used to model service model,
>device/configuration model and DetNet flow data model. Info model is to
>guide the design of data model and does not have to be YANG.

I agree; there are too many bullets in this section.  I’ll try to trim
this down.  Don’t know if I can get just 3, but I’ll try.

> 
>4.2:
>To me, an centralized SDN controller based architecture is introduced.
>But in open question peer-to-peer protocol is still mentioned in case of
>distributed architecture. Maybe we can use controller-based architecture
>but still adopt some distributed protocols. For example, using central
>controller for some job that needs global information such as PCE and
>routing, while using distributed protocols to reserve resource so the
>DetNet flow does not have to wait the communication between controller
>and NEs.

At this level, it may be premature to make an architectural
differentiation between a central controller that manages relay systems in
response to a request, and a central controller that instructs an end
system or edge relay system to initiate a peer-to-peer exchange, as with
PCE and RSVP-TE.

See below, section 6.  I think there might be something I can change to
help answer this issue.

>4.5:
>Resource sharing is only allowed between DetNet flow and normal flow. All
>DetNet flows are scheduled with resource that cannot be shared among
>DetNet flows. And correct me if I am wrong, burstness is not taking into
>account as it suppose shaping can solve this. And one more question can
>be schedulability problem, with given flows with delay requirements and
>given resource, can the requirements be meet?

It depends on the details of the low-level shapers/queues/schedulers
employed, but in general, some resources (e.g. Buffers) can often be
shared among DetNet flows, some (e.g. Bandwidth) cannot.  I’ll try to use
your comments to clarify this.

>Section 6:
>For the open question, we would like to do more on flow identification
>and peer-to-peer reservation protocols.

I will mention, in 6.4 Peer-to-peer reservation protocol, the ideas
mentioned above, in your comment on 4.2, and something about the UNI in
4.2.3 that was mentioned by Lou Berger.

>Cheers,
>Yiyong Zha
>
>-----Original Message-----
>From: detnet [mailto:[email-masked]] On Behalf Of Norman Finn
>(nfinn)
>Sent: Thursday, March 10, 2016 7:29 AM
>To: [email-masked]
>Subject: [Detnet] draft-finn-detnet-architecture-03 comments??
>
>In our plan from November, we talked about adopting an architecture draft.
>There is a draft for one, and time comment and revise it before the
>deadline for April.  Is it so good there is nothing more to say?  :)  :)
>
>https://www.ietf.org/internet-drafts/draft-finn-detnet-architecture-03.txt
>
>
>— Norm
>
>_______________________________________________
>detnet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/detnet
>_______________________________________________
>detnet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/detnet

---

From: zhayiyong <[email-masked]>
Date: Fri, 18 Mar 2016 09:05:49 +0000

Thank you for the clarification. Please find my responses in-line with [zyy].

Regards,
Yiyong

-----Original Message-----
From: Norman Finn (nfinn) [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 11:35 AM
To: zhayiyong; [email-masked]
Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??

— Norm

-----Original Message-----
From: detnet <[email-masked]> on behalf of zhayiyong <[email-masked]>
Date: Wednesday, March 16, 2016 at 15:32 PM
To: Norman Finn <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??

>how to use these techniques to guarantee for example delay and loss? 
>For pinned path, are we going to define routing mechanism to setup 
>redundant paths or just utilize existing management protocols to 
>manage? Maybe first step we can focus on a fixed path scenario.

I think a lot of people already have a pretty good idea how to use these techniques; there are several standards out there from IEEE 802 and IEC SC65C that are deployed, already.  Architecture and WG focus are two different things.  Pinned paths are needed by the architecture.  I think it’s up to other WG documents to define by which and how many ways we get them.  I’m biased towards defining nothing ourselves, and just calling out others’ work.

Is there something in the document text that you think should be changed, here?
[zyy] I am fine with the document text. It will be better if we clearly define how to use these techniques. 
>them are close related that can be represented using one model, some 
>are dependent on specific technique being used which is not easy to 
>model. So maybe all the models can be classified as: service model to 
>define the northbound interface for service provisioning; device 
>model/configuration model to define the southbound interface; 
>information model and data model of DetNet flow to represent the DetNet 
>flow that is used by control plane. Thus, YANG can be used to model 
>service model, device/configuration model and DetNet flow data model. 
>Info model is to guide the design of data model and does not have to be YANG.

I agree; there are too many bullets in this section.  I’ll try to trim this down.  Don’t know if I can get just 3, but I’ll try.
[zyy] Definitely we need more discussion on what kind of model and how to model it. And I would like to contribute on that. 
>But in open question peer-to-peer protocol is still mentioned in case 
>of distributed architecture. Maybe we can use controller-based 
>architecture but still adopt some distributed protocols. For example, 
>using central controller for some job that needs global information 
>such as PCE and routing, while using distributed protocols to reserve 
>resource so the DetNet flow does not have to wait the communication 
>between controller and NEs.

At this level, it may be premature to make an architectural differentiation between a central controller that manages relay systems in response to a request, and a central controller that instructs an end system or edge relay system to initiate a peer-to-peer exchange, as with PCE and RSVP-TE.

See below, section 6.  I think there might be something I can change to help answer this issue.
[zyy] Maybe we can work on both as each one can be the winner for certain scenario. 

>4.5:
>Resource sharing is only allowed between DetNet flow and normal flow. 
>All DetNet flows are scheduled with resource that cannot be shared 
>among DetNet flows. And correct me if I am wrong, burstness is not 
>taking into account as it suppose shaping can solve this. And one more 
>question can be schedulability problem, with given flows with delay 
>requirements and given resource, can the requirements be meet?

It depends on the details of the low-level shapers/queues/schedulers employed, but in general, some resources (e.g. Buffers) can often be shared among DetNet flows, some (e.g. Bandwidth) cannot.  I’ll try to use your comments to clarify this.
[zyy] Also, I believe it is related to how model the DetNet flow.
>and peer-to-peer reservation protocols.

I will mention, in 6.4 Peer-to-peer reservation protocol, the ideas mentioned above, in your comment on 4.2, and something about the UNI in
4.2.3 that was mentioned by Lou Berger.

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Mon, 21 Mar 2016 16:02:21 +0000

Yiyong,

I’ve been working on the document last week and this.  I really think that
the number of bullets in section 4.1 needs to be reduced.  But, there are
references to sections that talk about these models, and I just don’t have
time to make this change before the deadline.  We’ll have to do that on
the next version.

- Norm

-----Original Message-----
From: detnet <[email-masked]> on behalf of zhayiyong
<[email-masked]>
Date: Friday, March 18, 2016 at 02:05 AM
To: Norman Finn <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??

>them.  I’m biased towards defining nothing ourselves, and just calling
>out others’ work.
>
>[zyy] Definitely we need more discussion on what kind of model and how to
>model it. And I would like to contribute on that.
>> 
>>4.2:
>differentiation between a central controller that manages relay systems
>in response to a request, and a central controller that instructs an end