Subject: RE: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt

From: Les Ginsberg <[email-masked]>
Date: Thu, 18 Apr 2002 19:39:56 -0700

There are a number of ways to resolve this issue - each of which probably
presents different degrees of difficulty for forwarding plane
implementations.

1)All packets could be sent with the broadcast address. This is functionally
equivalent to what the implied destination address is on PtPt links - and
seems as functional as a new multicast address with the advantage that we
don't have to carve out a new multicast address and potentially stress the
limits of multicast address registration in the hardware.

2)An implementation could assign static ARP entries

3)Routing protocol could provide ARP entries based on info from the hello
messages. Note that this works well for IS-IS but doesn't help OSPF.

4)If the address of a loopback interface is always advertised in the case of
an unnumbered P2P/LAN and the local ARP implementation always replied to ARP
queries for the IP address of ANY local interface (not just the interface
associated with the port on which the ARP request is received) then the
destination MAC address could be discovered.

I suspect "your mileage may differ" is the applicable phrase in that what
may be easy for one router to implement may be awkward for another. This
seems the sort of thing which should be tried first on a number of platforms
before deciding which strategy/strategies to endorse. Perhaps those who have
already done this might share what solution(s) they used.

   Les

> 
> At 05:53 PM 4/18/2002, Naiming Shen wrote:
> > ] 
> > ] Why wasn't a standard multicast address chosen to avoid 
> the need for ARP?
> > ] 
> > ] ARP shouldn't be required when using ISIS anyway, since 
> IIHs are sufficient
> > ] for MAC address resolution.  And if ARP isn't required, 
> then the interface
> > ] IP address wouldn't be required either, I believe.  But 
> if a standard
> > ] multicast address is used, the issue becomes moot.
> >
> >ARP maybe used because we want to forward IP traffic, not because we
> >need to exchange ISIS routing packets. To forward traffic on a multi
> >access interface, you need to have a MAC. Or did I miss your 
> question?
> 
> I think you missed what I'm saying.
> 
> First, (ignoring the PTP issue) when using ISIS you don't need ARP to
> resolve the MAC address of a neighbor router, because you received an
> IIH from it and can get the MAC address from that.  ARP need
> not be the only entity allowed to create an address binding.  This is
> an implementation issue, not a protocol issue.
> 
> But if we assign a standard multicast MAC address on PTP Ethernet,
> then neither ARP nor the IIH MAC address is required.  It acts just
> like any other PTP link, whatever you send gets to the other end.
> 
> This also simplifies interoperability.  If there is an implementation
> that croaks upon receiving a PTP IIH on a broadcast LAN, nobody would
> know because it never happened before.  If we use a (new) multicast
> address for ALL packets on the link (not just IP packets, but also
> ISIS packets), then there would be no worry about a naive 
> implementation
> receiving these packets when they're inadvertently unleashed on a
> broadcast LAN.  They would be ignored because no systems would be
> listening to that multicast address on the LAN.
> 
> Regards,
> Jeff
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://spider.juniper.net/mailman/listinfo/isis-wg
> 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg