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

From: "Martin, Christian" <[email-masked]>
Date: Tue, 7 Aug 2001 17:44:08 -0400

Folks,

I have some comments on the draft that I'd like to address with the WG.  I
apologize for cutting this so close to the meeting, but this is the first
chance I've had to address it.

A while back I began considering how IS-IS could be made to support PTP
behavior over BMA networks.  The driving force behind this was primarily the
ability to assign arbitrary, per-neighbor metric information to individual
neighbors.  A second benefit would be the elimination of pseudonode exposion
when a large amount of PTP LAN links were used to interconnect routers.  I
sent an email detailing the need to the WG, but there was little response.
Some notable vendors also displayed little interest.  The only suggestion I
received, in fact, was to use PPPoE!  After reviewing the draft, I have some
concern about the utility of the proposal, and whether or not it satisfies a
real need.  While it does have merit and will help in many situations, the
scope should be expanded to address some more complex situations.  Comments
of course are welcome.

In regards to OSPF:

OSPF currently supports NBMA networks.  What we are attempting to do here is
create PtMP (of where MP can be P if there are only two nodes on a LAN)
networks out of BMA networks in order to support PTP type behavior, from a
Djiktsra perspective, correct?  This is in OSPF today.  You can build NBNA
networks on LANs and specify neighbors explicitly, with associated metrics.
The Hello's and LSA exchange is PTP, using ARP for next-hop MAC resoultion
based on the configured neighbor IP.  As I see it, the only benefit the
draft provides is the elimination of DR election (and the corresponding
elimination of pseudonodes on PTP links), which can be done by making the
interface point-to-multipoint (although requiring configuration).  The major
vendors support this feature today (I use it!).  

In regards to IS-IS:

This was the tricky part, as there was nothing in 10589 or 1195 (or any
subsequent draft) that proposes how to do this.  Furthermore, the
interaction between CLNS and IP makes the address resolution issue a bit
trickier.  Anyway, here is what I was thinking of.

1) Create support for point-to-multipoint in IS-IS.  This has some
additional benefit outside of the scope of LANs, as it allows the protocol
to be used on real NBMA networks like Frame Relay and ATM.  The way to do
this is either cumbersome for the vendor or cumbersome for the operator.  It
also may break the current separation between subnetwork-dependent and
independent functions, which may not sit well with ISO (or some IETF
members).  Let's address 802.3 networks first.

As I see it, ISIS Hellos should be sent as PTP hellos.  This means sending
them to a MAC address and an interface.  The interface is then made
point-to-multipoint.  For each configured adjacency, assign a circuit ID
based on the current mechanism in 10589.  The PTP hellos must be
encapsulated in 802.3 frames, of course, but they should be unicast.  CSNP
should not be sent every 10 seconds, but rather in response to SRM flag
changes, etc.

Every router knows how to forward traffic across a LAN without passing it
through the DIS, based on SNPA information from adjacencies.  Forwarding
would be still based on SNPA information, which is easily extracted from the
configured MAC address of the neighbor (hence, the adjacency).  An
additional feature could be to address the neighbors based on NSAP, and then
use ES-IS or some other address resolution mechanism to determine the MAC
address.  Either way, forwarding is an issue local to the router, and should
not be much of an issue.  This is where the 'cumbersome-ness' shifts.

As far as switched WANs, the same principles could be applied.  However,
there is the issue of mapping NSAPs to layer 2 circuit IDs (DLCIs, VCCs,
etc) that isn't addressed outside of X.25 in ISO (AFAIK).  This may be too
much of an undertaking, although it may be worth consideration if there is
sufficient interest.   Some possiblilities would be to use static mapping of
NSAPs to l2cid, which is common today, and then specifiy the neighbor, the
interface, and the metric.

Finally, this information could be extended to support
draft-ietf-isis-traffic-03.txt, by including link coloring, reserved
bandwidth, etc, although the RSVP piece becomes trickier in the way it is
encoded on LANs and in the way one reserves bandwidth across virtual
adjacencies in a shared media environment.  Either way, they are workable
issues, and should be addressed given the growing ubiquity of TE-extension
support.

In summary:

1) Keep the changes at the subnetwork-dependent layer as much as possible,
i.e., make IS-IS think that a LAN link is a PTP link (or a collection of PtP
links).  This makes the modifications easier, development-wise.

2) Allow for both directly connected routers using LAN media as well as
directed adjacencies across BMA networks for metric adjustment.

3) If the specification is about removing DR election (which as it stands
now, it is), state this explicitly.  I still think this does not address all
the issues, particlularly, the use of switches as media termination and
router hubbing devices.

4) Optionally allow IS-IS to use NSAP addresses as neighbors and build some
kind of address resolution mechanism to direct PTP hellos to the appropriate
MAC address.

5) Allow per neighbor metric adjustment, and possibly pseudolink coloring
and reservable/reserved BW info.

6) Optionally consider mechanisms to build NBMA support into IS-IS for
switched WAN media.  PtMP mode would be best, although it requires
additional flooding, etc.  NBMA mode, as in OSPF, is nice but may be
difficult to do in most cases (except for SMDS)   ~8^>

7) If it is desired to just turn a LAN link into a PTP link, then this is
fine.  However, if what I propose is acceptable, then the error checking
portion of the draft needs to be modified to check for PtMP behavior first.

Finally, I would think that OSPF implementation modifications should be
submitted separately to the OSPF-WG, and not to the IS-IS WG.  As stated
earlier, a good deal of the desired functionality specified in the draft is
already specified in RFC 2328 and later versions, so it may be unnecessary.

Sorry this is so late - you may treat these comments as my contribution to
the London meeting, in absentia of course.  ;)

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

---

From: Alex Zinin <[email-masked]>
Date: Wed, 8 Aug 2001 05:32:11 +0100

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.

 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.

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

 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.

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

 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.

 Thanks,
 
-- 
Alex Zinin

---

From: Naiming Shen <[email-masked]>
Date: Wed, 08 Aug 2001 11:08:24 -0700

Martin,
	some comments inline, thanks.

 ]Folks,
 ]
 ]I have some comments on the draft that I'd like to address with the WG.  I
 ]apologize for cutting this so close to the meeting, but this is the first
 ]chance I've had to address it.
 ]
 ]A while back I began considering how IS-IS could be made to support PTP
 ]behavior over BMA networks.  The driving force behind this was primarily the
 ]ability to assign arbitrary, per-neighbor metric information to individual
 ]neighbors.  A second benefit would be the elimination of pseudonode exposion
 ]when a large amount of PTP LAN links were used to interconnect routers.  I
 ]sent an email detailing the need to the WG, but there was little response.
 ]Some notable vendors also displayed little interest.  The only suggestion I
 ]received, in fact, was to use PPPoE!  After reviewing the draft, I have some
 ]concern about the utility of the proposal, and whether or not it satisfies a
 ]real need.  While it does have merit and will help in many situations, the
 ]scope should be expanded to address some more complex situations.  Comments
 ]of course are welcome.
 ]
 ]In regards to OSPF:
 ]
 ]OSPF currently supports NBMA networks.  What we are attempting to do here is
 ]create PtMP (of where MP can be P if there are only two nodes on a LAN)
 ]networks out of BMA networks in order to support PTP type behavior, from a
 ]Djiktsra perspective, correct?  This is in OSPF today.  You can build NBNA
 ]networks on LANs and specify neighbors explicitly, with associated metrics.
 ]The Hello's and LSA exchange is PTP, using ARP for next-hop MAC resoultion
 ]based on the configured neighbor IP.  As I see it, the only benefit the
 ]draft provides is the elimination of DR election (and the corresponding
 ]elimination of pseudonodes on PTP links), which can be done by making the
 ]interface point-to-multipoint (although requiring configuration).  The major
 ]vendors support this feature today (I use it!).  

no comments on OSPF;-)

 ]
 ]In regards to IS-IS:
 ]
 ]This was the tricky part, as there was nothing in 10589 or 1195 (or any
 ]subsequent draft) that proposes how to do this.  Furthermore, the
 ]interaction between CLNS and IP makes the address resolution issue a bit
 ]trickier.  Anyway, here is what I was thinking of.

general comment is that, this draft is an ietf draft, we are trying to solve
some real problems on today's Internet, no attempt is made here trying to
tie this into clns and make it so complicated so no prograss will be made
for years to come. This draft only needs some very simple changes(almost
no changes to the existing protocols) and make the p2p over LAN work for
the IP protocol. it's so simple that it's almost emberassing to make it
as an Internet draft:-)
For most of the current router implementations, the major change proposed
from this draft is to add a configuration knob. that's probably it.

 ]
 ]1) Create support for point-to-multipoint in IS-IS.  This has some
 ]additional benefit outside of the scope of LANs, as it allows the protocol
 ]to be used on real NBMA networks like Frame Relay and ATM.  The way to do
 ]this is either cumbersome for the vendor or cumbersome for the operator.  It
 ]also may break the current separation between subnetwork-dependent and
 ]independent functions, which may not sit well with ISO (or some IETF
 ]members).  Let's address 802.3 networks first.

My feeling is this, isis does not have NBMA for so long since OSPF has 
"invented" it, with atm/frame relay "legacy" services less popular
these days, i don't see a requirement to do this in ISIS for now.
Even with OSPF, as i remember when i was with previous companies,
we alwasy "advise" customers to use point-to-point when link-state
protocols are used for obvious reasons the problems NBMA has.
Yes, we can develop the nbma for isis, then adapt the nbma for the
LAN, but don't think it's worth the effort.

 ]
 ]As I see it, ISIS Hellos should be sent as PTP hellos.  This means sending
 ]them to a MAC address and an interface.  The interface is then made
 ]point-to-multipoint.  For each configured adjacency, assign a circuit ID
 ]based on the current mechanism in 10589.  The PTP hellos must be
 ]encapsulated in 802.3 frames, of course, but they should be unicast.  CSNP
 ]should not be sent every 10 seconds, but rather in response to SRM flag
 ]changes, etc.
 ]
 ]Every router knows how to forward traffic across a LAN without passing it
 ]through the DIS, based on SNPA information from adjacencies.  Forwarding
 ]would be still based on SNPA information, which is easily extracted from the
 ]configured MAC address of the neighbor (hence, the adjacency).  An
 ]additional feature could be to address the neighbors based on NSAP, and then
 ]use ES-IS or some other address resolution mechanism to determine the MAC
 ]address.  Either way, forwarding is an issue local to the router, and should
 ]not be much of an issue.  This is where the 'cumbersome-ness' shifts.
 ]
 ]As far as switched WANs, the same principles could be applied.  However,
 ]there is the issue of mapping NSAPs to layer 2 circuit IDs (DLCIs, VCCs,
 ]etc) that isn't addressed outside of X.25 in ISO (AFAIK).  This may be too
 ]much of an undertaking, although it may be worth consideration if there is
 ]sufficient interest.   Some possiblilities would be to use static mapping of
 ]NSAPs to l2cid, which is common today, and then specifiy the neighbor, the
 ]interface, and the metric.
 ]
 ]Finally, this information could be extended to support
 ]draft-ietf-isis-traffic-03.txt, by including link coloring, reserved
 ]bandwidth, etc, although the RSVP piece becomes trickier in the way it is
 ]encoded on LANs and in the way one reserves bandwidth across virtual
 ]adjacencies in a shared media environment.  Either way, they are workable
 ]issues, and should be addressed given the growing ubiquity of TE-extension
 ]support.

when a circuit is a p2p-over-lan, it's just an p2p circuit to IGP, nothing
says it can't carry TE TLV in it's LSPs.

 ]
 ]In summary:
 ]
 ]1) Keep the changes at the subnetwork-dependent layer as much as possible,
 ]i.e., make IS-IS think that a LAN link is a PTP link (or a collection of PtP
 ]links).  This makes the modifications easier, development-wise.

this draft only lets level-3 IGP knows this interface is a "p2p", no one else
needs to know that. So the IGP thinks this is a p2p interface, and lower
layer thinks(actually it is) a broadcast interface, that's it.

 ]
 ]2) Allow for both directly connected routers using LAN media as well as
 ]directed adjacencies across BMA networks for metric adjustment.
 ]
 ]3) If the specification is about removing DR election (which as it stands
 ]now, it is), state this explicitly.  I still think this does not address all
 ]the issues, particlularly, the use of switches as media termination and
 ]router hubbing devices.

well, it's a p2p circuit to IGP, no DR is needed, there is no need to
explitely say that no DR election is needed on a p2p circuit. DR is only
relavernt to IGP, not to layer two or below.

I don't see how using a switch in the middle will change anything, swich
is a layer two device, and we don't change anything on layer two here.

 ]
 ]4) Optionally allow IS-IS to use NSAP addresses as neighbors and build some
 ]kind of address resolution mechanism to direct PTP hellos to the appropriate
 ]MAC address.

if you mean to include mac address resolution for clns, we don't try to
do this here.

 ]
 ]5) Allow per neighbor metric adjustment, and possibly pseudolink coloring
 ]and reservable/reserved BW info.

metric you of course can adjust, it's an isis circuit. color or other TE
attributes is the same as normal p2p interface. you can do that too.

 ]
 ]6) Optionally consider mechanisms to build NBMA support into IS-IS for
 ]switched WAN media.  PtMP mode would be best, although it requires
 ]additional flooding, etc.  NBMA mode, as in OSPF, is nice but may be
 ]difficult to do in most cases (except for SMDS)   ~8^>

not in this draft, someone else can try.

 ]
 ]7) If it is desired to just turn a LAN link into a PTP link, then this is
 ]fine.  However, if what I propose is acceptable, then the error checking
 ]portion of the draft needs to be modified to check for PtMP behavior first.

not sure what error checking needs to be done, no ptmp attempt is being made.

 ]
 ]Finally, I would think that OSPF implementation modifications should be
 ]submitted separately to the OSPF-WG, and not to the IS-IS WG.  As stated
 ]earlier, a good deal of the desired functionality specified in the draft is
 ]already specified in RFC 2328 and later versions, so it may be unnecessary.

we can only submit into one working group, doesn't make sense to break this
draft into isis, ospf, arp, etc seperate portions.

the change on OSPF of this draft is that: NO CHANGE AT ALL.
we can't find arp working group.
so it goes into isis working group;-)

 ]
 ]Sorry this is so late - you may treat these comments as my contribution to
 ]the London meeting, in absentia of course.  ;)

appreciate for your comments.
thanks.

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

- Naiming

---

From: Jeff Learman <[email-masked]>
Date: Wed, 08 Aug 2001 18:18:31 -0400

>LAN, but don't think it's worth the effort.

ISO 8473-1988 defined "general topology" networks, which are
non-broadcast, multiple-access networks.  X.25 is an example, and
connectionless networks can be GT networks.

IS-IS does not support exchange of routing information over GT
networks unless they are modeled as collections of statically
enabled point-to-point links.  I don't know why, but perhaps
it was because X.25 was the only prevalent GT network at the time,
and it didn't make sense to have an SVC when exchanging periodic PDUs.
Using an IGP over GT net certainly makes more sense for connectionless
than for connection-oriented.

Jeff

---

From: Acee Lindem <[email-masked]>
Date: Wed, 08 Aug 2001 14:41:02 -0400

Martin,

As you suggest, OSPF P2P over LAN is similiar to OSPF P2MP and they
offer many of the same advantages. The arguments (which some may consider weak)
for OSPF P2P over LAN are:

   1. It allows a LAN or vLAN that is being used as P2P link to be viewed 
      and configured as one. 
   2. It allows for unnumbered operation of a LAN or vLAN being used as P2P link. 
   3. It offers a unified view of the LAN or vLAN across OSPF and ISIS (since
      ISIS does not have P2MP). 

Thanks,
-- Acee