[homenet] I-D Action: draft-ietf-homenet-dncp-11.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Distributed Node Consensus Protocol Authors : Markus Stenberg Steven Barth Filename: draft-ietf-homenet-dncp-11.txt Pages : 39 Date: 2015-10-14 Abstract: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses the Trickle algorithm and hash trees. DNCP is an abstract protocol, and must be combined with a specific profile to make a complete implementable protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-homenet-dncp-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dncp-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)
Hello Alia, thanks for your detailed replies and suggestions. We have just released a new version which should improve upon the issues you have raised. Please find some more detailed comments inline. Cheers, Steven > I understand that but there were still a number of gaps. For instance, I see > nothing > that describes how to compute the network state hash. I would expect a > section like: I refactored the hash-tree section and created two subsections "Calculating network state and node data hashes" and "Updating network state and node data hashes" to make it more obvious. I also added a reference to the profile section wrt. hash-function and truncation as you suggested. > The draft has "Topology graph the undirected graph of DNCP nodes produced by > retaining only bidirectional peer relationships between nodes." > > In Section 4.6, I think that you are describing how to create the topology > graph, > rather than "traversing it". Updated this section as well, changed "traversing" to "updating". Added some more clarifications and an xref to the hash tree section. > > "Sec 4.5.1 Initiating Neighbor Relationships > > A DNCP profile MAY specify a multicast address on which each DNCP node MUST > listen to learn about new neighbors. If multicast discovery is specified in > the DNCP > profile, then when a node starts, it SHOULD send a Node Endpoint TLV to the > multicast > address using ??UDP??. > > In addition to or instead of multicast discovery, a node MAY be configured > with a > set of DNCP neighbors and the associated interfaces to use. When a node > needs to initiate > a neighbor relationship, that node SHOULD send a Node Endpoint TLV to the > unicast address > of the desired neighbor. Note that security considerations may influence > whether the relationship > is established." > > "Sec 4.5.2 Destroying a Neighbor Relationship > > A node can destroy an established neighbor relationship, regardless of > whether that node initiated > or responded to create the neighbor relationship. A node MUST send a Node > State TLV that does > not include the Node Endpoint TLV with the neighbor's Node Identifier and the > associated link's Endpoint > Identifiers. A node MAY information> as part of > terminating DNCP. I updated the section on peers and renamed it to "Discovering, Adding and Removing Peers". It should now clarify the points that I think were not obvious based on your suggestions. > > > > >> c) It looks like the TLVs are sent one after another in a datagram or > >> stream across a socket. The closest I see to any detail > >> is "TLVs are sent across the transport as is". > > > > Section “4.2 Data Transport” says > >TLVs are sent across the transport as is, and they SHOULD be sent > >together where, e.g., MTU considerations do not recommend sending > >them in multiple batches. TLVs in general are handled individually > >and statelessly, with one exception … > > > > Could you please be more specific on what is unclear? > > > > The section states that TLV handling is stateless except for the one > exception > > which is explained, so otherwise it does not really matter in what > order > > they are sent or how you split them up onto datagrams (if that is your > > transport). > > > At a minimum, you should specify "in network order" for how the TLVs are sent. Do you mean that numbers are sent in network byte order? That is already defined in the section on TLVs. I created a cross-reference there. > It would be good to specify whether TLVs need to be sent in any particular > order. That was one of the intentions of the stateless parsing sentence, however I added an explanation inside brackets mentioning ordering. > It'd be nice for the receiver to know whether there's a way of seeing that > the last > TLV in the message has been received so it's easier to avoid doing work > multiple > times. There are no special resending requirements. Reliability is either provided by using a reliable transport or based on Trickle. Clarified that. > When does a node decide to use unicast transport? When does the node decide > to use multicast transport? There are some indications about what is sent, > but > not in a very normative way. It should be quite normative already. The only TLV that is regularly sent over multicast or that is actively sent (not as a reaction to another packet) is the trickle-driven Network State TLV (accompanied by an Endpoint TLV). The section on "Trickle-Driven Status Updates" has MUST-statements on which transport (mc or uc) to use. All other TLVs are sent reactively over unicast. I added another clarification. > > When and how does a node take into consideration MTU? I know this is tied to > the profile, but it needs to be discussed here. Can a TLV be broken across > multiple packets? Added that fragmentation and reassembly is
Re: [homenet] Yang based host IP subsystem configuration for dynamic QoS management and service chaining purpose
Well, if you can figure out some way to make it interface properly with the cake code (successor to fq_codel), I'm all for it. http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical On Wed, Oct 14, 2015 at 4:00 PM, Maxim Klyus wrote: > Dear Netmod, Homenet and MIF. > > > > We are looking for a proper place to discuss attached materials within IETF. > > So I would like to say sorry we have to send this letter across several IETF > WGs simultaneously. > > > > The latest trends show that IP services are getting decoupled from the > traditional Service Provider (SP) networks. Subscriber can get a lot of > services from the 3rd party content providers typically delivered over > public networks, P2P services are also becoming more and more popular and > the main problem how to achieve service chaining and delivery with proper > QoS. > > We would like to propose to use Yang for exchange between Subscriber’s > Device and Service Provider’s. The Yang-modeled data is transferred over > NetConf protocol from end-user device activation/management software towards > a service agent software residing in Subscriber’s Device. This approach > allows Service Provider to identify subscriber uniquely and his QoS > requirements within the network with multiple IP interfaces on Subscriber’s > Devices. Multiple IP interfaces will be used for service distinction and > delivery within SP network. Host applications will be divided by application > groups and bounded to a specific IP interface. > > > > Short solution description: > > > > 1) When connecting to the network, Subscriber’s Device gets an IP address > through DHCP and IP of SP’s headend device management server through a DHCP > option. Alternative option is manual configuration of these IP settings; > Service Agent Software installed on Subscriber’s Device makes AAA request to > Service Provider’s configuration management headend software. Based on > request SP can uniquely identify subscriber and subscriber’s QoS > requirements. In case Device was authorized successfully, it gets a new IP > interface (Tunnel or Loopback) and additional configuration parameters > (e.g., routing, QoS). SP network also will be reconfigured dynamically to > meet appropriate service delivery KPIs , however static SP environment > configuration also possible with fixed QoS and bandwidth for each interface > based on predefined IP pool. > > > > 2) Different application groups can originate service requests from > different Host IP addresses. Service will be delivered to specific IP > addresses with appropriate additional handling within SP network and quality > of service. Subscriber’s device can periodically send application-group QoS > modification requests to allocate more/less priority or/and bandwidth for > existing application groups within SP network. > > > > Benefits and Applicability: > > > > - SP don’t need to know anything about external services > located outside their network (Internet services, 3rd party content > providers). Service identification will be based on local Service Provider > IP addresses. > > > > - QoS configuration will be delivered dynamically based on > subscriber needs. > > > > - SP don’t need to make any dramatic updates for existing > environment to identify services, because traffic identification and > handling will be based on IP stack only. > > > > > > P.S. Authors are looking forward to developing this approach further. The > authors have already tested the approach using manual settings > > Potential next steps include: > > - developing a Host Agent prototype; > > - developing a Headend's NETCONF/YANG adapter; > > - collaboration with a carrier to arrange a lab trial; > > - contributing the code to the open source community. > > > > If you have any kind of questions please feel free to contact us directly > kl...@netcracker.com, pet...@netcracker.com > > > > Best Regards, > > Maxim Klyus > > > > > > > The information transmitted herein is intended only for the person or entity > to which it is addressed and may contain confidential, proprietary and/or > privileged material. Any review, retransmission, dissemination or other use > of, or taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Dave Täht Do you want faster, better, wifi? https://www.patreon.com/dtaht ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
