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

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

Ah!  I think I see the problem in 4.2.3 — The text doesn’t mention that
the data plane is part of the network plane.

Pascal?

— Norm

-----Original Message-----
From: Norman Finn <[e-mail]>
Date: Thursday, March 17, 2016 at 10:39 AM
To: Lou Berger <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: Pascal Thubert <[e-mail]>
Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??

>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.t
>>>x
>>>t
>>>
>>>
>>> — Norm
>>>
>>> _______________________________________________
>>> detnet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/detnet
>>
>>
>