[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: spc connections

Adrian,

Here is my attempt to make sense of things (and address your questions below).

An ERO is a protocol specific instance of G.7713's Explicit Resource List, which
specifies the route of a connection. Some services are realized by multiple
connections, which may have different EROs. This detail may be a bit less clear
for services that are implemented by just one connection, but certainly an ERO is
associated with a connection.

Under some circumstances a service request may contain constraints. Thus
a list of resources to use to realize a service (like an ERO) may be included
in a service request. However, service providers often want to maintain control
of routing in their networks, and in fact hide internal network details (topology,
addressing, etc.) from service requesters outside the network. Therefore, a
reasonable policy would be to ignore EROs received from some service requesters.

Clearly, it is up to the service requester to specify the endpoints for a service
request. These endpoints are specified using identifiers for Access Group Containers
(AGC) which are taken from a different space from that used for internal network addresses.

Specifying the service endpoint in the ERO is possible; however, this leads to
some problems:

1) The endpoint must be specified using an internal network address. This may be
unacceptable for service providers involved in inter-domain SPC setup that do not
want to publish internal addresses outside their domain.

2) To avoid publishing internal addresses, AGC IDs could be used instead; however this
would require extending the ERO definition to carry AGC IDs.

3) ERO processing rules must be enhanced to include methods for determining, based on
content, whether (or what parts of) an ERO should be honored for a given service
requester. (A simple "ignore" policy is no longer adequate.)

These problems are more easily addressed (or don't arise) if the endpoint identification
is encoded in an object separate from the ERO.

Regards,
Ben


Adrian Farrel wrote:

Just another 2 cents.

Lyndon correctly says that 3473 does not make the use of egress label control properly
clear.
John and Lou are right that the intention of the authors was to embrace egress label
control.

Two small points worry me.
Lyndon says
...the ERO, which may typically be calculated by the
source endpoint rather than passed down from the management system.
and Ben says


In fulfilling a service request, a service provider may disregard the ERO
but may not disregard the service request.



Why is the ERO not considered as part of the service request?
For example, the service requester may have some strong views about which nodes should be
included on the path.
The service provider may run path computation on the (partial) ERO supplied by the
requester.

Even when the ERO from the requester is otherwise empty, it *could* contain the
destination node and egress label.


I think we are arguing about whether implementations can be produced for one solution or
the other. I'm sure they can.

In the debate about whether we have or need to have more than one solution, we should look
at what has been implemented and deployed. We can then decide whether it is harmful to
have two solutions, and whether we need to deprecate one of them.

Adrian







-----------------------------------------
============================================================
The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================