Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt

Hi Lou, Igor, ccamper, et al,

Here is a follow-up on our AI from last WG meeting on the comments received on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt. We are planning to revise the document based on your feedback. Please advise if you have any further comment/ suggestion.

The issue is focused around the use of the GMPLS tunnel as a point-to-point link using Ethernet TE links. Unlike pos links where a L2 adjacency resolution is not required, the Ethernet links require that the ARP be resolved (aka Layer 2 MAC address) before any forwarding works on this link. It is not a case of broken implementation. We (router vendors) cannot work around ARP. What we need to do is to provide clear direction or recommendation for vendors on how to ARP for GMPLS controlled Ethernet interfaces. Or else, all vendors will implement whatever ARP mechanism works for them in terms of forwarding. E.g., there is an interop issue between Juniper and Cisco (from a fwding perspective) when Ethernet links are used (Both do ARP). We had to find workarounds to make things work (at ISO Core and in private testing). The same will be the case between Cisco, Juniper and other vendors.

The solution we are pushing for is that we need a mechanism that allows us to resolve ARP directly for the GMPLS tunnel ip addresses. This removes any dependency on the underlying Ethernet links or the addressing scheme that is used for TE links i.e. numbered links in the same or different subnets.

In the following, we describe the situation with numbered Ethernet links and Unnumbered Ethernet links (the assumption is that the GMPLS tunnel is a ipv4 numbered link in both instances).

Consider the scenario

<----------------------------------------------GMPLS Tunnel------------------------------------------>

RTR1 <------GE data link/TE link -----> OXC <------ GE data link/TE link -----> RTR2

segment # 1 segment # 2

There are two instance to consider:

(a) When numbered TE links are used but segment # 1 and segment # 2 are in different subnets (valid scenario)

In this situation we really have no way of resolving ARP using the addresses of the underlying TE link Ethernet links w/o using static ARP entries. The issue is that the subnets are different so the ARP request received by RTR2 from RTR1 will be rejected as it is not known to RTR2 and vice versa. Instead, if the ARP request if for the GMPLS tunnel instead then there should be no problem as the GMPLS tunnel is p-p link with IPV4 addresses in the same subnet.

Verdict: If we have the ARP resolution mechanism tied in to the GMPLS tunnel interfaces addresses then there is no issue or dependency

(a) When numbered TE links are used and segment # 1 and segment # 2 are in the same subnet.

In this setup the GMPLS Tunnel can inherit and use the ethernet link address for ARP resolution and there is no issue as both segments are in the same subnet. The problem in this situation is that we need to resolve the ARP for the ipv4 addresses for the GMPLS tunnel (considered as a p-p link) as opposed to inherit it from the underlying Ethernet TE links.

Verdict: In this situation the ARP resolution mechanism should be developed for the GMPLS tunnel address.

In this case we are again faced with the same issue of L2 ARP adjacency resolution between RTR1 and RTR2. RTR2 will reject the ARP request for RTR1 when it does not find the Unnumbered address (used by RTR1) in its FWDing database. This issue would not be encountered if we were resolving the ARP on GMPLS tunnel address.

Verdict: ARP resolution mechanism is required for GMPLS tunnel.

(d) We also need to make sure that when the tunnel-id is unnum, vendor implementation honor ARP request using loopback addresses. We have also faced interop issue in this scenario.

Thanks

Regards... Hassan and Zafar