Hi Igor,
I think you have to set the context of this I-D carefully, and then
understand the limited scope that is additionally proposed.
The context of the I-D is limited to the per-domain computation
case.
Hence, consulting an external PCE is out of scope. This is not to
say that
it is not valid to consult a PCE (in fact, you might expect JP
and me to
support that technique), but this I-D is demonstrating what we
can do and
how we can solve the problem without using PCE.
With respect to the use of the IP reachability, you may recall
that I
raised this concern in Paris and on the list. The conclusion was
that if
you have no other way of determining an exit router for your
domain, then
attempting to use the IP reachability is no worse than giving up,
and may
be much better.
In the cases you raise:
1. Yes, an interface address may be unreachable.
Do we lose anything by consulting IP reachability in this case?
No.
2. Yes, the IP reachability may give us a sub-optimal TE path.
Is this path worse than no path?
No.
So I asked the authors to be clear that what they are suggesting has
limitations, and should not be applied in some specific cases. I
haven't
looked at the text yet, but I hope they have covered this.
Cheers,
Adrian
----- Original Message -----
From: "Igor Bryskin" <ibryskin@movaz.com>
To: <jpv@cisco.com>; "Arthi Ayyangar" <arthi@juniper.net>
Cc: <ccamp@ops.ietf.org>
Sent: Friday, October 21, 2005 4:27 PM
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-
comp-01.txt
Arthi, JP
I have a problem with the auto-discovery mechanism you described
in the
draft (one that is based on query to IGP or BGP to determine
outgoing
ABR/ASBR).
1. Destination ID must be network unique but it does not have to
be IP
routable, for example, it could be a numbered link ID.
2. Even in case when destination is IP address, the path
computing node
can
only obtain the ID of an ABR or ASBR that advertises IP route to
the
destination, which would be one that knows about the shortest IP
path to
the
destination. However, it does not mean that properly constrained
TE path
from this ABR/ASBR to the destination or the next ABR/ASBR
exist, or is
not
suboptimal compared to one from some other ABR/ASBR which knows
about
worse
IP path to the destination and hence will not be reported to the
computing
entity by the routing sub-system.
I wonder why not to use the remote PCE service for this purpose.
For
instance a PCC may ask a PCE to determine either the ID of the
outgoing
domain border node or entire path in terms of domain border
nodes. You
may
ask why not to request explicit path(s) in this case? Several
reasons
why
the PCC wouldn't want to do so:
a) it could be easier and faster for the PCE to determine domain
border
node
in direction towards the destination rather than explicit path
(s). For
instance, the latter may require cooperation of other PCEs;
b) security considerations - PCE may not want to reveal remote
domain
topology(ies)
c) it may be desirable to compute and setup services on per-domain
basis,
for instance, to have each domain take separate care for service
restoration.
What do you think?
Igor
----- Original Message -----
From: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Cc: <ccamp@ops.ietf.org>
Sent: Thursday, October 20, 2005 6:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-
comp-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Common Control and Measurement
Plane
Working Group of the IETF.
Title : A Per-domain path computation method for establishing
Inter-domain Traffic Engineering (TE)
Label
Switched Paths (LSPs)
Author(s) : J. Vasseur, et al.
Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
Pages : 18
Date : 2005-10-20
This document specifies a per-domain path computation technique
for
establishing inter-domain Traffic Engineering (TE)
Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths
(LSPs). In this document a domain refers to a collection of
network
elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous
Systems.
Per-domain computation applies where the full path of an inter-
domain
TE LSP cannot be or is not determined at the ingress node of
the TE
LSP, and is not signaled across domain boundaries. This is most
likely
to arise owing to TE visibility limitations. The signaling message
indicates the destination and nodes up to the next domain
boundary. It
may also indicate further domain boundaries or domain
identifiers. The
path through each domain, possibly including the choice of exit
point
from the domain, must be determined within the domain.
A URL for this Internet-Draft is: