[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Follow-up on comments on draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
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: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Zafar Ali (zali)
> Sent: Thursday, July 05, 2007 6:39 PM
> To: Lou Berger; Igor Bryskin; ccamp@ops.ietf.org
> 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
>
> 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
>