Subject: Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 09 Mar 2006 12:07:29 +0100

hi all, some comments on the problem statement of this doc:

"(2) How to identify the routing instance in which such an advertisement 
should happen."

but by definition it is the same instance when speaking about an FA (or 
are we not speaking about FA's only (?) the previous paragraph seems to 
indicate this is not the case

"In order for the egress of an LSP to be able to advertise the LSP as
a TE link it needs to know that such an advertisement is desirable, "

ok this is a trigger issue

"and it also needs to know the TE Router ID of the ingress LSR.
(Please recall that the Router ID of the other end of the link is set
in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA
[RFC3630].)"

don't understand this; the Router ID is known and the TE router ID is 
known as well (part of the TEDB) ... what's the purpose of this new 
requirement (as there is no TE router ID part of the corr. link TLV)

clarifications appreciated,

in general, if a clearer procedure for numbered FA signaling could be 
devised that would be a good achievement, this said, i am for inst. 
unclear about these R and F bits ... where does numbered FA only adv. 
per RFC4206 is reproduced here ? what "adv. an FA in an IP network" 
means ? why restrict adv. to MPLS-TE and IP networks only ? etc.

imho, the issue of the trigger is part of a larger discussion around FA 
policing ... in brief, providing a cleaner procedure for numbered FA's 
is advisable but complexifying procedures by incorporating policing 
related actions is not advisable

thanks,
- dimitri.

[email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Advertisement of hierarchical and stitchable Label Switched Paths as Traffic Engineering Links
> 	Author(s)	: K. Shiomoto, et al.
> 	Filename	: draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt
> 	Pages		: 17
> 	Date		: 2006-3-7
> 	
> This document addresses topics related to hierarchical and stitched 
> Generalized Multiprotocol Label Switching (GMPLS) Label Switched 
> Paths (LSPs).  It describes extensions to allow an egress to identify 
> that a bi-directional LSP will be used as a dynamically signaled 
> Forwarding Adjacency LSP (FA-LSP) or Routing Adjacency (RA). In 
> addition, the document also addresses the issue of how to indicate 
> that an LSP should be advertised as a traffic engineering (TE) link 
> into a different instance of the IGP and how to identify the instance 
> that should be used.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-01.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-shiomoto-ccamp-lsp-hierarchy-bis-01.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-shiomoto-ccamp-lsp-hierarchy-bis-01.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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 9 Mar 2006 07:24:30 -0800 (PST)

Hi,
   
  I think this is a useful document. I've also noticed quite a significant effort to improve the solution compared to the previous revision.
   
  I believe there is one aspect (which is not covered yet) that would make the document even stronger. So far we do not have a way to bundle dynamic parallel H-LSPs and advertise them as a single TE link. Note that bundling could be different depending on routing instance the TE link is advertised in. For instance, it is possible to advertise parallel H-LSPs into one routing instance as separate TE links, into another as a single TE link and into the third as several TE links (with each of them bundling two or more H-LSPs).
   
  The simple solution would be to allow assigning the same link IDs (numbered or unnumbered) by H-LSP ingresses to H-LSPs that need to be bundled before advertising into particular routing instance.
   
  If you agree with such approach, it would be good to have an abstract describing the H-LSP bundling.
   
  Thanks,
  Igor

> implementation to automatically retrieve the ASCII version of the

---------------------------------
Brings words and photos together (easily) with
 PhotoMail  - it's free and works with Yahoo! Mail.