[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt
Hi Dimitri
Sorry for not responding sooner.
> 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-end
> 2. 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
>
I assume that the both endpoints are in the same area. Routing adjacency
could be brought up on it if needed.
>>> 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 unavailability
>>
>>
>> The 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
Yes, routing convergence time may be higher.
>
>>> 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 any
>> recommendation, 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
Here I am assuming that several independent service networks are
provided on top of a common GMPLS-based network. Target control plane
instance is used to identify the service network. Route Distinguisher
might be used for this purpose. In addition, it might be a good idea to
add Area ID.
>
>>> 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-18
>>>> This 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.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-shiomoto-ccamp-lsp-hierarchy-bis-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-shiomoto-ccamp-lsp-hierarchy-bis-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.
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> I-D-Announce@ietf.org
>>
>>
>>