Subject: [Isis-wg] Interest in Supporting PTP Behavior on LAN Media in IS-IS?

From: "Martin, Christian" <[email-masked]>
Date: Sun, 25 Feb 2001 01:51:19 -0500

Folks,

I know that over the years, the idea of supporting NBMA interfaces has been
tossed around the IS-IS community with little interest generated.  I assume
that the idea was spurred by the need to support partial-mesh, switched
WANs, such as Frame Relay.  The argument aginst this support was that these
media could be made into PTP media through static PVCs, at the expense of
address space.  Recently, I have been wondering about the utility of
supporting directed, PTP adjacencies over high-speed LAN interfaces, in an
attempt to provide deterministic, per-adjacency metric state.  Since I have
no experience in IS-IS protocol development, I was hoping those who have can
enlighten me on the level of difficulty required to produce such an
implementation, before I embark on authoring or co-authoring a draft.  Is
there any interest (outside my own), in supporting per adjacency state
across LAN media?  Perhaps an example would help illuminate the need as I
see it.

<salesmanship>
Today's ISP POP architecture is often built using PTP POS trunks between all
core routers in the POP.  Edge/Aggregation routers are often redundnatly
uplinked to multiple core routers via POS interfaces as well.  In many
cases, POS links may be substituted by ATM PVCs, but this case diminishes as
bandwidth needs rise, and it still looks as if no vendor has any interest in
building OC-48 or higher  SARs.  Give N core routers and M Edge/Aggregation
routers, such an architecture requires N(N-1) + N(M+N) = 2N^2 + N(M-1) POS
interfcaes per POP.  Given the minimum required number of nodes and links
needed for edge and core redundancy, M = N = 2, which results in 10 POS
ports.  Since many ISP POPs have N >= 3 and M >= 10, this yields a minimum
45 POS ports per POP.  At OC-48/192 speeds for N-N connectivity, and
OC-48/12 speeds for N-M connectivity, this results in N(N-1)*<oc192/48 port
cost> + N(N + M)*<oc48/12 port cost) per POP just to adequately mesh the
routers.
</salesmanship>

A less optimal, but much more cost effective approach would be to use 10GigE
interfaces instead of OC192/48 interfaces, and GigE instead of OC-48/12
interfaces.  By linking each device tigether through a pair of redundant
GigE switches, the number of GigE ports on the routers reduce to 2(N + M),
and the cost reduces to 2N<cost of 10GE port> + 2(N+M)<cost of GE port>,
plus 2(N+M) cost of GigE ports on the switches (which is generally an order
of magnitude less than the cost of router ports of the same type when the
switch density is high, utilization-wise).  This obviously has significant
advantages cost-wise, but there are glaring disadvantages technology-wise.
In particular, link restoration mechanisms inherent in SONET are not
available, as is end-to-end link management in general, thus requireing
reliance upon proptocol adjacency state to detect remote link trouble.  TE
may be more difficult across shared LAN media as well, however, I cannot
substantiate this claim from experience.  In particular, though, all routers
adjacent over the same subnetwork share the same metric.  This subtle
deficiency is exasperated when routers have different link speeds (and thus)
metrics into the switch fabric.  This particular deficiency renders IGP TE
using metrics impossible.

A potential solution to this problem would be to create Z=[N(N-1) + N(N +
M)]/2 VLANs through the switch fabric, and connect the routers over /30 or
/31 subnetworks.  However, this causes the creation Z pseudonodes in the
IS-IS domain.  Given an ISP backbone consisting of N = 100 and M =200, this
requires 19950 pseudonodes which has obvious drawbacks, even given the
ability to support more than 255 pseudonodes as recently proposed.

What would be nice would be one of two things:

1) Allow an operator to selectively turn LAN-based media into PTP links as
seen by IS-IS.
2) Allow an operator to selectively define neighbors across LAN media and
associate metrics to each neighbor.

As I see it, both have pros and cons.  1) makes it easier on the operator,
as he/she only needs to set the link type to PTP, and the rest of the
configuration would be akin to real PTP interfaces.  However, it requires
the CLNS/IS-IS stack to be able to discover IS-IS (trivial) nodes and direct
IS-IS PDUs at it and only it, which sems non-trivial (this is where I need
assistance from the dvelopers).  2) makes it easier on the developers?, but
harder on the operator, as now the operator has to explicitly define
neighbors.  Another pro, however, is that this method conserves address
space, and eliminates the need to create and manage hundreds of VLANs per
switch.  Finally, I know of one vendor who has done this with OSPF, although
the IP-ness of OSPF may or may not make this easier, particularly to those
vendors with no interest in supporting a full CLNP stack.

I suppose that ES-IS could be used to resolve system IDs to MAC addresses in
2), and then IIH hellos could be hacked to use the learned MAC instead of
the standard multicast MAC addressed used in LAN IIHs.  But, is this hard to
do development-wise?  Is there a workable solution to 1)?  Could IS-IS be
made to send IIHs on LAN media without performing DIS election?

I sincerely hope I am not blowing a bunch of wind, but I am open to any and
all flaming if this idea is completely baseless.  If there is any interest,
I'd be very willing to contribute to a draft effort.

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

---

From: Bora Akyol <[email-masked]>
Date: Tue, 27 Feb 2001 10:57:36 -0800

What's wrong with using PPP over Ethernet to achieve what you want 
without changing anything else?

This is why PPPoE was invented.

Bora