ops dir comment on draft-ietf-isis-igp-p2p-over-lan-03.txt

[Randy Bush <randy@psg.com>]

From: Pekka Savola <pekkas@netcore.fi>
To: Randy Bush <randy@psg.com>
cc: ops directorate <ops-dir@ops.ietf.org>
Subject: draft-ietf-isis-igp-p2p-over-lan-03.txt [Re: Agenda and Package for
 October 2, 2003 Telechat]
Date: Tue, 30 Sep 2003 00:02:27 +0300 (EEST)

On Fri, 26 Sep 2003, Randy Bush wrote:
>     3.1 WG Submissions
>     3.1.1 New Item
> ****  o draft-ietf-isis-igp-p2p-over-lan-03.txt
> 	Point-to-point operation over LAN in link-state routing protocols 
> 	(Informational) - 1 of 2 
> 	Note: On agenda for 2003-10-02 telechat 
> 	Token: Bill Fenner

IMHO, not ready yet.  Comments below.  Feel free to unmask (as always).

I had time for a quick read only, but should be enough for now..

In general, I think this is a very useful approach, with the advent of 
Ethernet-type media for WAN links.  However, the specification appears 
incomplete to me.

==> why is this meant for Informational?  This kind of stuff could be 
useful in Experimental/PS as well.

==> The document has a large number of IPv4 dependencies, some of them 
subtler than the others (ARP vs Neighbor Discovery, discussion of only 
OSPFv2/IS-IS).  This is unacceptable.

==> the draft has one author too many (6 at the moment)

==> add the IPR, copyrights, etc. sections at the end, please.

4.1 Operation of ISIS
[...]

   The circuit needs to have IP address(es) and the p2p IIH over this
   circuit MUST include the IP interface address(es) as defined in
   [ref2]. The IP address(es) can be numbered or unnumbered.

==> Uhh, I don't understand what is an "unnumbered IP address".  
In my book, you either have an IP address or you don't?  
What am I missing?  Note, ref2 [RFC1195] doesn't mention "unnumbered" 
at all.

4.3 IP forwarding and ARP
[...]
    Proxy ARP has to be enabled if the address is not the adjacent
    interface IP address.

==> this seems a bit awkward, couldn't you say it easier with like:

    Proxy ARP has to be enabled if the addresses do not share the
    same IP subnet.

==> further than that, I'm not sure if it has been described in enough 
detail why exactly you need proxy ARP.  It's used in a bit unconventional 
way, it seems to me ("router X proxy-arping for it's loopback addresses"), 
right?  I'm not sure if you need proxy-arp for that (or at least, describe 
that this is what you mean with proxy-arp), defining that a router just 
responds to loopback addresses with ARP on the particular interfaces would 
be OK as well.

....

    In the case where unnumbered IP addresses are used for p2p-over-lan
    circuit, the source IP address of ARP request and the target
    interface IP address are usually on different subnets. The ARP
    should reply if this is a p2p-over-lan circuit, or an
    implementation MAY choose to limit the reply to the case where the
    IGP peer is requesting over this unnumbered p2p-over-lan circuit.

==> IGP peer is requesting *what* ? 
==> I think the whole paragraph should be rewritten, starting from "The
ARP". I've _very_ little idea what you're actually specifying here.

7. Security Issues       

==> s/Issues/Considerations/

==> I'd also add here something on the potential for misconfiguration, 
affecting availability, like:

If one router on a link thinks that a LAN should be either broadcast or
p2p-over-lan, and the other router has a different opinion, the
adjacencies will never form, as specified in Section 5.  There are no
fallbacks at either end to resolve the situation, except by a manual
configuration change.

purely editorial
----------------

   Since the physically circuit is a broadcast one, the ISIS protocol

==> s/the physically/physically the/

  Both routers on the LAN will simply join the AllSPFRouters
 
==> s/SPF/OSPF/ (or intentional?)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings