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

From: dimitri papadimitriou <[email-masked]>
Date: Tue, 18 Oct 2005 23:35:39 +0200

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;

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

another more specific question on this document, what is the definition 
of the value space for the "Target Control Plane Instance" ?

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 ?

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]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Kohei Shiomoto <[email-masked]>
Date: Wed, 19 Oct 2005 09:18:13 +0900

Hi Dimitri,

> is only a matter of indicating to which instance this advertisement 

I am happy if you could point out what is missing.
> otherwise after their creation there may be no easy way to communicate 

The draft proposes the method to advertise the LSP created in the GMPLS
domain to the different routing instance, MPLS domain for instance.

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

> mechanism will make dynamically triggered numbered FA a reality ?

I hope so.

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.

>>     Title        : Advertisement of hierarchical and stitchable LSPs 
>> as TE Links     Author(s)    : K. Shiomoto, et al.
>> 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.  
>> [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.
>>
>>
>> http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>     "FILE 
>> /internet-drafts/draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt".
>>

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 19 Oct 2005 14:34:01 +0200

hi kohei

> 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

> 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

> 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

>>mechanism will make dynamically triggered numbered FA a reality ?

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

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 20 Oct 2005 14:45:30 -0400

Hi,

I believe the draft could be very useful. I have several suggestions that
IMO would make it stronger.

  1.. It is possible that the same H-LSP is advertised into several control
planes (for example, L1VPN provider H-LSP could be advertised into several
VPNs in the Virtual Link mode) each time with different link IDs (possibly
sometimes as numbered and sometimes as unnumbered). This fact could be
negotiated between the H-LSP ends by including several
LSP_TUNNEL_INTERFACE_ID objects (one per target control plane) into
Path/Resv message. I've probably missed it, but I didn't see anywhere in the
draft an explicit statement of such possibility.
  2.. There are no currently any signaling mechanisms for negotiating how
parallel H-LSPs should be bundled together before advertising them as a TE
link. Normally, such negotiation is provided via LMP. However, you suggest
(and rightfully so) to avoid using LMP for TE links based on H-LSPs, hence,
all negotiations should be achieved via signaling. Note that bundling
schemes could be different for each target control plane. One way of
achieving this is by introducing a new sub-TLV of the
LSP_TUNNEL_INTERFACE_ID object - let's call it BUNDLE sub-TLV - and have the
ends of the H-LSPs to bundle those H-LSPs which share the same bundle ID for
the same target control plane. Note also that bundle ID could be used as a
link ID when advertising the bundle as a single TE link
  3.. H-LSP does not necessarily have to be advertised as a TE link into any
control plane. For instance, an H-LSP could be used as a dedicated
protection for some other H-LSP or as a data link for a higher layer LSPs
(note that not all data links are advertised as TE links). However, in order
for such H-LSP to be capable to nest other LSPs the ends of the H-LSP need
to know at least that the LSP is intended to be used as H-LSP (that is,
resources will be dynamically allocated within the LSP)  as well as remote
link IDs (otherwise, it would impossible to map the information in the PHOP
object with the local end of the link). Again, usually this is the job of
the LMP. One way to signal an H-LSP that needs not to be advertised into any
control plane is to specify some special value (e.g. NULL) as a target
control plane ID.

Regards,

Igor