[OPSAWG] opsawg - Update to a Meeting Session Request for IETF 98

["IETF Meeting Session Request Tool"]

An update to a meeting session request has just been submitted by Warren 
Kumari, a Chair of the opsawg working group.


-
Working Group Name: Operations and Management Area Working Group
Area Name: Operations and Management Area
Session Requester: Warren Kumari

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: capport dane dprive
 Second Priority: dnsop v6ops



People who must be present:
  Joel Jaeggli
  Benoit Claise
  Warren Kumari
  Tianran Zhou

Resources Requested:
  

Special Requests:
  PLEASE NOTE: Combined OpsAWG / OpsAREA.
Please schedule it earlier in the week (before the plenary, one of the chairs 
is becoming AD)
-

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02

[Ignas Bagdonas]

Hi there,

[Copying GROW WG as this might be relevant to their coverage areas]

The document seems to be a good start but covers only standard 
communities. This is not sufficient given the universal deployment of 4 
octet ASNs. Both extended communities [RFC4360] and large communities 
[RFC8092] are needed and are used to address the signalling requirements 
for AS4 ASNs. Having separate documents each addressing only a specific 
type of community does not seem practical and rational. The document 
should include the definitions for IEs covering extended and large 
communities.


What is the logic of selecting multiple communities for export that a 
prefix may have been decorated with? Is it all of them all the time? The 
upper limit may be reaching 16000 standard communities per prefix - 
would that fit into resulting IPFIX IE? If there is a limit, how does it 
work? Is there any interpretation done on the values of the communities 
(all types, not just standard ones)? Those all are operational 
considerations aspects and should be covered in the document, appendix A 
likely could be a good place for it.


Security considerations on the privacy aspects would to be covered.

Ignas




On 13/02/2017 03:36, Tianran Zhou wrote:

Dear OPSAWG,

In Seoul, we got enough interest and positive response on this IPFIX IE 
extension draft.
By the authors' request, this email starts a formal poll. The chairs would like 
to know if the WG participants agree that the following document should be 
adopted as a WG document in OPSAWG.

Export BGP community information in IP Flow Information Export (IPFIX)
https://tools.ietf.org/html/draft-li-opsawg-ipfix-bgp-community-02

The adoption poll will take two weeks. Please let us know your opinion by Feb 
27. It would also be good to hear who is willing to review and/or implement or 
deploy the extension described in the document.

Since we already found that the majority of the f2f participants at our IETF97 
session like this idea, please do speak up now if you do not agree or have 
serious objections (with explanation of course).

Regards,
Tianran

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification

[Adrian Farrel]

Hi Tianran,

Nice summary.

I think some of the confusion may be that 
draft-ietf-netmod-yang-model-classification shows "Network Service YANG 
Modules" on the interface between OSS/BSS and the network. But the "customer 
service model" is at a different place in the hierarchy as shown in Figure 4 of 
draft-wu-opsawg-service-model-explained.

To attend to your specific questions:
> 1. Whether it's necessary to further classify the "Network Service YANG
> Module"?

I'm not particularly interested in doing that except so far as is necessary to 
avoid conflict between the two I-Ds. In draft-wu-opsawg-service-model-explained 
we introduced "customer service module" and "service delivery module" because 
it seemed (to us) that there were two different groups of people using the term 
"service model" to describe very different modules.

> 2. What's the well definition of "Network Service YANG Module", "customer
> service module", "service delivery module"?

Since draft-wu-opsawg-service-model-explained introduces the terms "customer 
service module" and "service delivery module" I am going to say that I am happy 
with the definitions in that document. I can say that "customer service module" 
is used consistently with the L3SM and L2SM work and so it is probably a stable 
definition. "Service delivery module" is a term we invented to match the 
definition in draft-wu-opsawg-service-model-explained: I don't think the term 
is used anywhere else, so maybe a better question is "is this a 
useful/meaningful term?"

If the answer to Q1 is that draft-wu-opsawg-service-model-explained should not 
try to resolve any overlap with draft-ietf-netmod-yang-model-classification, 
then I think the definition of "Network Service YANG Module" in 
draft-ietf-netmod-yang-model-classification is fine (with the few tweaks Dean 
and I discussed on the list).

> 3. What's the well position of the above terms in the management architecture?

Ah, I like that question. But it makes me ask: where should I look for the 
definitive, state-of-the art management architecture?

Thanks for continuing to drive this issue.

Adrian

> -Original Message-
> From: Tianran Zhou [mailto:zhoutian...@huawei.com]
> Sent: 14 February 2017 09:54
> To: Carl Moberg (camoberg); adr...@olddog.co.uk
> Cc: opsawg@ietf.org; draft-ietf-netmod-yang-model-classificat...@ietf.org;
> net...@ietf.org; Dean Bogdanovic
> Subject: RE: Question on draft-ietf-netmod-yang-model-classification
> 
> Hi,
> 
> Based on the discussion, here I try to clean up the confusion of the two I-Ds.
> 
> [draft-ietf-netmod-yang-model-classification] classifies the yang modules into
> "Network Service YANG Module" and the "Network Element YANG Module".
> And usually, it uses "service module" to imply the "Network Service YANG
> Module", i.e., "Network" here only want to limit the scope to network related
> modules. One example of "Network Service YANG Module" is [draft-ietf-l3sm-
> l3vpn-service-model].
> The authors do not want to further classify the service module into more 
> layers,
> until more operational practice comes.
> 
> [draft-wu-opsawg-service-model-explained] further classifies the service 
> module
> into "customer service module" and the "service delivery module". I think 
> this is
> based on the chair work on L3SM and L2SM WG and discussion with operators.
> But the document think the "Network Service YANG Module" defined in [draft-
> ietf-netmod-yang-model-classification] is "service delivery module" not 
> include
> the "customer service module". The [draft-ietf-l3sm-l3vpn-service-model] is
> actually the "customer service module".
> 
> Here comes the question:
> 1. Whether it's necessary to further classify the "Network Service YANG
> Module"?
> 2. What's the well definition of "Network Service YANG Module", "customer
> service module", "service delivery module"?
> 3. What's the well position of the above terms in the management architecture?
> 
> Good to see if we can solve the conflicts, these two I-Ds can complement each
> other.
> 
> Best,
> Tianran
> 
> > -Original Message-
> > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Carl Moberg
> > (camoberg)
> > Sent: Thursday, February 09, 2017 12:48 AM
> > To: adr...@olddog.co.uk
> > Cc: opsawg@ietf.org;
> > draft-ietf-netmod-yang-model-classificat...@ietf.org; net...@ietf.org;
> > Dean Bogdanovic
> > Subject: Re: [netmod] Question on
> > draft-ietf-netmod-yang-model-classification
> >
> > Team,
> >
> >  Inline below.
> >
> > > On Feb 8, 2017, at 8:04 AM, Adrian Farrel  wrote:
> > >
> > > Hi Dean,
> > >
> > > I've been processing your response and the continuing thread with you
> > and Tianran.
> > >
> > >>> We've been trying to ensure that
> > >>> draft-wu-opsawg-service-model-explained is consistent with the
> > >>> latest version of draft-ietf-netmod-yang-model-classification. In
> > >>> discussions with Tianran a question has come up.
> > >>>
> > >>> In section 2 you 

Re: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification

[Tianran Zhou]

Hi,

Based on the discussion, here I try to clean up the confusion of the two I-Ds.

[draft-ietf-netmod-yang-model-classification] classifies the yang modules into 
"Network Service YANG Module" and the "Network Element YANG Module". And 
usually, it uses "service module" to imply the "Network Service YANG Module", 
i.e., "Network" here only want to limit the scope to network related modules. 
One example of "Network Service YANG Module" is 
[draft-ietf-l3sm-l3vpn-service-model].
The authors do not want to further classify the service module into more 
layers, until more operational practice comes.

[draft-wu-opsawg-service-model-explained] further classifies the service module 
into "customer service module" and the "service delivery module". I think this 
is based on the chair work on L3SM and L2SM WG and discussion with operators.
But the document think the "Network Service YANG Module" defined in 
[draft-ietf-netmod-yang-model-classification] is "service delivery module" not 
include the "customer service module". The 
[draft-ietf-l3sm-l3vpn-service-model] is actually the "customer service module".

Here comes the question:
1. Whether it's necessary to further classify the "Network Service YANG Module"?
2. What's the well definition of "Network Service YANG Module", "customer 
service module", "service delivery module"?
3. What's the well position of the above terms in the management architecture?

Good to see if we can solve the conflicts, these two I-Ds can complement each 
other.

Best,
Tianran

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Carl Moberg
> (camoberg)
> Sent: Thursday, February 09, 2017 12:48 AM
> To: adr...@olddog.co.uk
> Cc: opsawg@ietf.org;
> draft-ietf-netmod-yang-model-classificat...@ietf.org; net...@ietf.org;
> Dean Bogdanovic
> Subject: Re: [netmod] Question on
> draft-ietf-netmod-yang-model-classification
> 
> Team,
> 
>  Inline below.
> 
> > On Feb 8, 2017, at 8:04 AM, Adrian Farrel  wrote:
> >
> > Hi Dean,
> >
> > I've been processing your response and the continuing thread with you
> and Tianran.
> >
> >>> We've been trying to ensure that
> >>> draft-wu-opsawg-service-model-explained is consistent with the
> >>> latest version of draft-ietf-netmod-yang-model-classification. In
> >>> discussions with Tianran a question has come up.
> >>>
> >>> In section 2 you have a nice definition of Network Service YANG
> >>> Modules and this definition maps nicely to our definition of "service
> delivery models".
> >>> Furthermore, your figure 1 shows Network Service YANG Modules on the
> >>> interface between OSS/BSS and the various network services.
> >>>
> >>> We have further defined "customer service models" at a higher layer
> >>> still. That is, on the interface to the customer. This (of course?)
> >>> assumes that the OSS/BSS is not customer code :-)
> >>>
> >>> However, your discussion of Network Service YANG Modules in section
> >>> 2.1 seems slightly at odds, although this may be just ambiguity.
> >>>
> >>> For example, when you say, "Network Service YANG Modules describe
> >>> the characteristics of a service, as agreed upon with consumers of that
> service,"
> >>> this is not the same as, "This model is used in the discussion
> >>> between a customer and a service provide to describe the characteristics
> of a service."
> >>> That is, the former case could be arrived at after processing based
> >>> on the latter case - processing that we have called "service
> >>> orchestration" but might (of course) be what leads to the operator poking
> the OSS/BSS.
> >>
> >> Adrian, I can see the ambiguity. The point of service module is to be
> >> consumed by the customer and there can be some modifications of the
> >> service module to adapt to the customer specifics.
> >
> > So far I agree with your email and therefore not with your document. The
> OSS/BSS is not, IMHO, a tool used by the customer.
> >
> > Please see Figure 3 in draft-wu-opsawg-service-model-explained-05.txt
> that shows the customer distinct from the OSS/BSS.
> 
>  IMHO figure 3 in the draft is what it says, an _example_ of a set of
> relationships between the constituent parts of a provisioning/activation
> system.
> 
>  In all real-world applications, customers are several layers above the
> “service orchestrator” and adjacent systems. But the YANG model nevertheless
> serves the purpose of describing the structure of the service for customer
> (outside the SP) or other consuming parties (e.g. the OSS/BSS teams).
> 
> >>> This might all be fine and good, but later in the same section you
> >>> say "Network Service YANG Modules define service models to be
> >>> consumed by external systems.
> >>> These modules are commonly designed, developed and deployed by
> >>> network infrastructure teams." And there you introduce two terms
> >>> that are previously undefined and only server to add ambiguity.
> >>> Specifically "external to what?" I could make and