Re: [homenet] Redirect and source-specific routing
On 13/07/2015 02:30, Juliusz Chroboczek wrote: I'm wondering if there isn't some interaction between Redirect messages and source-specific routing that we're overlooking. RFC 4861 Section 8.3 says the following: Redirect messages apply to all flows that are being sent to a given destination. That is, upon receipt of a Redirect for a Destination Address, all Destination Cache entries to that address should be updated to use the specified next-hop, regardless of the contents of the Flow Label field that appears in the Redirected Header option. It does not speak of the source address, so I assume that this applies to all sources. It definitely should not, since in some topologies that might send packets directly to a BCP38 filter. I think that's a 6man issue. I might even have to modify my slides for 6man. Brian Consider the following topology: A ---+--- B | H If A and B advertise non-overlapping source-specific default routes and H is multiplexing its traffic over source addresses in both source prefixes (say, it's using MP-TCP), its Destination Cache entry will flap between A and B. If I'm right, that argues in favour of an update to RFC 4861. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IntDir review: draft-ietf-homenet-dhcp-07
On 13/07/2015 03:05, Steven Barth wrote: Hello Ole, ... = Add a reference to Merkle trees? I'm not certain what would be a good source to quote here, maybe Merkle's paper from '87 or the ‘92 patent? At least there doesn't seem to be a really appropriate reference. His PhD thesis seems to be the best formal reference: www.merkle.com/papers/Thesis1979.pdf http://dl.acm.org/citation.cfm?id=909000 If you want to actually know what a Merkle tree is: https://en.wikipedia.org/wiki/Merkle_tree Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Questions about HNCP Section 7.2
In addition to the above -- shouldn't a prefix previously be announced with a lifetime of zero for a few minutes after it is destroyed? Yes, see RFC 7084 requirement L-13. In general you should follow RFC 7084, since HNCP says that these requirements apply (section 11). We only listed a few small adjustments to bridge the gap from single CE to a multi-router network. A few more such adjustments are staged for -08. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IntDir review: draft-ietf-homenet-dhcp-07
It is my (possibly mistaken) understanding that the nature of an endpoint depends on the mode of operation. So why not use a more concrete definition? The definition just gets more verbose with every iteration, the underlying problematic is that it tries to unify different concepts that are usually not unified ;) Also, the reverse is true. The modes that may be used depend on the type of endpoint. I personally think the socket metaphor more or less fits: if you have a socket bound / connected to some global address, you just cannot do link-local multicast with it, though if you've bound your socket to a link-local address of an interface, you can probably use (link-local) mc as well as uc. What makes sense here of course depends on what you are trying to achieve, if your DNCP-based protocol is supposed to communicate to something a few (non-DNCP) hops away then using link-locals or allowing multicast mode is probably not sensible, for HNCP we don't need globally scoped unicast so for the sake of simplicity we define that endpoints must be mc-capable. In all modes, an endpoint identifier is an arbitrary non-zero integer that, at any given time, MUST uniquely identify a particular endpoint. Endpoint identifiers SHOULD NOT be reused too soon after a given endpoint ceases to exist, but if that happens, DNCP will reconverge after a short period of chaos. Yeah, I guess the reuse-clause makes sense. (I don't think that DNCP requires endpoint identifiers to be non-zero, but HNCP does, so you might as well make that a requirement of DNCP.) The terminology defines 0 to be reserved for internal purposes. Thanks, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Shncpd news
Hello Julusz, Pretty nice, thanks. Did you look at hnetd source code, or did you do it only from the draft(s) ? - Pierre Le 11 juil. 2015 à 17:18, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr a écrit : Shncpd has learnt how to do prefix assignment last night. https://github.com/jech/shncpd It remains to teach it to speak RA, DHCPv4 and Babel, and it will be a minimally compliant Homenet stack all by itself. (For now, it requires that you run an external Babel daemon.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Redirect and source-specific routing
I'm wondering if there isn't some interaction between Redirect messages
and source-specific routing that we're overlooking. RFC 4861 Section 8.3
says the following:
Redirect messages apply to all flows that are being sent to a given
destination. That is, upon receipt of a Redirect for a Destination
Address, all Destination Cache entries to that address should be
updated to use the specified next-hop, regardless of the contents of
the Flow Label field that appears in the Redirected Header option.
It does not speak of the source address, so I assume that this applies to
all sources. Consider the following topology:
A ---+--- B
|
H
If A and B advertise non-overlapping source-specific default routes and
H is multiplexing its traffic over source addresses in both source
prefixes (say, it's using MP-TCP), its Destination Cache entry will flap
between A and B.
If I'm right, that argues in favour of an update to RFC 4861.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Shncpd news
Pretty nice, Don't rejoice too soon -- I haven't checked it yet. (I need a rest, it was hard work.) Did you look at hnetd source code, or did you do it only from the draft(s) ? From the draft only, although I did have a chat with Markus on IRC. The PA draft is better specified than HNCP and DNCP. On the other hand, I find that it often lacks rationale. Pierre, if you want to check my work, the core of the implementation is at https://github.com/jech/shncpd/blob/master/prefix.c#L618 -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Questions about HNCP Section 7.2
Section 7.2: o The default Router Lifetime MUST be set to an appropriate non-null value whenever an IPv6 default route is known in the HNCP network and MUST be set to zero otherwise. In the presence of source-specific routing, the term default route is ambiguous. There are marvelous interactions here between source-specific routing, on-link prefixes, autonomous address configuration flags and DHCPv6 servers. Could you please clarify what needs to be done here? o A Prefix Information Option MUST be added for each assigned and applied IPv6 prefix on the given link. The autonomous address- configuration flag MUST be set whenever the prefix is suitable for stateless configuration. What's suitable here? I assume you mean /64 or shorter? (But then RFC 7421 Section 4.3.1 implies that we might as well not bother, and always set the flag.) o A Route Information Option [RFC4191] MUST be added for each delegated IPv6 prefix known in the HNCP network. Additional ones SHOULD be added for each non-default IPv6 route with an external destination prefix advertised by the routing protocol. That's to handle isolated Homenets, right? Some rationale would be helpful. o To allow for optimized routing decisions for clients on the local link routers SHOULD adjust their Default Router Preference and Route Preferences [RFC4191] so that the priority is set to low if the next hop of the default or more specific route is on the same interface as the Route Advertisement being sent on. I'm not sure I follow. If the host has accurate on-link information, the redundant route will be ignored anyhow. If the host is multihomed and doesn't have on-link information, then setting the priority to low might cause it to route through a different interface, thus rendering the redirect mechanism ineffective. Every router sending Router Advertisements MUST immediately send an updated Router Advertisement via multicast as soon as it notices a condition resulting in a change of any advertised information. Immediately? I'd rather do that after a random delay in order to avoid collisions (think multicast on wireless). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IntDir review: draft-ietf-homenet-dhcp-07
a locally configured communication endpoint of a DNCP node, such as a network socket. An endpoint may be bound to a set of predefined unicast Addresses representing remote DNCP nodes to individually connect to or to accept connections from whereby communication with each node is separated (e.g., an individual unicast UDP message flow per remote node). An endpoint may also be bound to a whole network interface, then multicast communication is used (in addition to individual unicast flows) to send certain messages to all DNCP nodes connected therewith at once as well as to automatically discover new DNCP nodes. I'm not sure I understand this paragraph. It uses words with many syllables. It is my (possibly mistaken) understanding that the nature of an endpoint depends on the mode of operation. So why not use a more concrete definition? * in both multicast modes of operation, an endpoint is just a local interface; * in both unicast modes of operation, an endpoint is a connected socket, or, equivalently, a pair of a local socket and a remote socket (or perhaps a pair of a local socket and one or more remote sockets, I'm not sure). In all modes, an endpoint identifier is an arbitrary non-zero integer that, at any given time, MUST uniquely identify a particular endpoint. Endpoint identifiers SHOULD NOT be reused too soon after a given endpoint ceases to exist, but if that happens, DNCP will reconverge after a short period of chaos. (I don't think that DNCP requires endpoint identifiers to be non-zero, but HNCP does, so you might as well make that a requirement of DNCP.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IntDir review: draft-ietf-homenet-dhcp-07
Hello Ole, thanks again for your review and sorry for the delay. Please find replies inline. Cheers, Steven Markus Given that it is an Abstract protocol specification, that must be combined with a profile specification to be a fully implementable, it is somewhat difficult to predict if the specification is complete or not. Juliusz Chroboczek is writing an independent implementation, and I'd recommend incorporating the very informative replies the authors have made to his comments on the homenet list into the document. -07 already included some of them and we've staged a few more for -08. General comments: = = Replace no affiliation with Independent. If that's the case. Done. = It is unclear to me how multiple instances of DNCP is run on a link. Is that something that must be specified in the profile document, and each profile must support multiple instances? Given draft-stenberg-shsp, and the way it hijacks the HNCP profile, it appears that more formal multiple instance support would be needed. Hmm, I think this is up to the specific protocol. Reuse of profiles is in theory possible but for standardisation would require either one protocol updating the other OR distinct TLV-spaces. The latter sounds a bit awkward e.g. IANA-wise. In any case , when sharing transport details such as port numbers, then a shared registry would need to be done anyway. SHSP should probably not be seen as a good example here. Since DNCP does not define defaults here an extra identifier seems unncessary and could or should probably be specified by the derived protocol. = I can't help being left with the impression that fragmentation (section 6.3) is underspecified. Can fragmentation be left out of the protocol for now (and profiles requiring large TLVs can require a transport layer supporting segmentation and reassembly?) Agreed. = I do find the text on transport modes somewhat confusing, U, M+U and MulticastListen+U. I'd like to see more descriptive text Okay, we will prepare something for -08. Abstract: = OLD: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees. DNCP leaves some details unspecified or provides alternative options. Therefore, only profiles which specify those missing parts define actual implementable DNCP-based protocols. NEW: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses Trickle and Merkle trees. DNCP is an abstract protocol, that must be combined with a specific profile to make a complete implementable protocol. Done. = Add a reference to Merkle trees? I'm not certain what would be a good source to quote here, maybe Merkle's paper from '87 or the ‘92 patent? At least there doesn't seem to be a really appropriate reference. Section 4.2: = This is confusing: o If using a stream transport, the TLV MUST be sent at least once, and it SHOULD be sent only once. I staged If using a stream transport, the TLV MUST be sent at least once per connection, but SHOULD NOT be sent more than once. for now. OLD: * If only unreliable unicast transport is employed, Trickle state is kept per each peer and it is used to send Network State TLVs every now and then, as specified in Section 4.3. NEW: * If only unreliable unicast transport is used, Trickle state is kept per peer and it is used to send Network State TLVs intermittently, as specified in Section 4.3. s/every now and then/now and then/ s/employed/used/ Section 4.3: = reference to rfc6206? All done. o the endpoint is in Multicast+Unicast transport mode, in which case the TLV MUST be sent over multicast. o the endpoint is NOT in Multicast+Unicast transport mode, and the unicast transport is unreliable, in which case the TLV MUST be sent over unicast. = What do an implementation do if the endpoint is not in M+U transport mode, and the unicast transport is reliable? Section 4.2 states If only reliable unicast transport is employed, Trickle is not used at all. for unicast mode and ML+U mode references that as well. (I do find the transport modes confusing, and I'm not sure I understand the MulticastListen mode). These modes, especially the listen one is only used for Dense Broadcast Link optimization. It is essentially the same as unicast, however the node listens for multicast traffic to detect the presence or abscence of a node with higher identifier on the underlying multicast-capable link. s/when using also secure unicast/when using secure unicast/ Done. Section 4.4: = What is meant by: link with shared bandwidth? I changed it to multiple access link for now, I think that makes it more clear. o Any other TLV: TLVs not
Re: [homenet] Questions about HNCP Section 7.2
In addition to the above -- shouldn't a prefix previously be announced with a lifetime of zero for a few minutes after it is destroyed? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
