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

[Lou Berger <[e-mail]>]

Norm,
   Thanks for the response.  See below.

On 3/16/2016 10:39 PM, Norman Finn (nfinn) wrote:
> Lou,
>
> Thank you for the comments.  They look very useful.
>
> I don’t see any open-ended comments, here, and they make sense.  I’ll
> incorporate at least most of your comments (and a few others — see other
> emails) today, and upload a new version for adoption before the deadline.
> Exactly which and how many comments depend on how much interaction we
> managed to have before Monday.
>
> A few comments/questions for you in-line, below.  Assume remarked comments
> are fine with me.
>
> — Norm
>
> -----Original Message-----
> From: Lou Berger <[e-mail]>
> Date: Wednesday, March 16, 2016 at 05:56 AM
> To: Norman Finn <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??
>
>> Hi Norm/Authors,
>>    I reviewed your document and have some comments.  These comments can
>> be addressed now or once the document becomes a WG document (your choice):
>>
>> - First let me say this is a great start and very much appreciated!
>>
>> Section 2:
>> - general point: I think it would be good to separate into their own
>> subsection, e.g., 2.1,  terms that are listed for the sole purpose of
>> translating between IEEE 802 and DetNet terminology, e.g., listener and
>> relay, and keeping terms used throughout the document in the main section.
>>
>> OLD
>>   end system
>>           Commonly called a "host" in IETF documents, and an "end
>>           station" is IEEE 802 documents.  End systems of interest to
>>           this document are either sources or destinations.
>> NEW
>>   end system
>>           Commonly called a "host" or "node" in IETF documents, and an
>> "end
>>           station" is IEEE 802 documents.  End systems of interest to
>>           this document are either sources or destinations. Note that a
>> system that
>>           takes non-DetNet aware traffic and transmits it via a DetNet
>> flow is also an
>>        end system.  (For comparison, a Label Edge Router (LER) would be
>>        an MPLS "end system".)
>>
>> Question: Do we need a term of the DetNet equivalent of an LER
> Interesting question.  I don’t think I’d put that in, without some more
> discussion.  We have the concept in P802.1CB of the end system DetNet
> functions as a lump that can be on either end of the wire connecting the
> end system to the first relay system. 
lump; cool, a new networking term -- a rare commodity!  (In MPLS speak,
I believe this is an LER.  In MPLS-TP and LxVPN contexts, this is a PE
when the CE doesn't talk MPLS).

>  So, is a relay system with 1000
> ordinary relay system DetNet ports and one lump an LER?  If the one port
> configured for that capability is down at the moment?  Well, yes, but it’s
> also, and mostly, a relay system.  I need to get a better feel for what an
> LER is/isn’t before I add that to the document, so I don’t say something
> stupid.  I don’t know if there is time before the deadline.
That's fine.  The document isn't even a -00 WG draft so there is time to
work this out.

> ...
> - section 4.1
> s/provisioning by relay systems and end systems sharing peer-to-peer
> protocols/via control plane protocols (running on relay systems and end
> systems)
>
> - Section 4.2.3
> s/The Network Plane/The Network Plane, which is also commonly referred
> to as the data plane,
> I don’t think that’s what Pascal meant, here.  As I read it, the intention
> here is that the Network plane includes nailed-down paths that DetNet
> flows might use.  It would also include the RSVP-TE that might be used to
> nail that path down.

Humm, I included RSVP-TE and other control plane protocols as part of
the controller plane.  The differences to me there is off-path
(logically centralized) vs on-path (fully distributed) control. See mote
on this below.

>> - Section 4.2.3, second paragraph
>>    to me UNIs and NNIs are as much about the control plane as the data
>> plane (see RFC5921 for examples and figures).  I'm not sure if this is
>> what you intended or not, but scope should be clarified. Either way 5921
>> is probably a better reference than 3209.
> The Network Plane includes both control and data aspects.  The usage here
> is that UNI and NNI are definitely control plane.  That’s how I’m used to
> using those terms over the years in ATM, ITU-T, and IEEE.  Is that
> different in IETF?

I think I just don't understand these new terms.  I get management,
control, data and even policy planes.  I don't understand the
distinction being drawn by these new terms.  Looking at Figure 2, I
clearly see (and understand) the Application, Control, Management
planes.  Where things get fuzzy is in the 'Network Device' box (which is
not labeled as a plane -- a good thing).  In it I see the Forwarding
Plane, and the Operational Plane.  How about this: change "Network
Device" to "Data Plane",  "Forwarding Plane" to "Forwarding",
"Operational Plane" to "OAM" .  ( per the charter OAM = Operations,
Administration, and Maintenance)  And then after the figure add some
text along the lines of:
    The presented figure is logical view, and actual protocols and
    implementation platforms are not shown.  For example the Control
    Plane may be implemented via: a fully distributed control plane
    running on network devices, e.g., as found in some MPLS
    implementations; a fully centralized "SDN" controller; or a hybrid
    approach where some control functions are distributed to the network
    devices and others reside in a more centralized controller, e.g.,
    stateful PCE. 

I understand that this is a departure from the pure SDN model presented
in 7426, but DetNet isn't so narrowly scoped so it's architecture
document shouldn't be either.

The rest of the section will then need to be tweaked to line up with
these changes.

Thanks,
Lou

>> Section 4.5
>> s/not interfere excessively/coexist with
>> s/QoS/Class of Service (e.g., DiffServ)
>>
>> Section 4.7
>>
>> - Add after the 1st sentence. "It may serve as the foundation for the
>> DetNet model which will be defined by the working group."
>>
>> Section 4.8
>> s/a central controller/a central controller or decentralized control plane
>>
>> Section 4.9.2
>> s/[RFC5127]/[RFC3209] or [RFC3473]
>>
>> also at end of section add:
>> "The integration/interaction of the DetNet control layer an underlying
>> IEEE 802.1 sub-network control layer will need to be defined."
>>
>> Section 4.11
>> s/Layer-2 tunnels/Layer-2 connections
>> or
>> s/Layer-2 tunnels/Layer-2 VPNs
>>
>> Section 5.
>>
>> I think there's an additional point to be made, here's some suggested
>> text:
>>
>> All DetNet enabled systems and nodes will be interconnected by
>> sub-networks, i.e., Layer 2 technologies. These sub-networks will
>> provide DetNet compatible service for support of DetNet traffic.
>> Examples of sub-networks include 802.1TSN and a point-to-point OTN link.
>> Of course, multi-layer DetNet systems may be possible too, where one
>> DetNet appears as a sub-network, and provides service to, a higher layer
>> DetNet system.
>>
>> That's it for now.
>>
>> So do you want to do an update before a WG adoption call or would you
>> prefer to address my comments in a -01 rev of the WG document?
>>
>> Thanks,
>> Lou
>>
>>
>> On 3/9/2016 6:29 PM, Norman Finn (nfinn) wrote:
>>> 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.tx
>>> t
>>>
>>>
>>> — Norm
>>>
>>> _______________________________________________
>>> detnet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/detnet
>>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet