Re: [CCAMP] John's Terminology (Was RE: RSVP OTN single stage vs multi stage)

Hi Khuzema,

For your idea, the requirement and solution have been described in our 
draft 
http://tools.ietf.org/html/draft-fuxh-ccamp-boundary-explicit-control-ext-03.
It isn't a new requirement. It has been raised for several meeting times.

Xihua

Khuzema Pithewan <kpithewan@infinera.com> 
发件人:  ccamp-bounces@ietf.org
2011-07-23 上午 07:22

收件人
Lou Berger <lberger@labn.net>, Rajan Rao <rrao@infinera.com>
抄送
CCAMP <ccamp@ietf.org>, Mohit Misra <mmisra@infinera.com>
主题
Re: [CCAMP] John's Terminology (Was RE: RSVP OTN single stage vs multi 
stage)

Hi Lou,

We do want to highlight a new requirement (and a possible solution) 
regarding "how to control the origination point of implicit H-LSP" through 
ERO. Service layer LSP request should have an option to contain enough 
information to identify where the implicit LSP originating from and where 
it is terminating. This detail should include, for each layer, the 
Interface ID and OPU time slot  to complete the specification.

Thanks
Khuzema & Rajan

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Friday, July 22, 2011 7:13 AM
To: Rajan Rao
Cc: John E Drake; CCAMP; Ashok Kunjidhapatham; Khuzema Pithewan; Biao Lu; 
Mohit Misra
Subject: Re: [CCAMP] John's Terminology (Was RE: RSVP OTN single stage vs 
multi stage)

Guys,
                 I'm sorry, I don't understand the point of your mail.

Is it:
1) definition related: to make a comment on the definition of "implicit 
H-LSP"
2) requirements related: to highlight a new requirement/challenge related 
to the control of "implicit H-LSPs" via "implicit-link LSPs"
3) solution related: to state a solution to a new requirement/challenge 
related to the control of "implicit H-LSPs"
4) something else

BTW my intent on this particular thread was to keep the discussion focused 
on definitions and requirements, not solutions.  We can move onto 
solutions once we have agreement on terms and requirements.

Lou

On 7/21/2011 8:45 PM, Rajan Rao wrote:
> Hi,
> 
> The use of "implicit H-LSP" could be problematic as far as use of 
> explicit routing is concerned.  In explicit routing case we need a way 
> to specify  origination point of implicit-HLSP(s), i.e. the ODU
> layer(s) and the time slots.
> 
> One way to specify the origination point in explicit route is to use a 
> new label format which captures hierarchy details including time 
> slots.
> 
> The multi-stage label can be used to instantiate "implicit H-LSP(s)"
> optionally and to  address the above case.
> 
> Thanks
> Rajan & Khuzema
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, July 13, 2011 7:55 AM
> To: Rajan Rao
> Cc: John E Drake; CCAMP; Ashok Kunjidhapatham; Khuzema Pithewan; Biao 
> Lu; Mohit Misra
> Subject: Re: [CCAMP] John's Terminology (Was RE: RSVP OTN single stage 
> vs multi stage)
> 
> Rajan,
>                See below for in-line responses.
> 
> On 7/13/2011 6:22 AM, Rajan Rao wrote:
>> Lou,
>>
>> The 4th LSP type (implicit-link LSP) is not very clear. This seems to 
>> represent the service-LSP which induces implicit H-LSPs (type #3). In 
>> which case this should be a regular LSP (type#1) capable of inducing 
type#3.
> 
> Well, in *theory* I agree there should be minimal difference between a 
> regular LSP and an implicit (link) LSP.  I think the degree of 
> difference will come down to the specific mechanism we define.
> 
> At this stage, where we are still don't have consensus on 
> requirements, I think we need to differentiate the two.
> 
>>
>> We would like to retain "implicit-link" definition you had in your 
>> email earlier. To clarify, the "implicit-link" can have data plane 
>> representation with or without control plane representation (LSP).
> 
> If there is a one-to-one correspondence between the control plane and 
> the link, it is a standard H-LSP.
> 
>> In case of no control plane representation, the bandwidth of 
>> implicit-link is managed on the parent Te-Link.
> 
> And I was referring to the lower-level of the hierarchy in the 
> data-plane as an "implicit H-LSP"
> 
> Also, as has been highlighted by the other discussions, there's more 
> to consider than just bandwidth.
> 
>>
>>
>> The definition of "implicit-link" is same as you had before as follows:
>>
>> "
>> 1) "implicit-link"
>>    An implicit link is a logical entity that matches a (sup)layer
>>    (stage) in the data plane hierarchy, and which is established as
>>    result of control or management plane actions at a different layer
>>    (stage) in the data plane hierarchy. (Recall that a GMPLS/MPLS link
>>     may be a physical interface or provided by an H-LSP.) "
>>
>> To clarify, the multi-stage label proposed in draft-khuzema refers to 
>> "implicit-link" creation without implicit H-LSPs.
>>
> 
> I must not have been clear in my previous mail.  An "implicit-link" 
> (as
> defined) is just a logical entity, i.e., a concept. An "implicit H-LSP"
> (as defined) refers to the level of the hierarchy in the data-plane 
> that instantiates an implicit-link.  So, using these terms, 
> draft-khuzema refers to implicit-links that result in implicit H-LSPs.
> 
> Lou
> 
>> Thanks
>> Rajan, Ashok & Khuzema.
>>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On 
>> Behalf Of Lou Berger
>> Sent: Saturday, July 09, 2011 5:58 AM
>> To: John E Drake
>> Cc: CCAMP
>> Subject: Re: [CCAMP] John's Terminology (Was RE: RSVP OTN single 
>> stage vs multi stage)
>>
>>
>>
>> On 7/8/2011 5:21 PM, John E Drake wrote:
>> ...
>>>> How about we use the following terminology based on the existing 
>>>> H-LSP and link terminology and the (new) concept of *implicit* 
>>>> links and H- LSPs.
>>>>
>>>> 1) "implicit-link"
>>>>    An implicit link is a logical entity that matches a (sup)layer
>>>>    (stage) in the data plane hierarchy, and which is established as
>>>>    result of control or management plane actions at a different layer
>>>>    (stage) in the data plane hierarchy. (Recall that a GMPLS/MPLS 
link
>>>>    may be a physical interface or provided by an H-LSP.)
>>>>
>>>> 2) "implicit-link LSP"
>>>>    This is an LSP that uses an implicit-link.  Note that the
>>>>    implicit-link might not exist before the LSP is signaled.
>>>>
>>>> 3) "implicit H-LSP" (or implicitly established H-LSP)
>>>>    The H-LSP that is not directly signaled/managed and corresponds to
>>>>    an implicit-link.  Such an H-LSP is created as a result of the
>>>>    signaling/managment of an LSP that uses an implicit link.
>>>>
>>>> Comments?
>>>
>>> JD: 1) is what I was calling an intermediate switching stage LSP and
>> Given that 1 is a "logical entity", I suspect you mean (and I agree) 
>> that 3) is whay you were calling an intermediate switching stage LSP.
>>
>>> 2) is what I was calling an OUDj service LSP?
>>
>> agreed.
>>
>> So this leaves us with 4 types of LSPs.
>>
>> (old) LSPs
>>       LSPs that use explicit links
>> (old) H-LSPs
>>       LSPs that provide links to higher layers and are
>>       explicitly controlled
>>
>> (new) Implicit H-LSP
>>       LSPs that provide links to higher layers and are
>>       controlled via implicit mechanisms
>> (new) implicit-link LSP
>>       LSPs that use / trigger Implicit H-LSPs
>>
>> Comments?
>>
>> Lou
>>
>>>
>>>>
>>>> Lou
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp