Subject: [CCAMP] MELGs - Q&A

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 13 Mar 2013 23:27:23 -0400

*Folks, Hi!

There were some questions about the use of MELGs this morning after my
presentation (Much Thanks to the folks who voiced them out). **The
questions were mostly on the need for defining this new construct. **The
following text is an attempt to answer these questions. Please do read this
through and let me know if there are any further queries.*
*
*
*Regards,*
*-Pavan

1. Why do mutually exclusive abstract/virtual TE links exist?

When a server network domain gets abstracted and advertised into the client
network domain, the virtual TE links that get created can end up being
mutually exclusive. The assumption is that this abstraction is done based
on the output of some extensive planning activity. Since uncommitted
resources are involved, it is perfectly alright to plan the abstraction in
such a way that only a subset of the virtual TE links get used at any given
point of time. If multiple virtual TE links depend on the usage of the same
uncommitted network resource, only one of them can get instantiated at any
given point of time - And this makes them mutually exclusive.

2. Why is there a need to advertise this "mutual exclusivity" information?

The abstract/virtual TE links are advertised into a client network domain
and exist in the client TEDB. For a Client Network Domain path computation
function that does concurrent computations (of multiple paths), it is
important to know the existence of the mutually exclusive relationship
between Virtual TE Links. Absent this information, there exists the risk of
yielding erroneous concurrent path computation results where only a subset
of the computed paths can get successfully provisioned. The MELG-ID
construct is being introduced to advertise this "missing" piece of
information.

4. How is MELG different from SRLG?

**Each construct addresses a separate problem. **SRLGs are used to
advertise “fate-sharing” information. MELGs are used to advertise “mutual
exclusivity” information. *

It is possible for TE-links that have a common SRLG to be instantiated/used
at the same time. It is not possible for TE-links that have a common MELG
to be instantiated/used at the same time - only one of them can be used at
any given point of time

*
**5. Are there any scaling implications for MELGs?

The number of MELG-IDs advertised per TE-link depends on how the
abstraction process is carried out. If at all this is (or would become) a
concern, adequate policies can be imposed on the abstraction process to
limit the creation of too many mutually exclusive Virtual links.*

---

From: Dieter Beller <[email-masked]>
Date: Sat, 16 Mar 2013 13:52:54 +0100

Hi Pavan,

thanks for providing more explanations re the MELG draft.

Please find my comments in-line below.

Thanks,

Dieter

On 14.03.2013 04:27, Vishnu Pavan
Beeram wrote:

Folks,
Hi!

There
were some questions about the use of MELGs this morning
after my presentation (Much Thanks to the folks who voiced
them out). The
questions were mostly on the need for defining this new
construct. The
following text is an attempt to answer these questions.
Please do read this through and let me know if there are any
further queries.

Regards,

-Pavan

1.
Why do mutually exclusive abstract/virtual TE links
exist?

When
a server network domain gets abstracted and advertised
into the client network domain, the virtual TE links
that get created can end up being mutually exclusive.
The assumption is that this abstraction is done based on
the output of some extensive planning activity.

It is pretty clear that this virtual topology needs to be created by
the operator based on

conscious decisions where to place them, i.e., between which
potential link end points.

Since uncommitted resources are involved, it is
perfectly alright to plan the abstraction in such a way
that only a subset of the virtual TE links get used at
any given point of time. If multiple virtual TE links
depend on the usage of the same uncommitted network
resource, only one of them can get instantiated at any
given point of time - And this makes them mutually
exclusive.

clear

2.
Why is there a need to advertise this "mutual
exclusivity" information?

The
abstract/virtual TE links are advertised into a client
network domain and exist in the client TEDB.

I would rather use the term client layer network instead of
client network domain as we are

in a multi-layer environment and the client layer network is
probably in most cases belonging

to the same operator domain.

For a Client Network Domain path computation
function that does concurrent computations (of
multiple paths), it is important to know the
existence of the mutually exclusive relationship between
Virtual TE Links. Absent this information, there exists
the risk of yielding erroneous concurrent path
computation results where only a subset of the computed
paths can get successfully provisioned. The MELG-ID
construct is being introduced to advertise this
"missing" piece of information.

I think you mentioned the use case for which the mutual
exclusiveness of virtual links could be

important, i.e., you have a single path computation instance that is
capable to concurrently

calculate n paths in one shot. As soon as you calculate the paths
sequentially, the problem goes

away because as soon as the virtual link is used by one path, it is
no longer available for other

paths.

Moreover, if you are doing path computation in a distributed fashion
and you run into the situation

that two path computation functions are selecting the same virtual
TE-link when they calculate

backup paths for failed connections that need to be restored, this
conflict can only be resolved

when the backup paths are being setup (first come first serve,
crank-back for the 2nd followed

by the calculation of a new backup path excluding the already
occupied virtual TE-link). Hence,

MELGs are not needed in this scenario. The problem does also no
longer exist as soon as the

the TEDBs are updated in response to the allocation of the virtual
link by an LSP.

4.
How is MELG different from SRLG?

Each
construct addresses a separate problem. SRLGs
are used to advertise “fate-sharing” information. MELGs
are used to advertise “mutual exclusivity” information.

It
is possible for TE-links that have a common SRLG to be
instantiated/used at the same time. It is not possible
for TE-links that have a common MELG to be
instantiated/used at the same time - only one of them
can be used at any given point of time

5.
Are there any scaling implications for MELGs?

The
number of MELG-IDs advertised per TE-link depends on how
the abstraction process is carried out. If at all this
is (or would become) a concern, adequate policies can be
imposed on the abstraction process to limit the creation
of too many mutually exclusive Virtual links.

The question regarding scalability is certainly: how much additional
information is needed in case

the MELG concept would be applied to virtial TE links.

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

--

DIETER
BELLER

ALCATEL-LUCENT
DEUTSCHLAND AG

PROJECT MANAGER ASON/GMPLS CONTROL PLANE

CORE NETWORKS BUSINESS DIVISION

OPTICS BU, SWITCHING R&D

Lorenzstrasse 10

70435 Stuttgart, Germany

Phone: +49 711 821 43125

Mobil: +49 175 7266874

[email-masked]

Alcatel-Lucent
Deutschland AG

Domicile of the Company: Stuttgart · Local Court Stuttgart HRB
4026

Chairman of the Supervisory Board: Michael Oppenhoff

Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg
Daub · Dr. Rainer Fechner · Andreas Gehe

This e-mail and its attachments, if any, may contain
confidential information.

If you have received this e-mail in error, please notify us and
delete or destroy the e-mail and its attachments, if any,
immediately.

If you have received this e-mail in error, you must not forward
or make use of the e-mail and its attachments, if any.

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sat, 16 Mar 2013 20:08:39 -0400

Dieter, Hi!

Thanks for your response. Glad to see that you understand the fundamental
concept now.
Responses inline (prefixed with [VPB])

Snipped..

* For a Client Network Domain path computation*
>
> * function that does concurrent computations (of multiple paths), it is
> I think you mentioned the use case for which the mutual exclusiveness of
> virtual links could be
> away because as soon as the virtual link is used by one path, it is no
> longer available for other
> paths.
>
> Moreover, if you are doing path computation in a distributed fashion and
> you run into the situation
> that two path computation functions are selecting the same virtual TE-link
> when they calculate
> when the backup paths are being setup (first come first serve, crank-back
> for the 2nd followed
> by the calculation of a new backup path excluding the already occupied
> virtual TE-link). Hence,
> MELGs are not needed in this scenario. The problem does also no longer
> exist as soon as the
> the TEDBs are updated in response to the allocation of the virtual link by
> an LSP.
>
>
[VPB] Your points about the "path computation aspects" are fairly obvious
points - there is no dispute there. The context of interest (in case you
are still missing it) here is a centralized path computation function that
is capable of doing concurrent computations. And this computation function
operates on a Client TED that includes some mutually exclusive abstract
links (note that there could be multiple levels of abstraction). All that
this draft is trying to do is provide a means for this centralized
computation function to concurrently compute multiple paths that have a
high probability of being successfully provisioned.

Snipped..

>
> * Are there any scaling implications for MELGs?
>
> The question regarding scalability is certainly: how much *additional *information
> is needed in case
[VPB]  I don't really think there is any valid scaling argument to be made
against "MELGs". All that you would need to advertise the "mutual
exclusivity" information is included in the "construct" that is defined in
the draft. There is NO additional information that you would need to
advertise to make use of MELGs. Please do read through the draft (if you
haven't already) when you get a chance.

And please do let me know if you have any further concerns about MELGs.

Regards,
-Pavan

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 21 Mar 2013 03:37:30 +0000

Hi Pavan,

Each construct addresses a separate problem. SRLGs are used to advertise "fate-sharing" information. MELGs are used to advertise "mutual exclusivity" information.

It is possible for TE-links that have a common SRLG to be instantiated/used at the same time. It is not possible for TE-links that have a common MELG to be instantiated/used at the same time - only one of them can be used at any given point of time

[Fatai] I don't understand your definition of MELG(ie., MELGs are used to advertise "mutual exclusivity" information).  If we name it as XXLG, we can define XXLG similarly in your style: XXLGs are used to advertise "XX" informaiton.  My real question is: Why is there "mutual exclusivity"?   What is the essence of "mutual exclusivity"?

In additon, what you said in the second sentence about "possible" vs "not possible" is a kind of policy, there is nothing different between SRLG and MELG here.

Best Regards

Fatai

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 21 Mar 2013 10:43:04 -0400

Fatai, Hi!

Thanks for keeping the conversation going.
Response inline.

Snipped>>

> Each construct addresses a separate problem. SRLGs are used to advertise
> “fate-sharing” information. MELGs are used to advertise “mutual
> exclusivity” information. ****
>
> ** **
>
> It is possible for TE-links that have a common SRLG to be
> instantiated/used at the same time. It is not possible for TE-links that
> have a common MELG to be instantiated/used at the same time - only one of
> them can be used at any given point of time****
>
> ** **
>
> [Fatai] I don’t understand your definition of MELG(ie., MELGs are used to
> advertise “mutual exclusivity” information).  If we name it as XXLG, we can
> define XXLG similarly in your style: XXLGs are used to advertise “XX”
> informaiton.  My real question is: Why is there “mutual exclusivity”?
>   What is the essence of “mutual exclusivity”?
>

You seem to have missed reading the first couple of questions (in the FAQs)
that I sent out. The answers to those 2 questions should answer why "mutual
exclusivity" exists among the advertised topological constructs and why
 there is a need to advertise this additional information. I'm pasting
those 2 answers here for your benefit.

----
 *1. Why do mutually exclusive abstract/virtual TE links exist?*
*When a server network domain gets abstracted and advertised into the
client network domain, the virtual TE links that get created can end up
being mutually exclusive. The assumption is that this abstraction is done
based on the output of some extensive planning activity. Since uncommitted
resources are involved, it is perfectly alright to plan the abstraction in
such a way that only a subset of the virtual TE links get used at any given
point of time. If multiple virtual TE links depend on the usage of the same
uncommitted network resource, only one of them can get instantiated at any
given point of time - And this makes them mutually exclusive.

2. Why is there a need to advertise this "mutual exclusivity" information?
The abstract/virtual TE links are advertised into a client network domain
and exist in the client TEDB. For a Client Network Domain (centralized)
path computation function that does concurrent computations (of multiple
paths), it is important to know the existence of the mutually exclusive
relationship between Virtual TE Links. Absent this information, there
exists the risk of yielding erroneous concurrent path computation results
where only a subset of the computed paths can get successfully provisioned.
The MELG-ID construct is being introduced to advertise this "missing" piece
of information.*
----

Please do let us know if the above answers your questions. The 2 things
that you might want to think about  (to understand the need for MELGs) are
- "Network Domain Abstraction" and "Centralized Concurrent Path
Computation".

You are free to define "XXLG" (or any thing of that sort) as long as there
is a valid use-case. Our claim here is that "MELG" serves a valid use-case
(as explained in the draft and in the FAQs that I sent out). Please let us
know what part of this use-case doesn't sound "valid" enough for you.

Regards,
-Pavan

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 21 Mar 2013 14:42:52 +0000

Fatai,

Let me try to answer that. With Virtual Links it is possible to advertise two or more VLs with only one of them from the group to be operational at any given time. Recall that VLs could be advertised without having underlying server layer connection (e.g. H-LSP) in place. Therefore, the group of VLs may depend in a mutually exclusive way on a single network resource (e.g. WDM transponder). In order to make TE domain aware of such mutual exclusive dependency, it is suggested to use the concept of MELG. The path computer will understand that two or more VLs are mutually exclusive if they have an MELG in common.

Note, that MELGs are important only when you compute concurrently two or more paths, so that path computer wouldn't select paths with two or more VLs that mutually exclude each other. When you compute one path at a time, MELGs are not important and could be ignored.

Note also that MELGs make only sense for VLs, why otherwise you will advertise two links if only one of them at a time could be used, right? Normally you would advertise only one of them. However, with VLs it does make sense to advertise both as network topology potentiality. Hope this makes sense.

Cheers,
Igor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Wednesday, March 20, 2013 11:38 PM
To: Vishnu Pavan Beeram; [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

Hi Pavan,

Best Regards

Fatai

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 22 Mar 2013 01:14:47 +0000

Hi Pavan and Igor,

Thanks for your clarification.

I have seen the Question 1& 2 provided by Pavan.

When I asked "Why is there "mutual exclusivity"?  What is the essence of "mutual exclusivity"?,  I just want to know if "mutual exclusivity" exists because of "fate-sharing" in the server layer?

If the answer is "yes", then SRLG  100%  fits the valide use-case (ie., no need to introduce a new concept).

Please correct me if I missed something on the essence of MELG.

Best Regards

Fatai

From: Igor Bryskin [mailto:[email-masked]]
Sent: Thursday, March 21, 2013 10:43 PM
To: Fatai Zhang; Vishnu Pavan Beeram; [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Fatai,

Cheers,
Igor

Hi Pavan,

Best Regards

Fatai

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 22 Mar 2013 08:24:25 +0000

Hi Pavan and Igor,

I understand more after I read your draft and your explanation again.

I now understand that MELGs are used to solve the competition of "the same resource" in the server layer shared by two or more VLs, so I agree what Igor said that MELGs are important only when you compute concurrently two or more paths.

Do you think is this a corner case?

Best Regards

Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Friday, March 22, 2013 9:15 AM
To: Igor Bryskin; Vishnu Pavan Beeram; [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

Hi Pavan and Igor,

Best Regards

Fatai

Fatai,

Cheers,
Igor

Hi Pavan,

Best Regards

Fatai

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 22 Mar 2013 08:56:30 -0400

Fatai, Hi!

Good to see that you understand the construct now.

This is not a corner case. The utility of the construct becomes quite
significant if you have an application that does concurrent path
computations on an abstract topology.

Regards,
-Pavan

On Fri, Mar 22, 2013 at 4:24 AM, Fatai Zhang <[email-masked]> wrote:

>  Hi Pavan and Igor,****
>
> ** **
>
> I understand more after I read your draft and your explanation again.****
>
> ** **
>
> I now understand that MELGs are used to solve the competition of “the same
> resource” in the server layer shared by two or more VLs, so I agree what
> Igor said that MELGs are important only when you compute concurrently two
> or more paths.****
>
> ** **
>
> Do you think is this a corner case?****
>
> ** **
>
> ** **
>
> Best Regards****
>
> ** **
>
> Fatai****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Fatai Zhang
> *Sent:* Friday, March 22, 2013 9:15 AM
> *To:* Igor Bryskin; Vishnu Pavan Beeram; [email-masked]
>
> *Subject:* Re: [CCAMP] MELGs - Q&A****
>
>  ** **
>
> Hi Pavan and Igor,****
>
> ** **
>
> Thanks for your clarification.****
>
> ** **
>
> I have seen the Question 1& 2 provided by Pavan. ****
>
> ** **
>
> When I asked “Why is there “mutual exclusivity”?  What is the essence of
> “mutual exclusivity”?,  I just want to know if “mutual exclusivity” exists
> because of “fate-sharing” in the server layer?****
>
> ** **
>
> If the answer is “yes”, then SRLG  100%  fits the valide use-case (ie., no
> need to introduce a new concept). ****
>
> ** **
>
> Please correct me if I missed something on the essence of MELG.****
>
> ** **
>
> Best Regards****
>
> ** **
>
> Fatai****
>
> ** **
>
> *From:* Igor Bryskin [mailto:[email-masked]]
> *Sent:* Thursday, March 21, 2013 10:43 PM
> *To:* Fatai Zhang; Vishnu Pavan Beeram; [email-masked]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Fatai,****
>
>   What is the essence of “mutual exclusivity”?****
>
> ** **
>
> Let me try to answer that. With Virtual Links it is possible to advertise
> two or more VLs with only one of them from the group to be operational at
> any given time. Recall that VLs could be advertised without having
> underlying server layer connection (e.g. H-LSP) in place. Therefore, the
> group of VLs may depend in a mutually exclusive way on a single network
> resource (e.g. WDM transponder). In order to make TE domain aware of such
> mutual exclusive dependency, it is suggested to use the concept of MELG.
> The path computer will understand that two or more VLs are mutually
> exclusive if they have an MELG in common. ****
>
> ** **
>
> Note, that MELGs are important only when you compute concurrently two or
> more paths, so that path computer wouldn’t select paths with two or more
> VLs that mutually exclude each other. When you compute one path at a time,
> MELGs are not important and could be ignored.****
>
> ** **
>
> Note also that MELGs make only sense for VLs, why otherwise you will
> advertise two links if only one of them at a time could be used, right?
> Normally you would advertise only one of them. However, with VLs it does
> make sense to advertise both as network topology potentiality. Hope this
> makes sense.****
>
> ** **
>
> Cheers,****
>
> Igor ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Fatai Zhang
> *Sent:* Wednesday, March 20, 2013 11:38 PM
> *To:* Vishnu Pavan Beeram; [email-masked]
> *Subject:* Re: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Hi Pavan,****
>
> ** **
>
> ** **
>
>   What is the essence of “mutual exclusivity”?****
>
> ** **
>
> In additon, what you said in the second sentence about “possible” vs “not
> possible” is a kind of policy, there is nothing different between SRLG and
> MELG here. ****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> Best Regards****
>
> ** **
>
> Fatai****
>
> ** **
>
> ** **
>

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 25 Mar 2013 06:29:14 +0000

Hi Pavan,

I am not sure how much VL (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.

Do you think if it makes sense to add a flag (in routing advertisement) to indicate a link is a VL or not?

Best Regards

Fatai

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

Fatai, Hi!

This is not a corner case. The utility of the construct becomes quite significant if you have an application that does concurrent path computations on an abstract topology.

Regards,
-Pavan

---

From: Dieter Beller <[email-masked]>
Date: Mon, 25 Mar 2013 22:52:04 +0100

Hi Pavan,

On 25.03.2013 07:29, Fatai Zhang wrote:

Hi Pavan,

I am not sure how much VL (Virtual Link) will
be used in the practical deployment and how often concurrent
path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be
used."

This means we are trying to figure out under which conditions MELG
routing extensions

could be beneficial.

IMHO, they would only make sense, if:

a path computation function supports the calculation of k
shortest paths concurrently

if there is only a single path computation function instance
per domain (pce approach)

If path computation is done in a distributed fashion the benefit
goes away because

the instances calculate paths independently!

I suppose that if a pce approach is used, i.e., path computation is
centralized including the

TE-DB, MELG routing extensions are not needed because the
information about mutual

exclusive VLs can be kept in the central TE-DB when VLs are
configured.

Hence, it is quite doubtful whether MELG routing extensions are
really useful unless their

applicability is broader.

Thanks,

Dieter

Do you think if it makes sense to add a flag
(in routing advertisement) to indicate a link is a VL or
not?

Best Regards

Fatai

From: Vishnu Pavan Beeram
[mailto:[email-masked]]

To: Fatai Zhang

Fatai, Hi!

Good to see that you
understand the construct now.

This is not a corner
case. The utility of the construct becomes quite
significant if you have an application that does
concurrent path computations on an abstract topology.

Regards,

-Pavan

--

DIETER
BELLER

ALCATEL-LUCENT
DEUTSCHLAND AG

OPTICS BU, SWITCHING R&D

Lorenzstrasse 10

70435 Stuttgart, Germany

Phone: +49 711 821 43125

Mobil: +49 175 7266874

Alcatel-Lucent
Deutschland AG

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 26 Mar 2013 13:49:05 +0000

Dieter,

You said:
>> I guess we are coming back to the essential point: "and how often concurrent path computation will be >> used."

To be honest, this surprises me quite a bit, Let me give you some of many reasons as to why concurrent path computations are needed and why this is better than computing one path at a time:

1.     Computing several diverse paths for the same service in the context of service recovery. I hope you realize that computing one path at a time on many configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  having a link with common MELG with a link from another path;

2.     Computing paths for multiple services to be sufficiently disjoint from each other;

3.     Computing paths for multiple services to achieve a global optimization criteria (e.g. minimal summary total cost);

4.     Computing paths for multiple services for the purpose of removing the bandwidth fragmentations;

5.     Computing paths for multiple services to plan shared mesh protection/restoration schemes

6.     Etc.

Also think about this:

1.     If concurrent path computation was not important, why PCEP includes the machinery to do that?

2.     My understanding of the statefull PCE is that it does pretty much nothing but concurrent path computations

You also said:
>> I suppose that if a pce approach is used, i.e., path computation is centralized including the
>> TE-DB, MELG routing extensions are not needed because the information about mutual
>>exclusive VLs can be kept in the central TE-DB when VLs are configured.

How this logic does not apply to other link attributes such as SRLGs?
What if path computation is not centralized?

Cheers,
Igor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

Hi Pavan,

I am not sure how much VL (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.
I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing extensions
could be beneficial.

  *   a path computation function supports the calculation of k shortest paths concurrently
  *   if there is only a single path computation function instance per domain (pce approach)
If path computation is done in a distributed fashion the benefit goes away because
the instances calculate paths independently!
I suppose that if a pce approach is used, i.e., path computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really useful unless their
applicability is broader.

Thanks,
Dieter

Best Regards

Fatai

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] MELGs - Q&A

Fatai, Hi!

Regards,
-Pavan

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

--
DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874
[email-masked]<mailto:[email-masked]>

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub · Dr. Rainer Fechner · Andreas Gehe

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 26 Mar 2013 10:44:53 -0400

Fatai, Hi!

> ** **
>
> Do you think if it makes sense to add a flag (in routing advertisement) to
> indicate a link is a VL or not?****
>
> **
>

When Virtual TE (VTE) Links are used, it would be useful for a client path
computation element to know if a given VTE link is already committed or
not. This information allows the computing element to show preference to
the committed virtual TE links - and thus avoid unnecessarily instantiating
an uncommitted virtual TE link when you have an equally good available
committed TE link. The "U-Bit" in the MELG construct  is useful in this
regard.

So, to answer your question - If the MELG construct is used as defined in
the draft, I don't see a need to add any other separate flag to indicate if
a link is a Virtual TE Link or not.

-Pavan

> ** **
>
> *From:* Vishnu Pavan Beeram [mailto:[email-masked]]
> *Sent:* Friday, March 22, 2013 8:57 PM
> *To:* Fatai Zhang
> *Cc:* Igor Bryskin; [email-masked]
>
> Fatai, Hi!****
> Good to see that you understand the construct now.****
>
> ** **
>
> computations on an abstract topology.****
>
> ** **
>
> Regards,****
>
> -Pavan****
>

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 29 Mar 2013 01:22:57 +0000

Hi Pavan,

I think the usage or function of "U-Bit" (Uncommitted) is almost equivalent to my intention, but there is a little difference.
I more like to have a flag outside of MELG sub-TLV to indicate if a link is a Virtual link or *regular* link (and then path computation can be aware of this).

For the "U-Bit" defined in your draft, I think there is some logic issue. I think a virtual link is always *virtual* (ie., uncommitted). If a virtual link is committed, then this "virtual" link becomes a *regular* link (and the other virtual links sharing the same resource of the sever layer will become unavailable (or will be withdrawn) , and then MELG becomes useless (as what Igor said that "MELGs make only sense for VLs").

Best Regards

Fatai

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: Tuesday, March 26, 2013 10:45 PM
To: Fatai Zhang
Cc: Igor Bryskin; [email-masked]
Subject: Re: [CCAMP] MELGs - Q&A

Fatai, Hi!

When Virtual TE (VTE) Links are used, it would be useful for a client path computation element to know if a given VTE link is already committed or not. This information allows the computing element to show preference to the committed virtual TE links - and thus avoid unnecessarily instantiating an uncommitted virtual TE link when you have an equally good available committed TE link. The "U-Bit" in the MELG construct  is useful in this regard.

So, to answer your question - If the MELG construct is used as defined in the draft, I don't see a need to add any other separate flag to indicate if a link is a Virtual TE Link or not.

-Pavan

From: Vishnu Pavan Beeram [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; [email-masked]<mailto:[email-masked]>

Fatai, Hi!

Regards,
-Pavan

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 29 Mar 2013 13:25:13 +0000

Hi Fatai,

Please, see in line.
Igor
From: Fatai Zhang [mailto:[email-masked]]
Sent: Thursday, March 28, 2013 9:23 PM
To: Vishnu Pavan Beeram
Cc: Igor Bryskin; [email-masked]
Subject: RE: [CCAMP] MELGs - Q&A

Hi Pavan,

IB>> The flag you are talking about needs to be stuck into some sub-TLV, right? Because the MELGs and the flag are only meaningful for VLs, why not to use just one sub-TLV? For example, it is possible to specify 0 MLGs in the sub-TLV and set/clear the U bit to advertise

a)      Whether the link is VL or not (the fact that the sub-TLV present or not);

b)      Whether the VL is committed or not (depends on U bit)

IB>> Here I disagree. The way we see it, VL is decoupled completely from the data plane, and thus, remains VL even after the necessary data plane is in place, i.e. becomes committed. This differs our view from, say, MLN/MRN, where VL is converted to RL whenever the H-LSP is in place. We say that when VL is committed the necessary DP in the provider network is provisioned, which could be realized via single H-LSP or chain of H-LSPs (provisioned by provider CP or SDN controller), which is not seen by the client, nor it is important. In other words, VL is a piece of fiction, always virtual, rather than something that could be one moment virtual and the next converted into something real. Clients never see RLs. This allows, among other things, to have a separate (proprietary) set of attributes for RLs while standardized (and hence understood by clients) for VLs
Cheers,
Igor

Best Regards

Fatai

Fatai, Hi!

-Pavan

Fatai, Hi!

Regards,
-Pavan

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 29 Mar 2013 11:03:51 -0400

Fatai, Hi!

To add to what Igor said,  the Virtual TE Link (the way we see it) remains
"virtual" throughout its life-span. It may get committed from time to time,
when an underlying server LSP gets setup. But it can also get back to its
uncommitted state when the underlying server LSP gets deleted. So in that
context, just knowing whether the advertised TE-link is virtual or not
doesn't help the computing element.  The computing element would need to
know whether the link is committed or not and whether the link is mutually
exclusive with some other link(s) or not. Since we were defining a
construct (MELG) that is exclusive for Virtual TE Links, it seemed to be a
good idea to add the "Uncommitted/Committed" bit in the same container. I
can see how one would want to decouple this from the MELG construct, but
defining a new construct for just that one bit seems unnecessary (arguably).

There was one slide (Slide 7) in the presentation (
http://tools.ietf.org/agenda/86/slides/slides-86-ccamp-13.pdf) that was
made in Orlando, discussing Virtual TE link advertisements in the context
of MELGs (please see if the content in that slide makes sense to you).
We'll expand on the content in this slide and add sufficient text to the
next version of the draft. That should give you a better understanding of
how the Virtual TE Link advertisements would need to be handled by
implementations that understand/support MELGs. Please note that these
advertisement rules are meaningful (and come into play) only for
implementations/solutions that would need to worry about "MELGS". There is
no impact on implementations/solutions that don't wish to make any
distinction between a Virtual TE-link and a regular TE-link (the MELG
construct would simply be ignored in such cases).

BR,
-Pavan

On Fri, Mar 29, 2013 at 9:25 AM, Igor Bryskin <[email-masked]>wrote:

>  Hi Fatai,****
>
> ** **
>
> Please, see in line.****
>
> Igor****
>
> *From:* Fatai Zhang [mailto:[email-masked]]
> *Sent:* Thursday, March 28, 2013 9:23 PM
> *To:* Vishnu Pavan Beeram
> I think the usage or function of “U-Bit” (Uncommitted) is almost
> equivalent to my intention, but there is a little difference. ****
>
> I more like to have a flag outside of MELG sub-TLV to indicate if a link
> is a Virtual link or **regular* *link (and then path computation can be
> aware of this).****
>
> ** **
>
> IB>> The flag you are talking about needs to be stuck into some sub-TLV,
> right? Because the MELGs and the flag are only meaningful for VLs, why not
> to use just one sub-TLV? For example, it is possible to specify 0 MLGs in
> the sub-TLV and set/clear the U bit to advertise ****
>
> **a)      **Whether the link is VL or not (the fact that the sub-TLV
> present or not);****
>
> **b)      **Whether the VL is committed or not (depends on U bit)****
>
> ** **
>
> For the “U-Bit” defined in your draft, I think there is some logic issue.
> I think a virtual link is always *virtual* (ie., uncommitted). If a virtual
> link is committed, then this “virtual” link becomes a *regular* link (and
> the other virtual links sharing the same resource of the sever layer will
> become unavailable (or will be withdrawn) , and then MELG becomes useless
> (as what Igor said that “MELGs make only sense for VLs”).****
>
> ** **
>
> IB>> Here I disagree. The way we see it, VL is decoupled completely from
> the data plane, and thus, remains VL even after the necessary data plane is
> in place, i.e. becomes committed. This differs our view from, say, MLN/MRN,
> where VL is converted to RL whenever the H-LSP is in place. We say that
> when VL is committed the necessary DP in the provider network is
> provisioned, which could be realized via single H-LSP or chain of H-LSPs
> (provisioned by provider CP or SDN controller), which is not seen by the
> client, nor it is important. In other words, VL is a piece of fiction,
> always virtual, rather than something that could be one moment virtual and
> the next converted into something real. Clients never see RLs. This allows,
> among other things, to have a separate (proprietary) set of attributes for
> RLs while standardized (and hence understood by clients) for VLs****
>
> ****
>
> Cheers,****
>
> Igor****
>
> ** **
>
> ** **
>
> ** **
>
> Best Regards****
>
> ** **
>
> Fatai****
>
> ** **
>
> *From:* Vishnu Pavan Beeram [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Tuesday, March 26, 2013 10:45 PM
> *To:* Fatai Zhang
>  ****
>   ****
>  ****
>   ****
> regard.****
> a link is a Virtual TE Link or not. ****
>
> ** **
>
> -Pavan****
>
>  ****
>
>   ****
>
> *Cc:* Igor Bryskin; [email-masked]****
>
>
>  ****
>  ****
>  ****
>  ****