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

From: Kohei Shiomoto <[email-masked]>
Date: Wed, 09 Nov 2005 06:14:27 +0900

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.
>>>
>>> [email-masked] 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 
>>>> [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-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-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
>>>> [email-masked]
>>
>>
>>