[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of the
message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>