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

["Pascal Thubert (pthubert)" <[e-mail]>]

I agree with Lou:

The UNI is control plane. The trouble I had here is that is it an exchange between the network node and the end system, not over the southband interface like the flow setup. How should be characterize this?

Cheers,

Pascal


> -----Original Message-----
> From: Norman Finn (nfinn)
> Sent: jeudi 17 mars 2016 04:03
> To: Lou Berger <[e-mail]>; [e-mail]
> Cc: Pascal Thubert (pthubert) <[e-mail]>
> Subject: Re: [Detnet] draft-finn-detnet-architecture-03 comments??
> 
> 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-0
> >>>3.t
> >>>x
> >>>t
> >>>
> >>>
> >>> — Norm
> >>>
> >>> _______________________________________________
> >>> detnet mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/detnet
> >>
> >>
> >