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

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

> -----Original Message-----
> From: Hassan Sheikh (hassans) [mailto:hassans@cisco.com] 
> Sent: Monday, July 09, 2007 10:15 PM
> To: PAPADIMITRIOU Dimitri; Igor Bryskin; Zafar Ali (zali); 
> Lou Berger; Igor Bryskin; ccamp@ops.ietf.org
> Cc: Adrian Farrel; Brungard, Deborah A, ALABS; Tomohiro Otani
> Subject: RE: Follow-up on comments on 
> draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
> 
> 
> 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
> 
> -----Original Message-----
> From: PAPADIMITRIOU Dimitri
> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] 
> Sent: Monday, July 09, 2007 2:39 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
> 
> 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
> > > > 
> > > 
> > > 
> > 
>