[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Hi JP, Arthi Raymond
A few comments related to your inter-domain pd draft
-Section: 1) common assumptions,
Why not adding and addressing the case where a path is made of a set of abstract nodes?
For instance, in the inter-AS case, an ERO may list a set of ASes. This may require specific procedures when computing the path and selecting the downstream ASBR...
-Section 4: 1)
Even if this is not really in the scope I think that the auto-discovery mechanism would require some more words. This is partially addressed latter in the draft(4.2.1), but you should mention here that such auto-discovery may rely on IGP information and/or BGP information and also on local policies (particularly in inter-AS/SP case).
In the inter-AS/SP case there may be several candidate downstream ASBRs, pertaining to distinct ASes/SPs, and the downstream AS selection may require appying policies related to specific "TE peering contract" negociated with neigbors Ases/SPs...
-Section 4 2) b) ii) What do you exactly mean by "the boundary LSR is not a FA-LSP/LSP segment candidate"?
Does it mean in this case, that a contigous LSP is created?, this would not be consistent with b)
-Top of Section 4.1.1: You should remove the first sentence after the three path examples,
"At least the set", as this sounds an ambiguous repetition of what is just stated above
-Section 6.2:
"If the Inter-AS TE related Information is flooded in the IGP, each ASBR is capable of computing the path..."
Actually there may be some topologies where an ASBR cannot compute a link protection path.
See the following example
AS1--> <---AS2----
ASBR1----ASBR2
| |
| |
ASBR3----ASBR4
ASBR1 is aware of links ASBR1->ASBR2, ASBR1->ASBR3 and ASBR3->ASBR4 but not the link ASBR2->ASBR4 as there is no flooding between AS1 and AS2.
Hence ASBR1 cannot compute a path to protect link ASBR1-ASBR2.
Actually this case is similar to node protection issue, the path should be computed according to the pd computation methods defined in the doc.
Also it would be useful to mention that pd inter-domain backup path may requires XRO incusion in RSVP messages...
-Section 7.2
"Note that stiching or nesting rely on local optimization...hence the reoptimization is not global and...
Procedures describes in loose hop MUST be used...
"
It would be good to mention that global PCE-based reoptimization (with potential change of border LSRs) also apply to stiching/nesting.
In both cases, contiguous or stiching/nesting, PCE or any offline computation is required to achieve end-to-end reoptimization.
Hope it helps,
Best Regards,
JL
> -----Message d'origine-----
> De : owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] De la part de
> Internet-Drafts@ietf.org
> Envoyé : vendredi 15 avril 2005 21:34
> À : i-d-announce@ietf.org
> Cc : ccamp@ops.ietf.org
> Objet : I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.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
> computing Inter-domain Traffic
> Engineering (TE)
> Label Switched Path (LSP)
> Author(s) : J. Vasseur, et al.
> Filename :
> draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
> Pages : 0
> Date : 2005-4-15
>
> This document specifies a per-domain path computation method
> for computing inter-domain Traffic Engineering (TE)
> Multiprotocol Label Switching (MPLS) and Generalized MPLS
> (GMPLS) Label Switched (LSP) paths. In this document a domain
> is referred to as a collection of network elements within a
> common sphere of address management or path computational
> responsibility such as IGP areas and Autonomous Systems.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-dom
> ain-pd-path-comp-00.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-00.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-00.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.
>