hi kohei Kohei Shiomoto wrote:
Hi Dimitri, dimitri papadimitriou wrote:all,i don't think the issues of advertising an LSP as a TE link in another instance of the control plane than the one used for creating the LSP - ditto"[HIERAR] did not consider scenarios where an LSP is created (and maintained) by one instance of the GMPLS control plane, and is used as a (TE) link by another instance of the GMPLS control plane."is only a matter of indicating to which instance this advertisement should be done;I am happy if you could point out what is missing.
it is a matter of knowing whether the head-end (of the "LSP") is 1. within the same area than the tail-end2. the advertisement generated by the tail-end is going to reach the head-end and vice versa (as i think the draft makes no assumption about the routing adjacencies that allows exchanging this information) - note: this condition was kind of implicitly guaranteed in the [HIER] document
now, in addition to the "routing" part, there is the whole discussion about the maintenance of the (inherited) TE link - as we are speaking here about separate instance - some specific mechanism may be needed otherwise after their creation there may be no easy way to communicate their unavailabilityThe draft proposes the method to advertise the LSP created in the GMPLS domain to the different routing instance, MPLS domain for instance.
the difference is now that either you rely on the signaling capabilities to tell you (Notify, PathErr) whether the LSP is down - but you have to pass the information to the upper instance - or you are being made aware from the upper instance advertisement but the convergence time may be higher now there is a side issue here a loss of routing adjacency may be such that you loss a TE link even if the TE link is not down
another more specific question on this document, what is the definition of the value space for the "Target Control Plane Instance" ?Good question. We use a 32-bit space at this time. If you have anyrecommendation, I would be happy to hear that. You think that RD might be a good choice for instance, don't you.
what do you mean by RD ? i would say for instance the Area ID in OSPF
a last point, section 4 mentions"This is not believed to be an issue as an informal survey indicated that dynamically signalled numbered FAs had not been deployed. Indeed it was the attempt to implement numbered FAs that gave rise to the work on this document." ... is there a general feeling that having this mechanism will make dynamically triggered numbered FA a reality ?I hope so.
it may be a good sense to know whether provisioned numbered FAs where used before advising a specific mechanism for triggered once - do we have some feedback on this ?
thanks, - dimitri.
Thank you for your comments. --- Kohei PS I am now about to be on trip. I may not be able to respond timely. I apologize.thanks, - dimitri. Internet-Drafts@ietf.org wrote:A New Internet-Draft is available from the on-line Internet-Drafts directories.Title : Advertisement of hierarchical and stitchable LSPs as TE Links Author(s) : K. Shiomoto, et al.Filename : draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt Pages : 15 Date : 2005-10-18This document addresses topics related to hierarchical and stitched Label Switched Paths (LSPs). It describes extensions to allow an egress to identify that an LSP will be used as a dynamically signaled Forwarding Adjacency LSP (FA-LSP) in the case of numbered FA's. In addition, the document addresses the issue of how to indicate that an LSP should be advertised as a TE link into a different instance of the control plane 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-00.txtTo 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-shiomoto-ccamp-lsp-hierarchy-bis-00.txt". A list of Internet-Drafts directories can be found inhttp://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txtInternet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type:"FILE /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt". NOTE: The mail server at ietf.org can return the document inMIME-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 readerimplementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org.