Subject: [L3sm] [l3sm] #8 (draft-ltsd-l3sm-l3vpn-service-model): Who keep Site location information?

From: "l3sm issue tracker" <[email-masked]>
Date: Wed, 23 Sep 2015 08:41:53 -0000

#8: Who keep Site location information?

 In Prague meeting, the network orchestrator handling Site Location was
 discussed, one question is about whether the network orchestrator should
 keep the Site location information?

-- 
-------------------------------------+-------------------------------------
 Reporter:  [email-masked]       |      Owner:  draft-ltsd-l3sm-l3vpn-
     Type:  enhancement              |  [email-masked]
 Priority:  trivial                  |     Status:  new
Component:  draft-ltsd-l3sm-l3vpn-   |  Milestone:
  service-model                      |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/l3sm/trac/ticket/8>
l3sm <http://tools.ietf.org/l3sm/>

---

From: "l3sm issue tracker" <[email-masked]>
Date: Thu, 24 Sep 2015 13:07:19 -0000

Comment (by [email-masked]):

 This comment was less about the wording in the I-D itself, but about side
 effects:

 Site location information could for instance be stored in an inventory
 system, while most other parameters in the L3SM model would have to be
 handled by an SDN controller. Thus, implementing that part of the L3SM
 model may require an interaction between two separate systems.

 Since the location parameter is optional in the L3SM model, I don't think
 that the wording of the I-D has to be changed. But this should stay an
 optional attribute in the model, IMHO.

 Severity:  -                        |  Resolution:
 Keywords:                           |

Ticket URL: <http://trac.tools.ietf.org/wg/l3sm/trac/ticket/8#comment:1>
l3sm <http://tools.ietf.org/l3sm/>

---

From: "l3sm issue tracker" <[email-masked]>
Date: Fri, 25 Sep 2015 02:08:47 -0000

Comment (by [email-masked]):

 Replying to [comment:1 michael.scharf@…]:
 > This comment was less about the wording in the I-D itself, but about

 [Qin]: Section 5.2.1.3 said
 "  As an example, the management system receiving the request
    for diversity, MAY exchange information with some OSS components to
    define the best target PEs based on location and ressource
    availability.
 "
 that is to say, the management system need to interact with OSS to choose
 the best target PEs, the location and resource availability are entered by
 customer in the service model and used as constraints to compute the best
 PEs, we can assume the site location doesn't need to be kept by the
 management system upon the best PE is selected. Do we need to have a
 separate inventory system to store site location, why not keep all these
 parameters in the same NETCONF/RESTCONF datastore? Do you want to have a
 separate inventory sytem to store computation results, e.g., selected Best
 PE?

 > Since the location parameter is optional in the L3SM model, I don't
 think that the wording of the I-D has to be changed. But this should stay
 an optional attribute in the model, IMHO.

 [Qin]:Yes, in v(-01),the location parameter is optional parameter. One of
 reasons, I think, is in some case customer doesn't have preference on site
 location.

Ticket URL: <http://trac.tools.ietf.org/wg/l3sm/trac/ticket/8#comment:2>
l3sm <http://tools.ietf.org/l3sm/>

---

From: "l3sm issue tracker" <[email-masked]>
Date: Sun, 27 Sep 2015 10:40:11 -0000

I think the L3SM model should not make too many assumptions about
 information exchange between the system offering the L3SM model and other
 systems, such as inventory databases. The dependency on other systems can
 trigger quite a number of further questions: For instance, what happens if
 the inventory system does not return useful location information? Should a
 L3SM service request then be processed without considering location? Or
 should errors be returned? If so, what errors?

 According to a MAY in Section 6, I think that the location parameter can
 be ignored if it cannot be handled:

    As described in Section 5.2.1, the management system MAY
    use the location information and MUST use the site-diversity
    constraint to find the appropriate PE.

 Actually, perhaps this MUST for site-diversity could be turned into a
 SHOULD, because Section 5.2.1.3. states on site-diversity:

    How these diversity constraints are applied is out of scope of the
    document.

 Also in case of site-diversity I wonder if the L3SM model would have to
 consider responses to errors, e.g., inability to fulfill a diversity
 constraint.

 Michael

Ticket URL: <http://trac.tools.ietf.org/wg/l3sm/trac/ticket/8#comment:3>
l3sm <http://tools.ietf.org/l3sm/>

---

From: Qin Wu <[email-masked]>
Date: Mon, 28 Sep 2015 09:29:52 +0000

Hi, Michael:
-----邮件原件-----
发件人: l3sm issue tracker [mailto:[email-masked]] 
发送时间: 2015年9月27日 18:40
收件人: [email-masked]; [email-masked]; Qin Wu
抄送: [email-masked]
主题: Re: [l3sm] #8 (draft-ltsd-l3sm-l3vpn-service-model): Who keep Site location information?

 I think the L3SM model should not make too many assumptions about information exchange between the system offering the L3SM model and other systems, such as inventory databases. 

[Qin]: Here is my understanding.
The service model is built from customer perspective in more abstract way, it is challenge for the customer provide service parameters from service provider network perspective, these parameters should be provided by Network OSS as planning parameters, yes, we need service component to interact with OSS, but both service component and OSS belong to the same management system.

The dependency on other systems can trigger quite a number of further questions: For instance, what happens if  the inventory system does not return useful location information? 

[Qin]: See above, Network OSS and Service Orchestrator are part of the same management system. We require management system to compute the appropriate PE, but I am not sure it is
the job of inventory system, maybe you are referred to PCE?

Should a  L3SM service request then be processed without considering location? Or should errors be returned? If so, what errors?

[Qin]: I think the authors of draft-ltsd-l3sm-l3vpn-service-model need to consider how failure can be handled when the management system can not find appropriate PE.

 According to a MAY in Section 6, I think that the location parameter can  be ignored if it cannot be handled:

 Actually, perhaps this MUST for site-diversity could be turned into a  SHOULD, because Section 5.2.1.3. states on site-diversity:

[Qin]: Fair enough. This is RFC2119 language issue. I remembers Luis and Stephane talked about this before. We should make sure these RFC2119 languages are used correctly in the document.

 Also in case of site-diversity I wonder if the L3SM model would have to  consider responses to errors, e.g., inability to fulfill a diversity  constraint.

 Michael

-- 
-------------------------------------+----------------------------------
-------------------------------------+---
 Reporter:  [email-masked]       |       Owner:  draft-ltsd-l3sm-l3vpn-
     Type:  enhancement              |  [email-masked]
 Priority:  trivial                  |      Status:  new
Component:  draft-ltsd-l3sm-l3vpn-   |   Milestone:
  service-model                      |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+----------------------------------
-------------------------------------+---

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 28 Sep 2015 10:03:06 +0000

Hi Qin,

I don't think the inventory system has to determine the PE. Of course, this has to be performed by the system offering the L3SM interface. But my understanding is that some forms of diversity require rather advanced logic, beyond a basic PCE, and this could result in complexity, e.g., in heterogeneous networks. And the more constraints have to be considered, the higher is the risk that the logic cannot fulfill a given request.

This is why I wonder about the suggested error behavior in the L3SM model. This is actually a question that applies beyond location.

Michael

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, September 28, 2015 11:30 AM
To: l3sm issue tracker; [email-masked]; Scharf, Michael (Michael)
Cc: [email-masked]
Subject: Re: [L3sm] [l3sm] #8 (draft-ltsd-l3sm-l3vpn-service-model): Who keep Site location information?

Hi, Michael:
-----邮件原件-----
发件人: l3sm issue tracker [mailto:[email-masked]]
发送时间: 2015年9月27日 18:40
收件人: [email-masked]; [email-masked]; Qin Wu
抄送: [email-masked]
主题: Re: [l3sm] #8 (draft-ltsd-l3sm-l3vpn-service-model): Who keep Site location information?

[Qin]: See above, Network OSS and Service Orchestrator are part of the same management system. We require management system to compute the appropriate PE, but I am not sure it is the job of inventory system, maybe you are referred to PCE?

 Michael

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 28 Sep 2015 10:20:39 +0000

Hi, Michael:
I think it is service component(i.e., the system offering L3SM interface to Customer) to determine the PE, 
service component gets site location information from the customer, since customer know his own preference for site location,
and then service component uses customer preferred site location and site diversity constraint to select PE, how service component interact with
any system providing computation capability) is not in the scope of this document.

Yes, it is challenge to fulfill a service request with various constraint in the heterogeneous network environment, but PCE, maybe ALTO server did
could provide a generic mechanism for PE selection. If PCE or ALTO server is not possible, service component should have its own computation capability to
to decide the PE.

Yes, I agree the error behavior needs to be considered if we need to give an example to discuss interaction between service component with other systems for PE selection.

-Qin
-----邮件原件-----
发件人: Scharf, Michael (Michael) [mailto:[email-masked]] 
发送时间: 2015年9月28日 18:03
收件人: Qin Wu; l3sm issue tracker; [email-masked]
抄送: [email-masked]
主题: RE: [l3sm] #8 (draft-ltsd-l3sm-l3vpn-service-model): Who keep Site location information?

Hi Qin,

Michael

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, September 28, 2015 11:30 AM
To: l3sm issue tracker; [email-masked]; Scharf, Michael (Michael)
Cc: [email-masked]
Subject: Re: [L3sm] [l3sm] #8 (draft-ltsd-l3sm-l3vpn-service-model): Who keep Site location information?

Hi, Michael:
-----邮件原件-----
发件人: l3sm issue tracker [mailto:[email-masked]]
发送时间: 2015年9月27日 18:40
收件人: [email-masked]; [email-masked]; Qin Wu
抄送: [email-masked]
主题: Re: [l3sm] #8 (draft-ltsd-l3sm-l3vpn-service-model): Who keep Site location information?

 Michael