Subject: 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: Thu, 28 Jul 2005 15:53:03 +0200

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 : [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.
>

---

From: Arthi Ayyangar <[email-masked]>
Date: Thu, 28 Jul 2005 10:33:36 -0700 (PDT)

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..."
>
> 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.
> 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.

---

From: Arthi Ayyangar <[email-masked]>
Date: Thu, 28 Jul 2005 10:39:23 -0700 (PDT)

> > reoptimization (with potential change of border LSRs) also apply to
                      agree
> AA-------> I couldn't ^ more.

-arthi