Re: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-02.txt

2022-01-21 Thread tom petch 
From: OPSAWG  on behalf of Wubo (lana) 

Sent: 20 January 2022 03:24


Hi WG,

Many thanks to the WG for the discussion and valuable comments.

This update mainly reflects the discussion decision of the 112 meeting and also 
the comments of Adrian and Greg on the mailing list.


Some possible glitches for you.

Some of the lines in the YANG module are too long (they were ok in -01)

You use  to refer to two different I-D (this was ok in -01)

Abbreviations need expanding, perhaps in Terminology e.g. VPLS OWAMP L3VPN

I want references in the YANG module for OWAMP IPDV P

ITU-T Y.1731 would benefit from a title and needs adding to the I-D References

five fraction digits for a percentile?  I note that the defaults have only two 
digits

/http:/https:/
TLP is out of date

percentile definition seems not quite right.  You are using a percentage here 
but there is no requirement to do so - it can be an integer count or any other 
measurement of a proportion

'middle-delay' I think confusing; sounds too much like it is the median or 
mode; perhaps medium?

time when statistics are collected; start time, end time, duration of interval?

subnetwork (broadcast, multicast) I find unclear - sub which layer of our 
current network many-layered stacks.

Tom Petch

The detailed changes are the following:
1. Adds modeling considerations to the introduction
2. Adds a reference to draft-ietf-netmod-node-tags
3. YANG: Replaces the type of "pm-source”: string' -> 'identity'
4. YANG: Adds "vpn-one-way-pm-statistics* [class-id]" to collect class-based 
VPN underlay tunnel statistics
5. YANG: Adds “vpn-network-access” specific counters under " termination-point"
6. YANG: Highlights the unidirectional link metrics with " 
one-way-pm-statistics"
7. Fixed a lot of editorial issues

Here is the diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-02.

Thanks,
Bo

> -邮件原件-
> 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表
> internet-dra...@ietf.org
> 发送时间: 2022年1月20日 10:50
> 收件人: i-d-annou...@ietf.org
> 抄送: opsawg@ietf.org
> 主题: [OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Operations and Management Area Working
> Group WG of the IETF.
>
> Title   : A YANG Model for Network and VPN Service
> Performance Monitoring
> Authors : Bo Wu
>   Qin Wu
>   Mohamed Boucadair
>   Oscar Gonzalez de Dios
>   Bin Wen
>   Filename: draft-ietf-opsawg-yang-vpn-service-pm-02.txt
>   Pages   : 35
>   Date: 2022-01-19
>
> Ab
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

2022-01-21 Thread Qin Wu 
Thanks Dhruv for valuable review, see reply inline below.

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Dhruv Dhody
发送时间: 2022年1月19日 20:40
收件人: Tianran Zhou 
抄送: opsawg@ietf.org; opsawg-cha...@ietf.org
主题: Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi Tianran,

I have read the I-D and I support its adoption.

Few comments -

1) Figure 1 uses the term "Service Network Models" which is not defined and not 
aligned to RFC 8309.
[Qin Wu]  I think it is referred to network configuration models since it sits 
on top of controller described in figure 3 of RFC8309. But I am not sure 
RFC8309 is better reference  since RFC8309 introducse layered SDN architecture 
and split orchestrator into service orchestrator and network orchestrator which 
intends to align with MEF SLO project.
I suggest we can align with RFC8969 instead, which use the term “network model” 
and reduce confusion when the number of layers in our targeted architecture is 
different from on described in figure 3 of RFC8309.
2) Is the attachment-id the key via which the SAP is linked to the physical 
topology? More text on this would be useful.
[Qin Wu] Yes the attachment-id is the key for service-attachment –point list 
which can mapped to the specific port in the physical topology, yes, we can 
make this clear in the update.

3) Consider adding an example (JSON or XML) of how this model would be used 
alongside L3SM.
[Qin Wu] Good suggestion and will add.

4) Can SAP be used for NNI? Some clarification would be nice!
[Qin Wu] Yes, I think we cover NNI use case, see the text in the introduction
“
With the help of
   other data models (e.g., L3SM 
[RFC8299] or L2SM 
[RFC8466]),
   hierarchical control elements could determine the feasibility of an
   end-to-end IP connectivity or L2VPN connectivity and therefore derive
   the sequence of domains and the points of interconnection to use.

”
I think the point of interconnection can be exposed attachment point in the NNI 
case.

Thanks!
Dhruv

On Wed, Jan 5, 2022 at 7:42 AM Tianran Zhou 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi WG,

I assume most of you are back to work.
Hope you had a good holiday.

As a follow up action after IETF 111, this mail starts a working group adoption 
call for draft-dbwb-opsawg-sap-00.
https://datatracker.ietf.org/doc/draft-dbwb-opsawg-sap/

This document defines a YANG data model for representing an abstract view of 
the provider network topology containing the points from which its services can 
be attached (e.g., basic connectivity, VPN, network slices).

Please review and comment.
We will conclude this adoption call after two weeks.

Cheers,
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] WG Adoption Call for draft-dbwb-opsawg-sap-00

2022-01-21 Thread Qin Wu 
Thanks Bo, I believe Dhruv asked the similar question as you raised.
Yes, I think interconnection point in end to end connectivity spanning across 
multiple domains can be saps.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Wubo (lana)
发送时间: 2022年1月19日 22:27
收件人: Tianran Zhou ; opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi Tianran, all,

I support the adoption. I have read the draft. The draft is a necessary piece 
to realize L3SM, L2SM, and network slice services.

I have one clarification comment. The introduction says that the SAP model can 
be used together with the service model to derive the interconnection points in 
a multi-domain scenario. Are the interconnection points are also SAPs?

Best regards,
Bo
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2022年1月5日 10:12
收件人: opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi WG,

I assume most of you are back to work.
Hope you had a good holiday.

As a follow up action after IETF 111, this mail starts a working group adoption 
call for draft-dbwb-opsawg-sap-00.
https://datatracker.ietf.org/doc/draft-dbwb-opsawg-sap/

This document defines a YANG data model for representing an abstract view of 
the provider network topology containing the points from which its services can 
be attached (e.g., basic connectivity, VPN, network slices).

Please review and comment.
We will conclude this adoption call after two weeks.

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

[OPSAWG] Conclusion//RE: WG Adoption Call for draft-dbwb-opsawg-sap-00

2022-01-21 Thread Tianran Zhou 
Hi WG,

Thanks very much for your comments and contributions.
We conclude the adoption call of this draft.
We see sufficient supports and interests. There is no objection.
So the OPSAWG will adopt this draft.
The authors please rename the draft to draft-ietf-opsawg-sap-00, and upload.
The authors please incorporate the suggestions during the call in the later 
revision.


Cheers,
Tianran, as co-chair

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, January 5, 2022 10:12 AM
To: opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi WG,

I assume most of you are back to work.
Hope you had a good holiday.

As a follow up action after IETF 111, this mail starts a working group adoption 
call for draft-dbwb-opsawg-sap-00.
https://datatracker.ietf.org/doc/draft-dbwb-opsawg-sap/

This document defines a YANG data model for representing an abstract view of 
the provider network topology containing the points from which its services can 
be attached (e.g., basic connectivity, VPN, network slices).

Please review and comment.
We will conclude this adoption call after two weeks.

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

Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

2022-01-21 Thread Dhruv Dhody 
Hi Qin,

On Fri, Jan 21, 2022 at 6:05 PM Qin Wu  wrote:

> Thanks Dhruv for valuable review, see reply inline below.
>
>
>
> *发件人:* OPSAWG [mailto:opsawg-boun...@ietf.org] *代表 *Dhruv Dhody
> *发送时间:* 2022年1月19日 20:40
> *收件人:* Tianran Zhou 
> *抄送:* opsawg@ietf.org; opsawg-cha...@ietf.org
> *主题:* Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00
>
>
>
> Hi Tianran,
>
> I have read the I-D and I support its adoption.
>
> Few comments -
>
> 1) Figure 1 uses the term "Service Network Models" which is not defined
> and not aligned to RFC 8309.
>
> [Qin Wu]  I think it is referred to network configuration models since it
> sits on top of controller described in figure 3 of RFC8309. But I am not
> sure RFC8309 is better reference  since RFC8309 introducse layered SDN
> architecture and split orchestrator into service orchestrator and network
> orchestrator which intends to align with MEF SLO project.
> I suggest we can align with RFC8969 instead, which use the term “network
> model” and reduce confusion when the number of layers in our targeted
> architecture is different from on described in figure 3 of RFC8309.
>

Dhruv: Works for me!



> 2) Is the attachment-id the key via which the SAP is linked to the
> physical topology? More text on this would be useful.
>
> [Qin Wu] Yes the attachment-id is the key for service-attachment –point
> list which can mapped to the specific port in the physical topology, yes,
> we can make this clear in the update.
>
>
> 3) Consider adding an example (JSON or XML) of how this model would be
> used alongside L3SM.
>
> [Qin Wu] Good suggestion and will add.
>
>
> 4) Can SAP be used for NNI? Some clarification would be nice!
> [Qin Wu] Yes, I think we cover NNI use case, see the text in the
> introduction
>
> “
>
> With the help of
>
>other data models (e.g., L3SM [RFC8299
> ] or L2SM [RFC8466
> ]),
>
>hierarchical control elements could determine the feasibility of an
>
>end-to-end IP connectivity or L2VPN connectivity and therefore derive
>
>the sequence of domains and the points of interconnection to use.
>
>
>
> ”
>
> I think the point of interconnection can be exposed attachment point in
> the NNI case.
>
>
>
Dhruv: In that case, what would be the sap-type is not clear to me. Maybe
we need a new type for this and perhaps a figure that also describes this
case.

Thanks!
Dhruv



> Thanks!
> Dhruv
>
>
>
> On Wed, Jan 5, 2022 at 7:42 AM Tianran Zhou  40huawei@dmarc.ietf.org> wrote:
>
> Hi WG,
>
>
>
> I assume most of you are back to work.
>
> Hope you had a good holiday.
>
>
>
> As a follow up action after IETF 111, this mail starts a working group
> adoption call for draft-dbwb-opsawg-sap-00.
>
> https://datatracker.ietf.org/doc/draft-dbwb-opsawg-sap/
>
>
>
> This document defines a YANG data model for representing an abstract view
> of the provider network topology containing the points from which its
> services can be attached (e.g., basic connectivity, VPN, network slices).
>
>
>
> Please review and comment.
>
> We will conclude this adoption call after two weeks.
>
>
>
> Cheers,
>
> 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