igor - a short hint concerning the first point
Igor Bryskin <i_bryskin@yahoo.com>
Sent by: owner-ccamp@ops.ietf.org
03/04/2005 05:26 PST
To: LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@francetelecom.com>, ccamp@ops.ietf.org
cc:
bcc:
Subject: 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 :=)
DP> because it would require considering working secondaries - this combination is precluded as it does not make any sense (see the document, a bit a single semantic) while the combination protecting secondary is already determined as said by JL (this is strictly related to a protection object) - any other semantic overload would be considered here as a bad protocol design practice - therefore it is much appropriate to consider a specific for distinguishing both virtual from non-virtual FAs and make use of the protection object as defined in the end-to-end recovery document as required i.e. protected or not virtual FAs, protected or not FA-LSPs, etc.
> >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.
>
>
> >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.
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/