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

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Thu, 5 Jul 2007 12:39:04 -0400

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.
 
(c) The third scenario is when the GMPLS tunnel is numbered but the TE
links are Unnumbered.
     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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 7 Jul 2007 21:53:57 +0200

zafar

it is the other way around, because you have different subnets you can
not make use of existing mechanisms

"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."

hence the first question is why shall this be different ?

-d.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
> Sent: Thursday, July 05, 2007 6:39 PM
> To: Lou Berger; Igor Bryskin; [email-masked]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh 
> (hassans); Tomohiro Otani
> Subject: Follow-up on comments on 
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> 
> 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. 
>  
> 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 
>  
> RTR1 <------GE data link/TE link -----> OXC <------ GE data 
> link/TE link -----> RTR2
>                   segment # 1                                 
>   segment # 2
> (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.
>  
> (c) The third scenario is when the GMPLS tunnel is numbered 
> but the TE links are Unnumbered.
>      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.
> (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
>