The MPLS WG Archive

[Curtis Villamizar <curtis@avici.com>]

In message <38EA1FD2.6FDB1170@tellium.com>, Bala Rajagopalan writes:
> Curtis:
> 
> ... So, it's perhaps useful to just focus on
> interface functional requirements (including routing) and not
> worry too much about the terminology.
> 
> Regards,
> 
> Bala


The OIF can continue to work on the "open" model and they can, just
like the ATMF before them, ignore issues (like IP routing) that are
critical to building IP networks if that is what they are inclined to
do.  Is so, the outcome may be no more useful than the ATMF vision of
a big global ATM network with IP routers and host around the perimeter
finding the right path by magic (or by NHRP which doesn't work).

In the IETF (not the OIF) we may need terminology to describe a set of
proposals that involve using MPLS over optical.  If so, the terms
below might be appropriate and descriptive and cover the set of
(reasonably sane) proposals that have been discussed.

btw- By endpoints I do mean endpoints of an ATM VC or endpoints of a
PSC in the terminology used in draft-kompella-mpls-optical-00.txt.
This does not imply endpoints on the Internet (a pair of hosts) or
even customer ingress or egress, just boundaries of an optical region
which could be a traffic engineered optical backbone or a traffic
engineered regional or metropolitan area that makes up part of a
provider's network.

Curtis


[...]
> > Juha may have added a fourth case.  The following table might help.
> >
> >    router's topology  type of
> >    visibility         path setup      model name           example
> >
> >     configured*        none            static overlay       ATM-PVC
> >     configured*        endpoint        signaled overlay     ATM-SVC
> >     endpoints          endpoint        dynamic overlay      MPLS-loose
> >     full               full path       peer                 MPLS-strict
> >
> >    *configured here means endpoints only are configured in the router.
> >
> > The model Juha proposed is a slight improvement over the pure ATM SVC
> > model in that the endpoints to the ATM are advertised for the purpose
> > of making ATM call setups.  This model seems similar to the use of
> > MPLS with a single loose hop in the explicit route.  It is similar in
> > that the ingress knows about the endpoint through signaling rather
> > than configuration but leaves it to the next (signaling) hop (which
> > would be an optical device) to figure out how to get there.  If the
> > ingress had enough information to compute the path, we'd have the peer
> > model and the ingress would use strict hops in the explicit route.
> >
> > It wouldn't hurt to add the distinction that Juha has pointed out and
> > adapt the term "dynamic overlay" that he suggested.  I hope this
> > terminology is clear.  We seem to have some growing consensus on these
> > model names.