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

["Norman Finn (nfinn)" <[e-mail]>]

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.  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.

>To relay system, add "transit node" to the list.
>
>Add:
>
>  DetNet node
>        A DetNet aware end system or relay system.
>        "DetNet" may be omitted in some text.
>
>  DetNet domain
>        The portion of a network that is DetNet aware.  It includes end
>systems,
>        and other DetNet nodes.
>
>  link
>    A connection between two DetNet nodes.  It may be composed of a
>physical link
>    or a sub-network technology that can provide appropriate traffic
>delivery for DetNet
>    flows.
>
>Section 3.
>
>add to (c).  "This function is also know as 1+1 protection, e.g., see
>[RFC6372]."
>
>Section 3.1
>
>    this section should mention allocation and scheduling or resources
>that might otherwise be over subscribed and trigger congestion loss.
>
>Section 3.2
>
>Might be worth mentioning that pinned paths are commonly used in MPLS TE
>LSPs.
>
>Section 3.3
>
>- This section should reference that "Seamless Redundancy as defined in
>this section is also known as 1+1 hitless protection."
>
>- Adding sequence number isn't and architectural requirement, but rather
>one *example* way to implement Seemless redundancy.
>
>
>- 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.

>- 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?

>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
>
>