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

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 9 Jul 2007 18:17:42 +0200

sorry but we don't discuss about any over Ethernet here 
but between two IP/MPLS LSR  

hence, what is different here from two LSRs interconnected 
by an Ethernet link over X ?

zafar can you clarify this point ? because from what i 
read in your draft it is because the address to be resolved
creates an issue but why should that be different from 
what you see today between two Ethernet hosts connected
back-to-back ?

-d.

> -----Original Message-----
> From: Igor Bryskin [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 5:46 PM
> To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor 
> Bryskin; [email-masked]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh 
> (hassans); Tomohiro Otani
> Subject: RE: Follow-up on comments on 
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> 
> Zafar,
> 
> Let's look at your situation with eyes of an ITU-T folk :=)
> 
> Your client layer is IP, and your server layer (the one that provides
> connectivity between IP routers) is Ethernet. This means that 
> a link in
> IP layer is provided by a connection in Ethernet layer. The MAC header
> you need to encapsulate your IP CI is a label of the Ethernet 
> connection
> and should be learned via signaling before the connection is 
> used. Note
> also that IP layer is not the only client of Ethernet, for example,
> Ethernet-in-Ethernet is quite possible, so you can't rely on protocols
> like ARP. 
> 
> Cheers,
> Igor
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of PAPADIMITRIOU Dimitri
> Sent: Saturday, July 07, 2007 3:54 PM
> To: Zafar Ali (zali); Lou Berger; Igor Bryskin; [email-masked]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Hassan Sheikh 
> (hassans);
> Tomohiro Otani
> Subject: 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: [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
> > 
> > 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: Mon, 9 Jul 2007 20:39:20 +0200

igor, 

actually, we have ARP (or ND in case of v6) for address resolution

the whole discussion point for me (reading the material from zafar) is
that he wants to remove a dependency about IPv4 running over Ethernet
that is (by definition not dependent of GMPLS but) resulting from the
use of GMPLS to establish the LSP X with GPID = Ethernet (Eth over X) 

now, i am still not sure why zafar doesn't propose the use of
"gratuitous ARP" once the Ethernet i/f is up ?

thanks,
-d.

> Sent: Monday, July 09, 2007 7:32 PM
> Dimitri,
> What I was saying is that if a client layer IP uses a server layer
> Ethernet than the server layer should know what the Layer Information
> (LI) overhead to put on client's Adapted Information (AI), I mean this
> information belongs to Ethernet, not to IP, and it is not 
> IP's business
> to identify this information. And as you pointed out a pair of IP
> routers could be inter-connected by Ethernet trail, while another pair
> by SDH trail and it is not IP's business to determine LI in either of
> server layers. So, how is it different from what you say?
> 
> Igor
> 
> From: PAPADIMITRIOU Dimitri
> [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 12:18 PM
> To: Igor Bryskin; Zafar Ali (zali); Lou Berger; Igor Bryskin;
> [email-masked]

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Mon, 9 Jul 2007 23:46:29 +0200

> From: Hassan Sheikh (hassans) [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 10:15 PM
> To: PAPADIMITRIOU Dimitri; Igor Bryskin; Zafar Ali (zali); 
> Lou Berger; Igor Bryskin; [email-masked]
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Tomohiro Otani
> There are two problems with "gratuitous ARP" that I have encountered
> while testing:
> 1- It is not 100% reliable and these message can get lost /dropped
> unless both ends of the link are fully operational.

the same would happen with any other in-band messaging
that share the same end-points (side note what do you 
mean by "both ends of the link are fully operational")

> 2- What happens when ARP cache times out - i.e no activity on the data
> plane. Then we need another mechanism to kick start and 
> populate the ARP entries.

do i well understand here that one could have a case 
where local ARP cashes could clear within X min w/o
any packet being exchanged ?

assuming that would be the case (is that really the
case outside any test/demo context) are you going to 
re-signal the LSP just to be sure that the ARP cache 
entry stays up ? 

> What is being asked here is to associate the GMPLS LSP 
> (considered to a
> p-p link) endpoints with an ARP entry just like you would for a native
> Ethernet link. In this case, we would like to remove the dependency on
> the underlying Ethernet layer. This case is applicable when the GMPLS
> LSP is setup over an Ethernet link.

if my understanding of the problem described by Zafar is
correct, the case described is not GMPLS over an Ethernet 
link but GMPLS LSP setup resulting in an Ethernet link 

> Thx
> hassan
> Sent: Monday, July 09, 2007 2:39 PM
> > To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; 
> Igor Bryskin;
> 
> > [email-masked]
> > information belongs to Ethernet, not to IP, and it is not IP's 
> > business to identify this information. And as you pointed 
> out a pair 
> > of IP routers could be inter-connected by Ethernet trail, while 
> > another pair by SDH trail and it is not IP's business to 
> determine LI 
> > in either of server layers. So, how is it different from 
> what you say?
> > 
> > Igor
> > 
> > sorry but we don't discuss about any over Ethernet here but between 
> > two IP/MPLS LSR
> > 
> > hence, what is different here from two LSRs interconnected by an 
> > Ethernet link over X ?
> > 
> > zafar can you clarify this point ? because from what i read in your 
> > draft it is because the address to be resolved creates an issue but 
> > why should that be different from what you see today between two 
> > Ethernet hosts connected back-to-back ?
> > 
> > -d.
> >  
> > 
> > > connectivity between IP routers) is Ethernet. This means 
> that a link
> 
> > > in IP layer is provided by a connection in Ethernet layer. The
> > MAC header
> > > connection and should be learned via signaling before the 
> connection
> 
> > > is used. Note also that IP layer is not the only client 
> of Ethernet,
> 
> > > for example, Ethernet-in-Ethernet is quite possible, so you can't 
> > > rely
> > on protocols
> > > like ARP. 
> > > 
> > > Cheers,
> > > Igor
> > > 
> [mailto:[email-masked]] On 
> > > "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 
> > > > 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.
> > > > 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
> > > >  
> segment # 
> > > > 2 are in different subnets (valid scenario)
> > > > 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
> > > >  
> > > > 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
> > > > 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.
> > > > 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
> > > >