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

From: [email-masked]
Date: Fri, 4 Mar 2005 14:59:24 +0100

igor - a short hint concerning the first point

Igor Bryskin <[email-masked]>
Sent by: [email-masked]
03/04/2005 05:26 PST

To: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>, [email-masked]
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
<[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 :=)

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
> ><[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: [email-masked]
Date: Sat, 5 Mar 2005 00:25:55 +0100

"Igor Bryskin" <[email-masked]>
Sent by: [email-masked]
03/04/2005 18:05 EST

To: "Igor Bryskin" <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>, <[email-masked]>
bcc:
Subject: Re: RE : RE : TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-00.txt

> Sorry but this sounds really bad...
> Please let me know then how do you signal protected virtual FAs?
>
> 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.
>
> DP> because what do you do in case the primary (virtual) FA-LSP fails ?
you
> are simply going to activate the secondary (virtual) FA-LSP which is in
> clear
> opposition with the notion of virtual-FA - the reason is again because you
> are trying to use one bit i.e. S to say something in a context (protection
> object) for which it has not been designed for
>

IB>> Oh-Oh, what do you mean by "primary (virtual) FA-LSP fails" and  "you
are simply going to activate the secondary (virtual) FA-LSP "?  I activate
protection LSP if I have a failure in the *data plane* of the working LSP.
But working LSP of the virtual FA does not have any data plane yet, there is
nothing that can trigger the protection LSP activation and switchover.

DP> but they are associated to resources they do not use - and the control plane role is to ensure that when they need to be activated resources can be used - the question JL raises is the problem of "how do i protect a virtual FA" and the response is if you are using the S bit for telling i am a virtual FA you can not use it anymore to ensure protection of a primary (and even less a secondary !) - this said an secondary LSP exists only within the context of its primary