Subject: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt

From: "Martin, Christian" <[email-masked]>
Date: Wed, 8 Aug 2001 01:53:07 -0400

Alex,

Thanks for the response.  Comments inline...

> Christian,
> 
>  A comment regarding OSPF---essentially, we're not changing
>  anything in OSPF, we're only saying an implementation should
>  be able to treat LAN link as a p2p network type.

Understood.

> 
>  Your suggestion to implement p2mp in ISIS might make sense in a
>  generic context, however, it would introduce unnecessary
>  complexity to the p2p lan case, which is addressed simply
>  by (again) treating the link as p2p (and hence automagically
>  sending p2p iih's, using psnps, etc.) and agreeing on
>  the MAC address.

This is one of the benefits I see.  I was hoping it could be extended to the
more general case.  It is not uncommon for routers to be connected via
switches to other routers in an attempt to minimize port costs and maximize
bandwidth.  If you connect 10 routers to a switch (in the same VLAN of
course), all costs (to the pseudonode) are the same.  Directed adjacencies
(while more complex, configuration-wise) are a cost effective way of
adjusting metrics without using dedicated, PTP links )or VLANs).

>  I think if there's enough interest in p2mp in ISIS, it should
>  be addressed separately.

Perhaps this should be the case.  I can generate a draft and submit it
separately.  Care to collaborate?

>  Wrt the merits of the draft, it's not only eliminating
>  DR/DIS election, it is also reducing the number of LSAs/LSPs in
>  the domain, some flooding benefits, using ip unnumbered, etc.

Many network operators feel that IP unnumbered presents several operational
drawbacks, particularly when troubleshooting link problems.  I for one am
not opposed to it, but I could not convince my Ops staff that there was
enough merit in reducing IP usage to justify the reduction in operational
utility of addressed links (for pinging, traceroute, ER-LSPs, etc).
Nevertheless, others may have this requirement, so I am not diametrically
opposed to it.  Either way, you mention this, so I am ok with it.

>  If you see any problems that are not addressed within the
>  context of the draft, please elaborate.

I don't disagree with anything in the draft - I just think that it is fairly
specific in scope.  By expanding the scope to a more generic case, a
specification and subsequent implementations would not need additional
rewrites to cover other requirements.

For what it's worth, the draft does do some nice things ( things that caused
me to scrap GigE for POP interconnect in favor of POS - at a higher cost per
Mb ).  I was just thinking that some additional work would yield an IS-IS
implementation that covered the generic case.

>  Regarding a separate OSPF doc, I don't see the critical mass
>  of changes in OSPF (in fact, there are none) to justify splitting
>  of a complete document.

I do not write code for a vendor, so I cannot in fairness speak to this
directly.  But I would think that the OSPF-WG would be interested in this
work, as it does require an implementation to treat a LAN as PTP - which may
not be trivial.  Just a thought.

>  Thanks,

Thanks, as well.

-chris

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