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

From: Jeff Learman <[email-masked]>
Date: Fri, 19 Apr 2002 10:11:02 -0400

At 10:39 PM 4/18/2002, Les  Ginsberg wrote:
>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.

I think that a new multicast address would be far better than a broadcast
address because it would cause fewer problems when (not IF, but WHEN) an
interface configured for PTP is attached to a broadcast LAN.  It should
not be difficult to assign a multicast address.

Regards,
Jeff

>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

---

From: Naiming Shen <[email-masked]>
Date: Fri, 19 Apr 2002 14:36:55 -0700

] >
 ] >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.
 ] 
 ] I think that a new multicast address would be far better than a broadcast
 ] address because it would cause fewer problems when (not IF, but WHEN) an
 ] interface configured for PTP is attached to a broadcast LAN.  It should
 ] not be difficult to assign a multicast address.

It may not be much better. I have seen people run IGP over the LAN on
some of the NAPs between their own peering routers. Assume multicast
mac is used, and they run p2p-over-lan for the IGP adjacency. The data
packets can be picked up by multiple routers on the LAN other than your
neighbor and this will cause serious problems.

I agree with Les that, an implementation can offer a configuration
knob to allow broadcast MAC address being used if the user is sure about
there is only two devices on the physical LAN. Its up to the implementation
and the user. Yes, a multicast MAC will also work in this case, but why
bother? why should every piece of hardware be touched to recognize this new
MAC just for this p2p-over-lan? Its not like the existing mechanisms all
fail.

thanks.
- Naiming

---

From: stefano previdi <[email-masked]>
Date: Sat, 20 Apr 2002 00:02:21 +0200

On Friday 19 April 2002 23:36, Naiming Shen wrote:
> and the user. 

absolutely. I woudn't force the use of any specifc address. I believe the 
scope of the draft is to give flexibility on the way the igp sees the link, 
but not on the way forwarding is done on the wire. So, give generic 
recommendations but not at the point of which mac address is supposed to be 
used.

s.

> Yes, a multicast MAC will also work in this case, but why