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

From: Jeff Learman <[email-masked]>
Date: Thu, 18 Apr 2002 16:41:04 -0400

(Changing the group to isis-wg.)

At 04:03 PM 4/18/2002, Ravindra Sunkad wrote: 
>Sections 4.2 and 4.3 of <http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.txt>http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.txt do discuss IP forwarding over unnumbered LAN interfaces. Then again this applies only to LANs that are simulating PT-PT operation.

Thanks, Ravi, I missed that one somehow.  It's probably in my
"stuff I gotta read" folder ;-)

Concerning the draft:

(4.1 paragraph 2)  What's an "unnumbered IP address"?   Does this
paragraph mean that an address must be advertised in IIH PDUs, but the
same address may be used on other point-to-point circuits on the same
router?

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.

(Sorry for the johnny-come-lately questions.)

Thanks,
Jeff

---

From: Naiming Shen <[email-masked]>
Date: Thu, 18 Apr 2002 14:53:01 -0700

] 
 ] Concerning the draft:
 ] 
 ] (4.1 paragraph 2)  What's an "unnumbered IP address"?   Does this
 ] paragraph mean that an address must be advertised in IIH PDUs, but the
 ] same address may be used on other point-to-point circuits on the same
 ] router?

i think the "unnumbered" means to borrow some address from one of the
internal/connected addresses. yes, it should be advertised in the IIH.
yes, it maybe used for multiple p2p isis ckts on the same router. Most
implementations do this on normal p2p ckt today.

 ] 
 ] 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?

 ] 
 ] (Sorry for the johnny-come-lately questions.)

- Naiming
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Thu, 18 Apr 2002 18:37:41 -0400

>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

---

From: Naiming Shen <[email-masked]>
Date: Thu, 18 Apr 2002 18:15:10 -0700

Jeff,

 ] 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.

True. This draft is trying to do things using the most natual way
we know of, such as using ARP on a LAN:-) Sure, an implementation can
be done that as soon as IS-IS is configured, ARP is automatically
disabled, and IS-IS is used directly programming the linecards, etc.
Some people would think it's a layer violation. This draft lists
this mechanism as "2. MAC address gleaning" and its up to the
implementations.

 ] 
 ] 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 is also listed as "4. Broadcast/multicast/proprietary". But notice
that, we are not only talking about two devices on a LAN, we are also
dealing with vLANs. If we use multicast mac address for sending
traffic, first of all, all the linecards need some change to recognize
this new mac; and all the vLAN routers on this physical LAN have to
read the packet and drop on wrong vLAN id; And in the case of a LAN,
even though there is only two ISIS routers, but there can be other
IP devices/routers, if they happen to ok this mac, then they will
take in all the traffic not meant for them.

 ] 
 ] 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.
 ] 

I hope people do some basic testing before they suddenly enable this
on their backbone. Any reasonable implementation should just ignore
that "wrong" pkt, if not, then we all have one less competitors;-)

thanks.
- Naiming