Hello Erik: Section 3: Clarifying Questions on scope (note that a picture would help visualize the IPPL better):
* The document insists on PVLAN, and I agree with the need/goal to explain them and support them better. I'm used to a promiscuous primary VLAN from which IP multicast effectively functions, like a core. Is there a need from something more complex? * Splitting a subnet in several L2 domains with L3 tunnels interconnection is a different beast, yet would fit in the generic term of IPPL. Is it the intention that those are covered? * Finally there's the multilink subnet whereby the router interconnects the limited ports with the core at L3. In that case, the router has multiple ports on the subnet, as opposed to the PVLAN where it has only one, thus the risk of ARP loop. This case appears to be not covered, though it makes the proxy ARP operation much more natural. Is that correct? Section 4: For ND and ARP, this means that address resolution and service discovery from isolated links will not necessarily work, and that there is a need for a careful deployment. We could note that there is an expectation that there are some reliable multicast transmissions between any node a limited set of peers (which may depend on that node), in particular that any node can discover a router, and whatever network services it is looking for e.g. a printer over mDNS. Can we say that the expectation is that people deploy common services in the promiscuous core and place hosts and limited services in the isolated ports? Section 6: The draft expects that the routers serving the hosts are connected to the promiscuous ports whereas the hosts are connected to the limited ports. If all the ARP proxy routers are in a promiscuous core where multicast functions (even if emulated), then the proxy operation can be done having the proxies copy the ARP reqs from the edge to the core, and from the core to the edge. This is doable (and done) in a L3 switch that has a capability to know from which port a packet came in, and control which ports will get a copy. " At a minimum, the reception of an ARP request MUST NOT result in sending an ARP request, and..." The "and" seems to read like this is a rule and there is more. But this is not required to obtain the intented loop avoidance, for instance the suggestion that the routers do not forward ARPs coming from other routers known by MAC@ but forward the others, and it appears to kill the design above. I'd suggest to remove that quoted text, or say that this in one way of achieving the recommendation to avoid loops that is already there. Section 8 "For that reason it is NOT RECOMMENDED to configure outbound multicast forwarding from private VLANs." Not all protocols would be impacted in a same manner. I think that the recommendation, which applies to ND more than to many others because of DAD, could be more specific, like that whatever is done to propagate a multicast beyond the limited scope allowed by the PVLAN should ensure that the multicast is either harmless to the protocol it is propagating, or not echoed back to the source device at all. Then again, the latter is something that can be done in a L3 switch and a ML subnet router. Cheers, Pascal -----Original Message----- From: Int-area [mailto:[email protected]] On Behalf Of Erik Nordmark Sent: jeudi 26 janvier 2017 19:20 To: Richard Li <[email protected]>; [email protected]; Wassim Haddad <[email protected]> Subject: Re: [Int-area] WG Adoption Call: IP over Intentionally Partitioned Links On 1/25/17 4:09 PM, Richard Li wrote: > > Authors: > > Do you intend to specify a standard or provide some information about > the implementation? > Richard, I'm not sure I understand your question. The draft specifies constraints on an implementation (with some MUST and SHOULD) for both the L2 partitioning layer and for IP running over this partitioned L2. That makes it a standard. Note that in general it is a bad idea to standardize specific behavior since we want to allow implementations to try different things. FWIW I've been bitten by this in the past with the IPv6 NUD standard being far to prescriptive with retransmission behaviors so we had to make an additional standards-track RFC relaxing the behavior. > Another question：Assuming your router supports L2VPN or its > equivalent, can L2VPN solve your problem? > If L2VPN is used to create a fully connected L2 network, then the L2VPN link would not be partitioned. Hence you wouldn't need the IPPL handling in that case. (But I imagine L2VPN could be used to create a partitially partitioned link as well.) But that doesn't mean that L2VPN would solve the problem people set up to solve when they created split horizon for DSL or PVLAN for Ethernets. We just need to make sure IPv4 and IPv6 can run reliably on such partitioned links. Does that answer your question? Thanks, Erik > Thanks, > > Richard > > *From:*Int-area [mailto:[email protected]] *On Behalf Of > *Wassim Haddad > *Sent:* Thursday, January 19, 2017 1:39 PM > *To:* [email protected] > *Subject:* [Int-area] WG Adoption Call: IP over Intentionally > Partitioned Links > > Dear all, > > We would like to start a WG adoption call for > _draft-nordmark-intarea-ippl-05_ ("IP over Intentionally Partitioned > Links”). > > Please indicate your preferences on the mailling list. The deadline is > Februray 3rd. > > Regards, > > JC & Wassim > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
