Subject: RE: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 29 Jul 2005 11:18:49 +0200

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:[email-masked]] 
> Envoyé : jeudi 28 juillet 2005 19:34
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : JP Vasseur; [email-masked]; [email-masked]
> 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 : [email-masked]
> > > [mailto:[email-masked]] De la part de 
> > > [email-masked] Envoyé : vendredi 15 avril 2005 
> 21:34 À : 
> > > [email-masked] Cc : [email-masked] 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 
> > > [email-masked] 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:
> > > 	[email-masked].
> > > 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.
> > >
> >
>