[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 Arthi
> 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 ?
Yes that would be good, as actually, in an inter-SP context, such policies based on the so called "TE peering contracts" might be of huge importance...
Thanks,
JL
> -----Message d'origine-----
> De : Arthi Ayyangar [mailto:arthi@juniper.net]
> Envoyé : jeudi 28 juillet 2005 19:34
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : JP Vasseur; Raymond_Zhang@infonet.com; ccamp@ops.ietf.org
> Objet : 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
> AA-------> 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 ?
Yes that would be good, as actually in an inter-SP context these policies might be
of huge importance
>
>
> > -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.
> > >
> >
>