[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt
Igor,
Please see inline
Regards,
JL
>-----Message d'origine-----
>De : Igor Bryskin [mailto:i_bryskin@yahoo.com]
>Envoyé : vendredi 4 mars 2005 14:26
>À : LE ROUX Jean-Louis RD-CORE-LAN; ccamp@ops.ietf.org
>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
><jeanlouis.leroux@francetelecom.com> wrote:
>
>> Hi Igor,
>>
>> Thanks for these comments
>>
>> Please see inline
>>
>>
>> >-----Message d'origine-----
>> >De : Igor Bryskin [mailto:i_bryskin@yahoo.com]
>> >Envoyé : jeudi 3 mars 2005 20:45
>> >À : LE ROUX Jean-Louis RD-CORE-LAN;
>> ccamp@ops.ietf.org
>> >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
>> ><jeanlouis.leroux@francetelecom.com> 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/
>