Re: [CCAMP] MELGs - Q&A

[Vishnu Pavan Beeram <[e-mail]>]

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 <[e-mail]>wrote:

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