Hello Erik :
Please see inline:
* 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.
[Pascal] I'm thinking of the cases described in IPv6 ND proxies, RFC 4389; the
case above would be scenario 2, and the desire would be to avoid copying the L2
broadcasts over the possibly slow PPP link. ND proxy can indeed be useful in
subnet configurations where people want to isolate portions of the layer 2
network, not necessarily for security reasons but also, say, to limit the
broadcast domain and protect wireless clients. The configurations proposed in
the RFC force going through L3 and appears to me as forms of IPPL. Would you
agree?
As your draft does, RFC 4389 also insists on loopless configurations only. A
> * 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?
[Pascal] No, I’m not talking about an SVI but about placing a router where the
IPPL draft places a switch.
The router also has the effect of partitioning the L2 broadcast domain. I
understand that IEEE Std 802.11 recommends the use of ND proxy to protect the
wireless edge, which is yet another form of topology, not explicited by RFC
4389, but covered by draft-ietf-6lo-backbone-router for the context of
constrained power. Ccing Dorothy to make sure I’m not mis-representing the IEEE
position.
My question is really about the scope of the IPPL document, considering that
the term IPPL seems a lot larger in scope than private vlans…
>
>
> 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?
[Pascal] I agree that the DAD that the Pvlan nodes see are issued by the
router, and that’s how the end device are kept unaware of each other, and
that’s part of the router being a proxy. My point was not about the information
being transported with the same packet, but about the loop avoidance text in
the proxy operation:
“
For the ARP proxy to be robust it MUST avoid loops where router1
attached to the link sends an ARP request which is received by
router2 (also attached to the link), resulting in an ARP request from
router2 to be received by router1.
“
Point is, the L3 switch makes a difference between what’s coming from an access
port that’s private and what’s coming from a port connected to the primary vlan
(the backbone) where the routers are sitting. In particular, DAD requests
coming from the primary are not proxied back to the primary, so there is no
loop. The proxy checks if it has a matching state on a private port in which
case it replies, otherwise it drops the DAD packet.
>
> " 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?
[Pascal] I thought this discussion is about proxying the ARP. And I’m saying
that “the reception of an ARP request” may actually “ result in sending an ARP
request” as long as the flooding domain is controlled and loops are avoided, as
discussed just above. Probably le being confused in the scope of the text I
was reading.
>
> 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.
[Pascal] I was confused again. I though the forwarding term here was describing
the switch behavior, and I read this text as a recommendation that the switch
does not propagate the multicast..
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.
[Pascal] Did I read too quickly or could that be clarified in the text?
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.
[Pascal] I must admit I do not fully understand what this text. Maybe a picture
with the routers and the switches showing the packet duplication at work?
Take care,
Pascal
>
> Cheers,
>
> Pascal
> -----Original Message-----
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Erik
> Nordmark
> Sent: jeudi 26 janvier 2017 19:20
> To: Richard Li <renwei...@huawei.com<mailto:renwei...@huawei.com>>;
> int-area@ietf.org<mailto:int-area@ietf.org>; Wassim
> Haddad <wassim.had...@ericsson.com<mailto:wassim.had...@ericsson.com>>
> 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:int-area-boun...@ietf.org] *On Behalf Of
>> *Wassim Haddad
>> *Sent:* Thursday, January 19, 2017 1:39 PM
>> *To:* int-area@ietf.org<mailto:int-area@ietf.org>
>> *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
>> Int-area@ietf.org<mailto:Int-area@ietf.org>
>> https://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org<mailto:Int-area@ietf.org>
> https://www.ietf.org/mailman/listinfo/int-area
>
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
