Subject: [lmap] draft-boucadair-lmap-considerations

From: <[email-masked]>
Date: Mon, 18 Feb 2013 14:09:22 +0100

Dear all,

We submitted this new I-D.

Comments are welcome.
Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : lundi 18 février 2013 14:05
À : BOUCADAIR Mohamed OLNC/OLN
Cc : JACQUENET Christian OLNC/OLN
Objet : New Version Notification for draft-boucadair-lmap-considerations-00.txt

A new version of I-D, draft-boucadair-lmap-considerations-00.txt
has been successfully submitted by Mohamed Boucadair and posted to the
IETF repository.

Filename:	 draft-boucadair-lmap-considerations
Revision:	 00
Title:		 Large scale Measurement of Access network Performance (LMAP): Requirements and Issues from a Network Provider Perspective
Creation date:	 2013-02-18
Group:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-boucadair-lmap-considerations-00.txt
Status:          http://datatracker.ietf.org/doc/draft-boucadair-lmap-considerations
Htmlized:        http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00

Abstract:
   This document raises several points related to the ongoing LMAP
   (Large scale Measurement of Access network Performance) effort.  The
   goal is to contribute to define a scope for LMAP and its expected
   contribution.

The IETF Secretariat

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 18 Feb 2013 21:35:06 +0000

> Title:		 Large scale Measurement of Access network Performance
> (LMAP): Requirements and Issues from a Network Provider Perspective

Thanks. I think this is good as a foundation for some much needed discussion. I have some questions around what this draft's intended focus/scope is, that may help clarify some of the questions raised in the draft.

The document's title states that it is intended to provide the Network Provider's perspective. Does that mean that the intention is to provide the requirements that a Network Provider has for the systems, network elements, devices, and applications that are managed/controlled by the Network Provider? And are these all of the requirements that a Network Provider might have (in the global LMAP context), or just the ones that a Network Provider wants the IETF to help with?

If it is not intended to restrict itself to a Network Provider's requirements for their own boxes and applications, then I would recommend splitting out the requirements that a Network Provider has for their own things, and any other requirements that the draft may include. I would also recommend characterizing the other requirements. Are they requirements of others on Network Providers? Are they requirements of a Network Provider (a subset of "others" from the previous question) on other Network Providers? Or are they requirements of a Network Provider on others (End Users, etc.)? Personally, I would prefer not to include any of these sorts of requirements in this draft (I think they should be in a different draft that does not claim to express the Network Provider's perspective). But if they are included, they should be clearly delineated -- it's important to distinguish between requirements one entity is attempting to impose on another, vs. requirements that an entity is imposing on themselves.

I would also recommend restricting the scope of the draft to requirements that Network Providers want the IETF to help with.

The draft discusses "domain". I would suggest distinguishing between "network domain" and "management domain". For example, the Customer Premises Network (CPN) is a distinct network domain. The Network Provider whose perspective this is, may have managed devices or applications residing in the CPN, or in the network of some server hosting provider. As an employee of a "Network Provider", I would definitely express interest in seeing the framework consider inter-"network domain" measurement. Inter-"management domain" is a different story. In the context of what I said above, I think that inter-"management domain" only needs to be included in this draft if there is a Network Provider who is actively asking the IETF for help with that, in the context of providing interfaces to their own boxes and applications. [Note that if there is no Network Provider asking for such help, this does not necessarily mean that Network Providers are uninterested in such a capability -- merely that they are not asking the IETF to help solve it.]
Barbara

---

From: <[email-masked]>
Date: Tue, 19 Feb 2013 07:35:14 +0100

Dear Barbara,

Thank you for reading and providing comments. 

The initial goal of the draft is to focus on the requirements from a network provider for LMAP system. 
I agree with your comment regarding the "domain" notion. This will be clarified in the next version of the draft. 

BTW, we will be more than happy to welcome contributions from other network providers.

Cheers,
Med 

>De : STARK, BARBARA H [mailto:[email-masked]] 
>Envoyé : lundi 18 février 2013 22:35
>À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]
>Objet : RE: draft-boucadair-lmap-considerations
>
>> URL:             
>http://www.ietf.org/internet-drafts/draft-boucadair-lmap-consid
erations-00.txt
>Thanks. I think this is good as a foundation for some much 
>needed discussion. I have some questions around what this 
>draft's intended focus/scope is, that may help clarify some of 
>the questions raised in the draft.
>
>The document's title states that it is intended to provide the 
>Network Provider's perspective. Does that mean that the 
>intention is to provide the requirements that a Network 
>Provider has for the systems, network elements, devices, and 
>applications that are managed/controlled by the Network 
>Provider? And are these all of the requirements that a Network 
>Provider might have (in the global LMAP context), or just the 
>ones that a Network Provider wants the IETF to help with?
>
>If it is not intended to restrict itself to a Network 
>Provider's requirements for their own boxes and applications, 
>then I would recommend splitting out the requirements that a 
>Network Provider has for their own things, and any other 
>requirements that the draft may include. I would also 
>recommend characterizing the other requirements. Are they 
>requirements of others on Network Providers? Are they 
>requirements of a Network Provider (a subset of "others" from 
>the previous question) on other Network Providers? Or are they 
>requirements of a Network Provider on others (End Users, 
>etc.)? Personally, I would prefer not to include any of these 
>sorts of requirements in this draft (I think they should be in 
>a different draft that does not claim to express the Network 
>Provider's perspective). But if they are included, they should 
>be clearly delineated -- it's important to distinguish between 
>requirements one entity is attempting to impose on another, 
>vs. requirements that an entity is imposing on themselves.
>
>I would also recommend restricting the scope of the draft to 
>requirements that Network Providers want the IETF to help with.
>
>The draft discusses "domain". I would suggest distinguishing 
>between "network domain" and "management domain". For example, 
>the Customer Premises Network (CPN) is a distinct network 
>domain. The Network Provider whose perspective this is, may 
>have managed devices or applications residing in the CPN, or 
>in the network of some server hosting provider. As an employee 
>of a "Network Provider", I would definitely express interest 
>in seeing the framework consider inter-"network domain" 
>measurement. Inter-"management domain" is a different story. 
>In the context of what I said above, I think that 
>inter-"management domain" only needs to be included in this 
>draft if there is a Network Provider who is actively asking 
>the IETF for help with that, in the context of providing 
>interfaces to their own boxes and applications. [Note that if 
>there is no Network Provider asking for such help, this does 
>not necessarily mean that Network Providers are uninterested 
>in such a capability -- merely that they are not asking the 
>IETF to help solve it.]
>Barbara
>

---

From: <[email-masked]>
Date: Tue, 19 Feb 2013 09:51:31 +0100

Barbara,

Thanks for your feedback. A couple of comments below in addition to Med's. 

[snip]

The document's title states that it is intended to provide the Network Provider's perspective. Does that mean that the intention is to provide the requirements that a Network Provider has for the systems, network elements, devices, and applications that are managed/controlled by the Network Provider?

CJ: that's the intent indeed. But one of the primary goals is to stimulate discussions about issues raised LMAP systems from a service provider's perspective. 

And are these all of the requirements that a Network Provider might have (in the global LMAP context), or just the ones that a Network Provider wants the IETF to help with?

CJ: first, I don't think we documented a comprehensive list of requirements. We wanted to make sure the draft meets the cut-off date prior to discussions in Orlando. Second, the draft indeed aims at soliciting the IETF about these requirements and issues. As such, there may be additional requirements that either refer to service provider-specific operational guidelines or to areas where other SDOs may be solicited. Admittedly, I don't have a clear view on the full scope of requirements yet.

If it is not intended to restrict itself to a Network Provider's requirements for their own boxes and applications, then I would recommend splitting out the requirements that a Network Provider has for their own things, and any other requirements that the draft may include.

CJ: fair enough.  

I would also recommend characterizing the other requirements. Are they requirements of others on Network Providers? Are they requirements of a Network Provider (a subset of "others" from the previous question) on other Network Providers?

CJ: this one suggests inter-domain considerations which I think need to be tackled indeed. 

Or are they requirements of a Network Provider on others (End Users, etc.)? Personally, I would prefer not to include any of these sorts of requirements in this draft (I think they should be in a different draft that does not claim to express the Network Provider's perspective).

CJ: I agree, for the sake of clarity.
 
But if they are included, they should be clearly delineated -- it's important to distinguish between requirements one entity is attempting to impose on another, vs. requirements that an entity is imposing on themselves.

CJ: right.

CJ: agreed, that's the intent.

The draft discusses "domain". I would suggest distinguishing between "network domain" and "management domain". For example, the Customer Premises Network (CPN) is a distinct network domain. The Network Provider whose perspective this is, may have managed devices or applications residing in the CPN, or in the network of some server hosting provider. As an employee of a "Network Provider", I would definitely express interest in seeing the framework consider inter-"network domain" measurement.

CJ: the notion of domain introduced in the draft basically relies upon the typical BGP domain notion, i.e., a set of network devices operated by a single administrative entity. Such devices may include CPEs for some providers.  

Inter-"management domain" is a different story. In the context of what I said above, I think that inter-"management domain" only needs to be included in this draft if there is a Network Provider who is actively asking the IETF for help with that, in the context of providing interfaces to their own boxes and applications. [Note that if there is no Network Provider asking for such help, this does not necessarily mean that Network Providers are uninterested in such a capability -- merely that they are not asking the IETF to help solve it.]

CJ: I think your notion of inter-management domain can be seen as a collateral effect of inter-domain considerations, where measurement practices/capabilities between domains may need to be exchanged/exposed/negotiated at the level of a management layer. This is one of the areas we'd like to further expand in the next versions of the draft. 

Cheers,

Christian.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.