Subject: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 4 Mar 2005 19:56:22 +0100

Igor,

Please see inline

Regards,

JL

>-----Message d'origine-----
>De : Igor Bryskin [mailto:[email-masked]] 
>Envoyé : vendredi 4 mars 2005 14:26
>À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
>Objet : Re: RE : TR : I-D 
>ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt 
>
>
>JL,
>
>Please, see my comments in-line
>
>Igor
>
>--- LE ROUX Jean-Louis RD-CORE-LAN 
><[email-masked]> wrote:
>
>> Hi Igor,
>> 
>> Thanks for these comments
>> 
>> Please see inline
>> 
>> 
>> >-----Message d'origine-----
>> >De : Igor Bryskin [mailto:[email-masked]]
>> >Envoyé : jeudi 3 mars 2005 20:45
>> >À : LE ROUX Jean-Louis RD-CORE-LAN;
>> [email-masked]
>> >Objet : Re: TR : I-D
>> ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
>> >
>> >
>> >JL,
>> >
>> >I have a couple of comments/suggestions.
>> >
>> >1.	The draft says that currently GMPLS does not
>> have a
>> >mechanism to provision virtual FAs. I don't think
>> this
>> >is correct - I believe we could use the same
>> mechanism
>> >as was suggested in
>> >draft-ietf-ccamp-gmpls-recovery-e2e-signaling
>> (section
>> >9.3) for signaling of Secondary LSPs
>> 
>> I wouldn't be so expeditious...
>> Actually we could use a similar mechanism but
>> definitely not the same.
>> Secondary LSP are dedicated to Shared Meshed
>> Restoration.
>> IMHO this would be bad to use the Protection object
>> for soft-FAs. Semantics
>> are pretty different...
>> 
>
>IB>>Well, are they? They give you a way to signal a
>requirement not to commit resources for an LSP until
>further notice and also to require their commitment
>when it becomes necessary. Why not to allow working
>LSP to be signaled as Secondary according to the
>mentioned draft? Then it would be possible even to
>signal protected virtual FAs, which is not as stupid
>as it may sound :=)

Sorry but this sounds really bad...
Please let me know then how do you signal protected virtual FAs?

>
>> 
>> >2.	I agree that we need TE link adaptation
>> >capabilities to be advertised along with other TE
>> link
>> >attributes such as switching capabilities,
>> protection
>> >capabilities, etc. I suggest also adding TE link
>> termination
>> >capabilities to this list, i.e. decoupling of these
>> 
>> >capabilities from adaptation capabilities:
>> >to terminate LSP in a particular layer and to adopt
>> >into it LSPs of one or more higher layers are
>> separate
>> >resources and could be considered separately in the
>> 
>> >inter-layer path computations;
>> 
>> I agree that our curent terminology may be confusing
>> What we call Internal Adapatation Capability
>> actually refers to Termination capabilities.
>> See the MRN requirement draft (version 01) for an
>Ø	example.
>
>IB>> My point is that termination and adaptation
>capabilities are separate things. For instance, the
>fact that a link can terminate lambdas means the it
>has certain number of available transceivers, while
>the fact whether these lambdas can carry particular
>tributary signals depends, say, on whether SIM cards
>of appropriate type could be cross-connected to the 
>transceivers. In fact, link termination bandwidth is shared 
>between multiple adaptation functions. The bottom line is I 
>think it would be good idea to advertise them separately.
>

IMHO all what is missing in GMPLS-RTG is the advertisement of the internal termination capabilities (a.k.a internal adaptation capability in our draft...). 
This is useful only when doing inter-region path computation. 
IMHO we just need to find an appropriate terminology.

>> 
>> 
>> >3.	Everything that is said about regions, region
>> >boundaries, etc. is also applicable for layers
>> >contained within regions. I suggest to do what we
>> have
>> >already done in the PCE WG documents and
>> >presentations: replace word region with word layer everywhere apart 
>> >from where signaling specific
>> aspects
>> >are discussed.
>> 
>> See section 3 of the requirement draft.
>> Actually what we define for region also applies to
>> layers, but we prefer to
>Ø	keep the term region here at the time being.
>
>IB>> And my question is why to do so, if FAs and
>everything to do with VNT is about layers, including
>those that start and stop in the middle of the region,
>that is, far away from region boundaries? Furthermore,
>when you say things like creating FA in the lower
>region to carry LSP for the higher region, it is not
>clear what do you mean by that in the case when the
>lower region contains multiple layers.

You are right this applies also to multi-layers.
We will clarify in next revision, but note that this is already clarified in the 
MRN req draft (see section 3).

Thanks again,

JL

>
>Igor
>
>> 
>> Again, thanks a lot for these comments,
>> 
>> Regards,
>> 
>> JL
>> 
>> >
>> >Thanks,
>> >Igor
>> >   
>> >
>> >
>> >--- LE ROUX Jean-Louis RD-CORE-LAN
>> ><[email-masked]> wrote:
>> >
>> >
>> >
>> >> 
>> >> Hi all,
>> >> 
>> >> Here is a new draft evaluating current GMPLS
>> >> protocols wrt MRN
>> >> requirements.
>> >> Your comments on this new draft would be highly appreciated.
>> >> 
>> >> Best Regards,
>> >> 
>> >> JL
>> >> 
>> >> To: i-d-announce at ietf.org
>> >> Subject: I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
>> >> From: Internet-Drafts at ietf.org 
>> >> Date: Tue, 15 Feb 2005 10:14:38 -0500 
>> >> 
>> >> A New Internet-Draft is available from the
>> on-line Internet-Drafts
>> >> directories.
>> >> 
>> >> 
>> >> 	Title		: Evaluation of existing GMPLS Protocols
>> >> against
>> >> Multi Region Networks
>> >> 	Author(s)	: J. Le Roux, et al.
>> >> 	Filename	:
>> draft-leroux-ccamp-gmpls-mrn-eval-00.txt
>> >> 	Pages		: 11
>> >> 	Date		: 2005-2-14
>> >> 	
>> >> This document provides an evaluation of
>> Generalized Multi-Protocol
>> >>    Label Switching (GMPLS) protocols and
>> mechanisms
>> >> against the 
>> >>    requirements for Multi Region Networks (MRN).
>>  
>> >>    In addition, this document identifies areas
>> where
>> >> additional 
>> >>    protocol extensions or procedures are needed
>> to
>> >> satisfy the 
>> >>    requirements of Multi Region Networks, and
>> >> provides guidelines for 
>> >>    potential extensions.
>> >> 
>> >> A URL for this Internet-Draft is:
>> >>
>>
>>http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr
>> n-eval-00
>> > .txt
>> > 
>> > 
>> > 
>> > 
>> >
>> 
>> 
>> 
>> 	
>> 		
>> __________________________________
>> Celebrate Yahoo!'s 10th Birthday! 
>> Yahoo! Netrospective: 100 Moments of the Web 
>> http://birthday.yahoo.com/netrospective/
>>
>
>
>
>	
>		
>__________________________________ 
>Celebrate Yahoo!'s 10th Birthday! 
>Yahoo! Netrospective: 100 Moments of the Web 
>http://birthday.yahoo.com/netrospective/
>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 4 Mar 2005 13:25:44 -0800 (PST)

IB>> You signal both working and protection LSPs of the FA as Secondary. At the time when you decide to make FA “real” you re-signal working or both LSPs (depending on protection type) as Primary. Don’t see why this wouldn’t work.

Igor

---------------------------------
Celebrate Yahoo!'s 10th Birthday! 
 Yahoo! Netrospective: 100 Moments of the Web