Opened 7 years ago

Last modified 7 years ago

#8 new enhancement

Who keep Site location information?

Reported by: bill.wu@… Owned by: draft-ietf-l3sm-l3vpn-service-model@…
Priority: trivial Milestone: milestone1
Component: l3vpn-service-model Version: 2.0
Severity: Active WG Document Keywords:
Cc:

Description

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?

Change History (8)

comment:1 follow-up: Changed 7 years ago by michael.scharf@…

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.

comment:2 in reply to: ↑ 1 Changed 7 years ago by bill.wu@…

Replying to michael.scharf@…:

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.

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

comment:3 Changed 7 years ago by michael.scharf@…

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

comment:4 Changed 7 years ago by michael.scharf@…

I think the original ticket should be fairly simple to close, since this is not really about a change of the YANG model. It is more about the vague description of what system would implement this model, and how it would interact with other systems.

Regarding locatiom specifically, some additional wording as shown on slide 15 in the IETF 94 presentation could perhaps be added, but to me it is not absolutely necessary.

However, the IETF 94 presentation did not mention my comment on MUST vs. SHOULD on site diversity. I am not convinced that a MUST on an unspecified mechanism really makes sense, and since this also does not affect the YANG model, the solution to this aspect could be simple as well. If this question requires follow-up discussion, my proposal would be to close this ticket and issue a new ticket for the MUST/SHOULD specifically.

comment:5 Changed 7 years ago by stephane.litkowski@…

Could you repoint your comment on MUST vs SHOULD on site diversity ? sorry for having miss it.

comment:6 Changed 7 years ago by michael.scharf@…

See ticket 11 - this should not prevent closing this issue.

comment:7 in reply to: ↑ description Changed 7 years ago by sunseawq@…

Michael Scharf agreed to close this issue and also propose to use SHOULD for site diversity on issue #11.

Replying to bill.wu@…:

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?

comment:8 Changed 7 years ago by bill.wu@…

  • Component changed from draft-ltsd-l3sm-l3vpn-service-model to l3vpn-service-model
  • Milestone set to milestone1
  • Owner changed from draft-ltsd-l3sm-l3vpn-service-model@… to draft-ietf-l3sm-l3vpn-service-model@…
  • Severity changed from - to Active WG Document
  • Version set to 2.0
Note: See TracTickets for help on using tickets.