Re: [CCAMP] MELGs - Q&A

[Igor Bryskin <[e-mail]>]

Hi Fatai,

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

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).

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:[e-mail]]
Sent: Tuesday, March 26, 2013 10:45 PM
To: Fatai Zhang
Cc: Igor Bryskin; [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] MELGs - Q&A


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:[e-mail]<mailto:[e-mail]>]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; [e-mail]<mailto:[e-mail]>

Subject: Re: [CCAMP] MELGs - Q&A

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