On 2/7/17 2:54 AM, Pascal Thubert (pthubert) wrote:
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?
It is true that downstream multicast on the primary vlan works, however
a host which originates upstream multicast on an isolated or community
vlan wouldn't just work. It doesn't seem like anybody cares, hence the
draft merely documents this issue.
* 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?
Depends on the IP configuration associated with those tunnels. If IP at
both ends agree that the tunnel is assigned the same prefix (i.e. both
ends think it is 192.168.1.0/24) or both ends agree that the tunnel has
no prefix but instead has a single local and remote IP addresses, then
the tunnel is a link which is not partitioned.
However, if the router's IP configuration is 192.168.1.1/24 and a host
has an IP configuration with no subnet but instead has a local address
192.168.1.17 and a remote IP of 192.168.1.1, then the tunnels are used
to construct an intentionally partitioned link. In this case a host
sending a packet to 129.168.1.99 requires that the router forward it
back out the same interface. (And if you are doing this with IPv6 you'd
end up assuming that the routers forward a a packet addressed to a
link-local address out the interface on which it arrived.)
Do you know of any existing document/protocol which describes such
intentionally partitioned tunnel setups?
If so there would be something we could reference, and there would be a
reason to clarify the scope in this document.
* 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?
For me to understand your case you have to separate out the L3
configuration and what it sees as L3 interfaces (whether those are L3
ports or SVIs); for IPPL it doesn't matter which mapping there is
between L3 interfaces and L2 ports.
So are the ports you refer to L2 ports with IP seeing an SVI? Or
something else?
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
Deploying common services on promiscious ports is a result of having
deployed IPPL links.
(Note that the draft doesn't advocate that folks deploy IPPL; it is
merely stating what needs to be done for IPv4 and IPv6 coping with
partitioned links. Hence I'm careful with the wording to not encourage
more deployment of partitioned links than needed.)
I'll add some words about that to the document once this becomes a WG
document.
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.
I don't think that is how e.g. PVLAN implementations work today. I know
that is not how DAD proxy works.
The router doesn't copy the received packet and send it out. Instead the
router originates a new packet with its own MAC address as the source.
Why do you want the routers to send out the unmodified packets? That
would make them into bridges hence they would potentially violate the
partitioning that was created in the actual bridges.
What problem are you trying to solve by doing this?
" 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.
router != bridge as described in this document.
The fact that there are products which combine routing and bridging
functions doesn't mean we can't and shouldn't describe the routing
function as separate from the bridging function. That is basically what
all the RFCs I've read done.
Thus I'm confused.
Are you talking about some unspecified device which, between the same
set of interfaces, bridges some packets and forwards others?
Is there an RFC or IEEE 802 specification for such a device?
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.
ND packets are never forwarded in any useful way since forward (as
described in RFCs) is a an IP operation which includes decrementing the
ttl/hopcount and ND verifies that hopcount is 255 on receipt.
The intent of the statement is about IP multicast packets which are
forwarded in other networks, but have issues with duplication or
loopback to the sender when the sender is on a community or isolated vlan.
Section 8 tries to explain that issue with
IP Multicast which spans across multiple IP links and that have
senders that are on community or isolated ports require additional
forwarding mechanisms in the routers that are attached to the
promiscuous ports, since the routers need to forward such packets out
to any allowed receivers in the private VLAN without resulting in
packet duplication. For multicast senders on isolated ports such
forwarding would result in the sender potentially receiving the
packet it transmitted. For multicast senders on community ports, any
receivers in the same community VLAN are subject to receiving
duplicate packets; one copy directly from layer 2 from the sender and
a second copy forwarded by the multicast router.
Erik
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
