Re: [CCAMP] MELGs - Q&A

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

Khuzema, Hi!

MELGs are useful and come into play only when:
(1) The server network domain is abstracted and the advertised Virtual
TE-links possess some mutual exclusivity relationship.
(2) There is a Centralized path computation entity in the client domain
(computes paths in terms of Client TE-links/TE-nodes) that is capable of
doing concurrent path computations.

If either of the above 2 statements is NOT true, there is no utility for
MELGs.
At the risk of being pedantic:
- Are MELGs needed when the server-network domain in not abstracted (no
Virtual TE links)? The answer is NO.
- Are MELGs needed when you have a distributed path-computation
architecture (Client PCE interacting with Server PCE)? The answer is NO.
- Are MELGs needed when the centralized path-computation engine doesn't
(can't) do concurrent computations? The answer is NO.

The actual procedures involved in abstracting the server network domain is
beyond the scope of <draft-melgs>. The abstraction procedure itself is
implementation-specific (maybe someday someone would put together a draft
for discussing this). Though it is true that the primary use-case we had in
mind when coming up with this new construct involves a lambda-layer server
network domain, there is really no restriction (at a conceptual level) on
using this construct when abstracting a packet-layer server network domain
or a TDM-layer server network domain. It is up to the implementation on how
to make best use of this construct.

When you advertise a Virtual TE-link into a client network domain, you are
doing this based on the existence of some potential underlying server-path.
TE attributes like SRLGs, MELGs, delay etc that get advertised for the
Virtual TE-link depend on the underlying server-path that is chosen for
catering to this Client TE-link. If the underlying server-path keeps
changing (based on network events), these TE attributes would also keep
changing. The procedure for keeping the advertised information "current" is
an implementation choice.

If there exists such a thing as an abstraction manager (again, this is
totally implementation specific), then the assumption is that it does one
of the following -
(a) computes new server-paths for the Virtual TE links whenever there is a
change in the network (may not be very scalable in some architectures),
(b) or does periodic path-computation for each Virtual TE link,
(c) or uses a policy to pin down the Virtual TE-link to a specific
underlying server-path,
(d) or uses a combination of (a), (b), (c).

<draft-melgs> doesn't make any recommendation as to what choice the
abstraction manager would need to take.

Hope this helps.
-Pavan


On Tue, Apr 16, 2013 at 7:08 AM, Khuzema Pithewan <[e-mail]>wrote:

>  Hi Igor,****
>
> ** **
>
> I am trying to summarize the discussion we had so far. Pls see if my
> conclusion is in sync with the idea of MELG you have ****
>
> ** **
>
> MELG is useful when****
>
> **1.       **server layer VLs are nailed down for the resources on the
> server layer links that are shared among multiple VLs. These resources are
> typically wavelength on a fiber (can it be anything else??). In other
> words, if 2 VLs are pinned to use a particular wavelength on a particular
> fiber, then these 2 VLs will have MELG for the wavelength.****
>
> **2.       **server layer do not have centralized path computation entity
> which can be used by client layer to ask for concurrent diverse path
> computation within server layer.****
>
> **3.       **Client layer has a centralized path computation entity,
> which would compute paths for client+server layer.****
>
> **4.       **The need is to centralized concurrent computation of more
> than one client+server layer path that meets some diversity and resource
> exclusivity requirements.****
>
> ** **
>
> Regds****
>
> Khuzema****
>
> ** **
>
> *From:* Igor Bryskin [mailto:[e-mail]]
> *Sent:* Monday, April 15, 2013 9:44 PM
>
> *To:* Khuzema Pithewan; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [e-mail]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
>  ** **
>
> Khuzema,****
>
> Please, see in-line.****
>
> ** **
>
> Igor****
>
> ** **
>
> *From:* Khuzema Pithewan [mailto:[e-mail]]
> *Sent:* Monday, April 15, 2013 12:05 AM
> *To:* Igor Bryskin; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [e-mail]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Hi Igor,****
>
> ** **
>
> I understand the SRLG and MELG behavior you have penned .****
>
> ** **
>
> My concern was little different.  With changing resource consumption
> (because of dynamicity the network has) in the network links, potential
> paths a set of virtual link can take will change and hence its MELG, as it
> is tied to a resource it can take. So unless virtual links paths are nailed
> down, it would be hard to compute MELGs in distributed way.****
>
> ** **
>
> IB>> I think you are missing the point here. Virtual Link server layer
> paths are pinned as far as fate sharing is concerned (that is, they are
> pinned on  server layer link level). It would make little sense to
> advertise VL SRLGs if the SRLGs constantly change. The same is true for
> MELGs.  SRLGs/MELGs advertised for VLs normally do not change: neither over
> time nor when VLs become committed/uncommitted.****
>
> ** **
>
> Another point is, virtual links can be viewed as oversubscription of
> resources (in MELG context). Taking an example (for OTN, I know it would
> work differently for a Wavelength in WDM), a link resources are worth 1 TB
> of BW, user has provisioned 20 virtual links of 100G each going via that
> OTN link.  Physically, only 10 will get committed. But which 10? It will
> really depend on network dynamics at the time of demand to commit. MELGs
> are not that effective here. You need some different mechanism.****
>
> ** **
>
> IB>> As I mentioned before MELGs have nothing to do with bandwidth and
> were never intended to solve the problems such as you describe (just like
> it would not make much sense to solve such problem with SRLGs :=)****
>
> Again,  MELG is an extreme case SRLG designed exclusively for VLs (no more
> and no less).****
>
> ** **
>
> Regds****
>
> Khuzema****
>
> ** **
>
> ** **
>
> *From:* Igor Bryskin [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Friday, April 12, 2013 11:55 PM
> *To:* Khuzema Pithewan; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [e-mail]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Khuzema,****
>
> ** **
>
> Think about MELG as an SRLG that is shared between two or more links in
> its entirety. When two real links have an SRLG in common, it means that two
> real links can co-exist concurrently, but there is something (e.g. common
> conduit, note that the conduit has room for more than for one link) that
> will bring both these links down, if this something fails (e.g. conduit is
> cut ). Now consider that this something must be taken in its entirety by
> one of the links to become operational . In this case SRLG becomes MELG.
> Note that MELG is only meaningful for virtual links (unlike SRLG that makes
> sense for either real or virtual link). Why would you advertise two links
> that mutually exclude each other rather than advertising only one of them
> at a time, unless the two are virtual links and hence both available for
> the client layer connections?****
>
> ** **
>
> Igor ****
>
> ** **
>
> ** **
>
> *From:* Khuzema Pithewan [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Friday, April 12, 2013 1:01 PM
> *To:* Igor Bryskin; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [e-mail]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Hi Igor,****
>
> ** **
>
> Do you mean, if virtual link do not have any specific constraint, for
> example a link in the path (not talking about egress links/interfaces) must
> be traversed to realize the virtual link, there wont be any MELG for the
> virtual link?****
>
> ** **
>
> Regds****
>
> Khuzema****
>
> ** **
>
> *From:* Igor Bryskin [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Friday, April 12, 2013 9:52 PM
> *To:* Khuzema Pithewan; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [e-mail]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
> ** **
>
> Khuzema,****
>
>  ****
>
> MELGs have nothing to do with bandwidth. MELG is a concrete network
> resource in a server layer that two or more Virtual Links in a client layer
> depend on in a mutually exclusive way. An example of MELG is a WDM layer
> transponder that can terminate either of respective WDM layer tunnels (but
> not both at the same time) for two OTN layer Virtual Links. If you
> advertise a Virtual Link, say, for Ethernet layer that depends on the
> connection in OTN layer going through one of the mentioned OTN links, the
> Ethernet VL must inherit the MELG similarly like it does SRLGs advertised
> for the OTN links.****
>
>  ****
>
> Igor****
>
>  ****
>
>  ****
>
> *From:* Khuzema Pithewan [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Friday, April 12, 2013 12:06 PM
> *To:* Igor Bryskin; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [e-mail]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
>  ****
>
> Hi Igor,****
>
>  ****
>
> For multi-layer (more than 2) network, consider all the layers are meshy
> (that’s when virtual links are useful anyway), MELGs of virtual link will
> change as and when BW/wavelength availability changes, because potential
> paths, a virtual link can take will change. Mapping lower layer MELGs to
> higher layer MELGs won’t be practical if done in distributed manner, so it
> has to be centralized. So you do have central element in each layer that
> knows all the risk and paths (a PCE?), which can be utilized for layer
> specific path computation (as it is doing it anyway). ****
>
>  ****
>
> This kind of architecture has all the pieces that are required for
> Inter-PCE communication (across layers), except the protocol that would
> actually make the 2 PCEs talk.****
>
>  ****
>
> You seem to be doing something that you don’t like J****
>
>  ****
>
> Regards****
>
> Khuzema****
>
>  ****
>
> *From:* Igor Bryskin [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Friday, April 12, 2013 8:39 PM
> *To:* Khuzema Pithewan; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [e-mail]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
>  ****
>
> Khuzema,****
>
>  ****
>
> I am not a fan of inter-layer path computations (nor I am a fan of
> inter-PCE computations). In my mind path computation for a service or
> services in layer X is performed only in layer X, i.e. considers only X
> layer links (real or virtual). As Pavan mentioned SRLGs and MELGs that need
> to be inherited from lower layers should be translated into X layer link
> SRLGs/MELGs and specified with X layer specific SRLG/MELG IDs.****
>
>  ****
>
> Cheers,****
>
> Igor****
>
>  ****
>
>  ****
>
> *From:* Khuzema Pithewan [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Friday, April 12, 2013 10:55 AM
> *To:* Igor Bryskin; Vishnu Pavan Beeram
> *Cc:* Dieter Beller; [e-mail]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
>  ****
>
> Hi Igor,****
>
>  ****
>
> Ok. This would be useful if network architecture is based on external PCE
> or mgmt entity as PCE in client layer, but there is no counterpart in
> server layer, otherwise one could have inter-PCE communication to achieve
> diverse path in server layer without getting into virtual link and MELG
> stuff.****
>
>  ****
>
> Is that correct?****
>
>  ****
>
> Khuzema****
>
>  ****
>
> *From:* Igor Bryskin [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Friday, April 12, 2013 6:36 PM
> *To:* Vishnu Pavan Beeram; Khuzema Pithewan
> *Cc:* Dieter Beller; [e-mail]
> *Subject:* RE: [CCAMP] MELGs - Q&A****
>
>  ****
>
> Khuzema,****
>
>  ****
>
> 2.       For cases of concurrent computation (case#2-5), you are mainly
> talking about global optimization and diversity among multiple services.
> You can do the path computation, but to actually enact the computed path
> the signaling needs to be done from the source end of those LSPs.  So there
> is no point in doing concurrent computation at one network element for the
> services starting from multiple network elements. At best it looks to me a
> problem to be solved by network management/planning software. ****
>
> Well, when an ingress node is initiating a service, it is doing so on
> request from some management entity. This management entity can compute
> paths for many services with some global criteria in mind, and then specify
> the resulting paths as explicit EROs in provisioning requests sent to each
> of the service ingresses. How else, for example,  you can set up several
> services originated from different nodes that are disjoint from each other?
> Also, what is the point in your opinion of the statefull PCE work? ****
>
>  ****
>
> Cheers,****
>
> Igor****
>
>  ****
>
> *From:* Vishnu Pavan Beeram [mailto:[e-mail]<[e-mail]>]
>
> *Sent:* Friday, April 12, 2013 8:08 AM
> *To:* Khuzema Pithewan
> *Cc:* Igor Bryskin; Dieter Beller; [e-mail]
> *Subject:* Re: [CCAMP] MELGs - Q&A****
>
>  ****
>
> Khuzema, Hi!****
>
>
> Please see inline..****
>
>  ****
>
>  ****
>
>  1.       When Network has more than 2 layer i.e. Packet-OTN-DWDM, the
> Packet (client) layer will be talking to its immediate server layer i.e.
> OTN, which in turn is talking to DWDM layer. Using MELG, client layer path
> computation can take care of resource exclusivity of virtual link for
> immediate server layer i.e. OTN layer.  However if there is resource
> exclusivity at DWDM layer, this mechanism doesn’t work. You need to do
> loose routing or use distributed PCE model****
>
>   ****
>
> [VPB] The behavior is the same as what you would do with SRLGs in a
> multi-layer architecture. There are architectures that allow the SRLGs in
> the lowest layer to be exported all the way up to the highest layer. The
> expectation is that MELGs would be treated in the same vein. ****
>
>  2.       For cases of concurrent computation (case#2-5), you are mainly
> talking about global optimization and diversity among multiple services.
> You can do the path computation, but to actually enact the computed path
> the signaling needs to be done from the source end of those LSPs.  So there
> is no point in doing concurrent computation at one network element for the
> services starting from multiple network elements. At best it looks to me a
> problem to be solved by network management/planning software. ****
>
>  [VPB]  I'm not sure why you think there is no point in having a
> centralized computation function compute paths concurrently for LSPs with
> different set of end-points. Even your NMS/planning-software can interact
> with such computation engine, retrieve all the paths and then go about
> initiating the path-setup from the ingress of each LSP. ****
>
>  ****
>
> Regards,****
>
> -Pavan****
>
>  ****
>
>   ****
>
>  ****
>
>  ****
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Igor Bryskin
> *Sent:* Tuesday, March 26, 2013 7:19 PM
> *To:* Dieter Beller; Vishnu Pavan Beeram****
>
>
> *Cc:* [e-mail]
> *Subject:* Re: [CCAMP] MELGs - Q&A****
>
>  ****
>
> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Dieter Beller
> *Sent:* Monday, March 25, 2013 5:52 PM
> *To:* Vishnu Pavan Beeram
> *Cc:* [e-mail]
> *Subject:* Re: [CCAMP] MELGs - Q&A****
>
>  ****
>
> 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:[e-mail]<[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****
>
>  ****
>
> _______________________________________________****
>
> CCAMP mailing list****
>
> [e-mail]****
>
> 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: [phone] begin_of_the_skype_highlighting [phone]FREE
> end_of_the_skype_highlighting <%2B49%20711%20821%2043125>
> Mobil: [phone] begin_of_the_skype_highlighting [phone]FREE
> end_of_the_skype_highlighting <%2B49%20175%207266874> ****
>
> *[e-mail] *****
>
>  ****
>
> 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 ****
>
>   ****
>