[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Hi JL,
(You seem to be on a roll...14 IDs down, 4 to go... :-))
> A few comments related to your inter-domain pd draft
AA---> Thanks for the comments.
> -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...
AA-------> True. This needs to be addressed. The procedures would require
interaction with BGP to find the ASBR exit point for the nexthop AS.
> -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...
AA---------> Actually the section on Assumptions where we introduce
Auto-discovery does say that it would rely on IGP and/or BGP information.
Would you just like us to expand that to include use of local policies
in conjuction with the above information when there are sevaral downstream
candidates ?
> -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)
AA----> This is what happens when drafts are merged, split, re-named; etc.
:-). One of the versions of the draft actually explained what "candidate"
meant...Well...
This means that if the LSR has no local policy for nesting or stitching
the inter-domain LSP, then it would simply set up a contiguous LSP.
Also, I think we need to fix the assumption that FA LSPs or LSP
segments can exist only between domain boundary LSRs. It might be the
case, but it is not necessary.
> -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
AA-----> Okay.
> -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.
AA--------> I agree completely.
>
> Also it would be useful to mention that pd inter-domain backup path
may requires XRO incusion in RSVP messages...
AA-----> That's fine. This is useful for any computation where loose hop
expansion occurs in different domains.
> -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.
AA-------> I couldn't more.
thanks,
-arthi
In both cases, contiguous or stiching/nesting, PCE or
> any offline computation is required to achieve end-to-end
> reoptimization.
>
>
>
>
> > -----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.
> >
>