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

["PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>]

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.






> -----Original Message-----
> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] 
> Sent: Monday, July 09, 2007 7:32 PM
> To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor 
> Bryskin; ccamp@ops.ietf.org
> 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
> 
> 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
> 
> -----Original Message-----
> From: PAPADIMITRIOU Dimitri
> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] 
> Sent: Monday, July 09, 2007 12:18 PM
> To: Igor Bryskin; Zafar Ali (zali); Lou Berger; Igor Bryskin;
> ccamp@ops.ietf.org
> 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
> 
>  
> 
> 
> 
> 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:IBryskin@advaoptical.com] 
> > Sent: Monday, July 09, 2007 5:46 PM
> > To: PAPADIMITRIOU Dimitri; Zafar Ali (zali); Lou Berger; Igor 
> > Bryskin; ccamp@ops.ietf.org
> > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> > Behalf Of PAPADIMITRIOU Dimitri
> > Sent: Saturday, July 07, 2007 3:54 PM
> > To: Zafar Ali (zali); Lou Berger; Igor Bryskin; ccamp@ops.ietf.org
> > 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: 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 
> > > 
> > 
> > 
>