Re: [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Randy Bush]

robin,

> It is not described clearly in the draft that reusing BMP is also a
> possible option for monitoring IGP. We will refine the draft.  

if i could also use bmp for monitoring dns, smtp, and ntp, i could
stop using nagios!

i think what acee is trying to say is that "B" in BMP does not stand
for Bypass.

randy

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Acee Lindem (acee)]

Hi Robin, 

I know for a fact that there have been applications written that do passive 
monitoring using IS-IS and simply advertising yourself in overload mode. 
Additionally, given that all routes in an area have the same LSDB, you don't 
really have the same requirements as BGP. 

With respect to scalability, I believe the advantage of the YANG models is more 
in terms of consumption and having a single network programmability paradigm 
rather unique per-protocol monitoring. Additionally, YANG, NETCONF, RESTCONF, 
gNMI, and streaming telemetry are happening now irrespective of your proposal. 

I agree that a custom protocol will result in fewer bits on the wire and 
potentially less processing on the network device. However, I certainly don't 
believe that this alone is a reason to do it. 

Thanks,
Acee 


On 7/5/18, 6:49 AM, "GROW on behalf of Lizhenbin"  wrote:

Hi Jeff,
Before we propose the NMP idea, we carefully compared it with the existing 
NETCONF, gRPC and YANG models work:
1. Based on my experience in the YANG model work, it may be not 
satisfactory for these models does not define config/oper of all features of 
specific protocol and these models have much relation with each other and it is 
difficult to stabilize the definition.
2. For monitoring the control protocol, it is not enough based on the 
existing YANG models such as the packets of control protocol which should be 
monitored but not defined in YANG models. 
3. Performance concern on the existing NETCONF.
4. Standardization of the existing gRPC.

We would like to define the NMP based on the usecases. That is, a specific 
set of parameters exported by NMP can satisfy the purpose of a specific 
usecase. Thus the protocol can be deployed incrementally.


Best Regards,
Robin



-Original Message-
From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] 
Sent: Wednesday, July 04, 2018 5:15 AM
To: Acee Lindem (acee) ; Lizhenbin 
; grow@ietf.org; ops...@ietf.org
Cc: l...@ietf.org; rt...@ietf.org; Guyunan (Yunan Gu, IP Technology 
Research Dept. NW) 
Subject: Re: [Lsr] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Robin,

Pretty much same comment as Acee - I'm not clear as to why...
Protocol YANG models developed in the last years clearly provide much 
better and more scalable approach to what has been proposed in the draft, since 
we are talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg. 
How do you propose to corelate operational state to configuration?

gRPC provides high performance RPC framework  to streaming the telemetry 
data that is structured, easy to consume and extend. 

I'm not going to go into technical discussion, however would appreciate 
your response as to why NMP (please do not restate the points in the section 4 
of the draft, they are quite incorrect) 

Thanks!

Cheers,
Jeff

On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)" 
 wrote:

Hi Robin, 
I'm not arguing to deprecate BMP. What I am arguing is that the fact 
that BMP was created 15 years ago doesn't necessarily mean we should create an 
analogous IMP for IS-IS given the current IETF OPS technologies and the fact 
that faster link speeds and Moore's law facilitate deployment of these new OPS 
technologies. Anyway, I looked at the agenda and I will definitely attend GROW 
on Wednesday afternoon for the discussion. 
Thanks,
Acee 

On 7/3/18, 6:40 AM, "Lizhenbin"  wrote:

Hi Acee,
Thank for your attention to the new draft. Please refer to my reply 
inline.

Best Regards,
Robin



-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
Sent: Monday, July 02, 2018 9:24 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; grow@ietf.org; ops...@ietf.org
Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Hi Yunan, Shunwan, and Zhenbin, 

What are the advantages of inventing a new protocol over just using 
YANG and NETCONF, RESTCONF, or gNMI? 
[Robin] In the draft we simply mention the difference between NMP 
and protocols you mentioned for the management plane. Though there is maybe 
some overlap between the two types of protocols, the protocols you mentioned is 
not enough for monitoring the control protocol. For example, would we like to 
use YANG and NETCONF, RESTCONF, or gNMI to export the packets of control 
protocols such as update message of BGP and/or ISIS PDU, etc. for the purpose 
of monitoring?


Operators and vendors are doing 

Re: [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Acee Lindem (acee)]

Hi Robin, 

On 7/5/18, 6:35 AM, "Lizhenbin"  wrote:

Hi Acee,
It is not described clearly in the draft that reusing BMP is also a 
possible option for monitoring IGP. We will refine the draft. 

It doesn't matter where you put it, it is still an alternate paradigm for IS-IS 
management. 

Expect to have more discussion with you in IETF 102.

I'm sure we will. I really don't think this meets the "stick to the wall" test 
for GROW. 

Thanks,
Acee 


Thanks,
Robin





-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Wednesday, July 04, 2018 12:09 AM
To: Lizhenbin ; grow@ietf.org; ops...@ietf.org
Cc: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; l...@ietf.org; rt...@ietf.org
Subject: Re: [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Hi Robin, 
I'm not arguing to deprecate BMP. What I am arguing is that the fact that 
BMP was created 15 years ago doesn't necessarily mean we should create an 
analogous IMP for IS-IS given the current IETF OPS technologies and the fact 
that faster link speeds and Moore's law facilitate deployment of these new OPS 
technologies. Anyway, I looked at the agenda and I will definitely attend GROW 
on Wednesday afternoon for the discussion. 
Thanks,
Acee 

On 7/3/18, 6:40 AM, "Lizhenbin"  wrote:

Hi Acee,
Thank for your attention to the new draft. Please refer to my reply 
inline.

Best Regards,
Robin



-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Acee Lindem 
(acee)
Sent: Monday, July 02, 2018 9:24 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; grow@ietf.org; ops...@ietf.org
Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Hi Yunan, Shunwan, and Zhenbin, 

What are the advantages of inventing a new protocol over just using 
YANG and NETCONF, RESTCONF, or gNMI? 
[Robin] In the draft we simply mention the difference between NMP and 
protocols you mentioned for the management plane. Though there is maybe some 
overlap between the two types of protocols, the protocols you mentioned is not 
enough for monitoring the control protocol. For example, would we like to use 
YANG and NETCONF, RESTCONF, or gNMI to export the packets of control protocols 
such as update message of BGP and/or ISIS PDU, etc. for the purpose of 
monitoring?


Operators and vendors are doing this anyway. A second alternative would 
be to listen passively in IS-IS (or OSPF for that matter). Why would anyone 
want this? 
[Robin] In fact we tried the method you proposed. From our point of 
view, the basic design principle should be that the monitoring entity should be 
decoupled from the monitored entity. This is to avoid following cases:
1. The failure of operation of the control protocol may affect the 
monitoring at the same time.
2. The limitation of the control protocol will also have effect on the 
monitoring. For example, for the method of listening passively, if there are 
multiple hops between the listener and the network devices, it has to set up a 
tunnel as the virtual link for direct connection. But the TCP-based monitoring 
protocol need not care about it. 


As far as where it belongs, we have a rather full agenda in LSR so I 
don't think we want to devote time to it there at IETF 102.  
[Robin] Though the WG the draft should belong to is not determined yet, 
we think the work belongs to OPS area and send the notice to GROW WG and 
OPSAWG. We also applied for the presentation in the two WGs. We should have 
copied the notice to the related WGs of RTG area. So the LSR WG and RTGWG WG 
mailing list are added. More comments and suggestions are welcome.

Thanks,
Acee



On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology 
Research Dept. NW)"  
wrote:

Dear GROW & OPSAWG WGs,

We have proposed a Network Monitoring Protocol (NMP) for the 
control plane OAM. NMP for ISIS is illustrated in this draft to showcase the 
benefit and operation of NMP. Yet, we haven't decided which WG it belongs to. 

   
Comments and suggestions are very welcome! 

Thank you!


Yunan Gu
Huawei Technologies Co. Ltd

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: 2018年7月2日 20:07
To: Zhuangshunwan ; Lizhenbin 
; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 

Subject: New Versio

Re: [GROW] Call for IETF 102 agenda items

[Zhuangshunwan]

Dear Chairs,

I request 15 minutes to present 
draft-gu-grow-bmp-vpn-label-00 & draft-zhuang-grow-monitoring-bgp-parameters-00

Thanks,
Shunwan

-邮件原件-
发件人: GROW [mailto:grow-boun...@ietf.org] 代表 Job Snijders
发送时间: 2018年6月12日 1:21
收件人: GROW List ; Christopher Morrow 

主题: [GROW] Call for IETF 102 agenda items

Hi Folks!

GROW is planning to meet in Canada at IETF 102, iff we have agenda items. 
People who would like time on the agenda please send a request so that a time 
slot and agenda can be prepared!

Presentation proposals with drafts will have priority over talks without an 
uploaded draft.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [OPSAWG] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Einar Nilsen-Nygaard (einarnn)]

Robin,

With respect to your points below:


  *   #1 – The draft ISIS model doesn’t seem to have many lateral dependencies 
as far as I can see. And if it is incomplete from the perspective of monitoring 
the health of ISIS, then it should be extended. I’m not sure why it would be 
difficult to stabilise the definition?
  *   #2 – This seems to be the same issue of an incomplete model. Can you 
clearly articulate any data that you think should be available that cannot be 
modelled in YANG?
  *   #3 – Agreed that exporting high volume, low latency telemetry one the 
baseline transport suggested in ietf-netconf-yang-push would perhaps have 
issues. This is one of the reasons why transport extensibility is an explicit 
part of the draft.
  *   #4 – IMO, as long as the encoding for data is clearly defined in an 
"open" way, then this is not really an issue yet. I still think we need to 
experiment with encodings, but I do not think an entirely new protocol will 
serve network operators.

I’d also like to add to the last point and say that I do not think adding new 
protocols and new encodings will serve network operators well. Over the last 
few years operators have been making it clear that they want to simplify their 
interactions with the network, and not have more things they need to understand 
thrown at them. Acee isn’t suggesting deprecating BMP, and neither am I, but in 
at least two discussions with operators I have attended, when introduced to 
BMP, their initial reaction could be summarised as "this looks interesting, but 
why have you introduced another protocol for this?"

I completely support identifying the use cases you have, but would really like 
to see us focus on rectifying any deficiencies we can identify with existing 
proposals, rather than dilute our efforts.

Cheers,

Einar

On 5 Jul 2018, at 11:48, Lizhenbin 
mailto:lizhen...@huawei.com>> wrote:

Hi Jeff,
Before we propose the NMP idea, we carefully compared it with the existing 
NETCONF, gRPC and YANG models work:
1. Based on my experience in the YANG model work, it may be not satisfactory 
for these models does not define config/oper of all features of specific 
protocol and these models have much relation with each other and it is 
difficult to stabilize the definition.
2. For monitoring the control protocol, it is not enough based on the existing 
YANG models such as the packets of control protocol which should be monitored 
but not defined in YANG models.
3. Performance concern on the existing NETCONF.
4. Standardization of the existing gRPC.

We would like to define the NMP based on the usecases. That is, a specific set 
of parameters exported by NMP can satisfy the purpose of a specific usecase. 
Thus the protocol can be deployed incrementally.


Best Regards,
Robin



-Original Message-
From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Wednesday, July 04, 2018 5:15 AM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
Lizhenbin mailto:lizhen...@huawei.com>>; 
grow@ietf.org; ops...@ietf.org
Cc: l...@ietf.org; rt...@ietf.org; 
Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
mailto:guyu...@huawei.com>>
Subject: Re: [Lsr] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Robin,

Pretty much same comment as Acee - I'm not clear as to why...
Protocol YANG models developed in the last years clearly provide much better 
and more scalable approach to what has been proposed in the draft, since we are 
talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg. How do 
you propose to corelate operational state to configuration?

gRPC provides high performance RPC framework  to streaming the telemetry data 
that is structured, easy to consume and extend.

I'm not going to go into technical discussion, however would appreciate your 
response as to why NMP (please do not restate the points in the section 4 of 
the draft, they are quite incorrect)

Thanks!

Cheers,
Jeff

On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)" 
mailto:lsr-boun...@ietf.org> on behalf of 
acee=40cisco@dmarc.ietf.org> wrote:

   Hi Robin,
   I'm not arguing to deprecate BMP. What I am arguing is that the fact that 
BMP was created 15 years ago doesn't necessarily mean we should create an 
analogous IMP for IS-IS given the current IETF OPS technologies and the fact 
that faster link speeds and Moore's law facilitate deployment of these new OPS 
technologies. Anyway, I looked at the agenda and I will definitely attend GROW 
on Wednesday afternoon for the discussion.
   Thanks,
   Acee

   On 7/3/18, 6:40 AM, "Lizhenbin" 
mailto:lizhen...@huawei.com>> wrote:

   Hi Acee,
   Thank for your attention to the new draft. Please refer to my reply 
inline.

   Best Regards,
   Robin



   -Original Message-
   From: OPSAW

Re: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Lizhenbin]

Hi Jeff,
Before we propose the NMP idea, we carefully compared it with the existing 
NETCONF, gRPC and YANG models work:
1. Based on my experience in the YANG model work, it may be not satisfactory 
for these models does not define config/oper of all features of specific 
protocol and these models have much relation with each other and it is 
difficult to stabilize the definition.
2. For monitoring the control protocol, it is not enough based on the existing 
YANG models such as the packets of control protocol which should be monitored 
but not defined in YANG models. 
3. Performance concern on the existing NETCONF.
4. Standardization of the existing gRPC.

We would like to define the NMP based on the usecases. That is, a specific set 
of parameters exported by NMP can satisfy the purpose of a specific usecase. 
Thus the protocol can be deployed incrementally.


Best Regards,
Robin



-Original Message-
From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] 
Sent: Wednesday, July 04, 2018 5:15 AM
To: Acee Lindem (acee) ; Lizhenbin 
; grow@ietf.org; ops...@ietf.org
Cc: l...@ietf.org; rt...@ietf.org; Guyunan (Yunan Gu, IP Technology Research 
Dept. NW) 
Subject: Re: [Lsr] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Robin,

Pretty much same comment as Acee - I'm not clear as to why...
Protocol YANG models developed in the last years clearly provide much better 
and more scalable approach to what has been proposed in the draft, since we are 
talking is-is - look at notifications in draft-ietf-isis-yang-isis-cfg. How do 
you propose to corelate operational state to configuration?

gRPC provides high performance RPC framework  to streaming the telemetry data 
that is structured, easy to consume and extend. 

I'm not going to go into technical discussion, however would appreciate your 
response as to why NMP (please do not restate the points in the section 4 of 
the draft, they are quite incorrect) 

Thanks!

Cheers,
Jeff

On 7/3/18, 09:21, "Lsr on behalf of Acee Lindem (acee)"  wrote:

Hi Robin, 
I'm not arguing to deprecate BMP. What I am arguing is that the fact that 
BMP was created 15 years ago doesn't necessarily mean we should create an 
analogous IMP for IS-IS given the current IETF OPS technologies and the fact 
that faster link speeds and Moore's law facilitate deployment of these new OPS 
technologies. Anyway, I looked at the agenda and I will definitely attend GROW 
on Wednesday afternoon for the discussion. 
Thanks,
Acee 

On 7/3/18, 6:40 AM, "Lizhenbin"  wrote:

Hi Acee,
Thank for your attention to the new draft. Please refer to my reply 
inline.

Best Regards,
Robin



-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Acee Lindem 
(acee)
Sent: Monday, July 02, 2018 9:24 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; grow@ietf.org; ops...@ietf.org
Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Hi Yunan, Shunwan, and Zhenbin, 

What are the advantages of inventing a new protocol over just using 
YANG and NETCONF, RESTCONF, or gNMI? 
[Robin] In the draft we simply mention the difference between NMP and 
protocols you mentioned for the management plane. Though there is maybe some 
overlap between the two types of protocols, the protocols you mentioned is not 
enough for monitoring the control protocol. For example, would we like to use 
YANG and NETCONF, RESTCONF, or gNMI to export the packets of control protocols 
such as update message of BGP and/or ISIS PDU, etc. for the purpose of 
monitoring?


Operators and vendors are doing this anyway. A second alternative would 
be to listen passively in IS-IS (or OSPF for that matter). Why would anyone 
want this? 
[Robin] In fact we tried the method you proposed. From our point of 
view, the basic design principle should be that the monitoring entity should be 
decoupled from the monitored entity. This is to avoid following cases:
1. The failure of operation of the control protocol may affect the 
monitoring at the same time.
2. The limitation of the control protocol will also have effect on the 
monitoring. For example, for the method of listening passively, if there are 
multiple hops between the listener and the network devices, it has to set up a 
tunnel as the virtual link for direct connection. But the TCP-based monitoring 
protocol need not care about it. 


As far as where it belongs, we have a rather full agenda in LSR so I 
don't think we want to devote time to it there at IETF 102.  
[Robin] Though the WG the draft should belong to is not determined yet, 
we think the work belongs to OPS area and send the notice to GROW WG and 
OPSAWG. We also

Re: [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Lizhenbin]

Hi Acee,
It is not described clearly in the draft that reusing BMP is also a possible 
option for monitoring IGP. We will refine the draft. 
Expect to have more discussion with you in IETF 102.


Thanks,
Robin





-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Wednesday, July 04, 2018 12:09 AM
To: Lizhenbin ; grow@ietf.org; ops...@ietf.org
Cc: Guyunan (Yunan Gu, IP Technology Research Dept. NW) ; 
l...@ietf.org; rt...@ietf.org
Subject: Re: [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Hi Robin, 
I'm not arguing to deprecate BMP. What I am arguing is that the fact that BMP 
was created 15 years ago doesn't necessarily mean we should create an analogous 
IMP for IS-IS given the current IETF OPS technologies and the fact that faster 
link speeds and Moore's law facilitate deployment of these new OPS 
technologies. Anyway, I looked at the agenda and I will definitely attend GROW 
on Wednesday afternoon for the discussion. 
Thanks,
Acee 

On 7/3/18, 6:40 AM, "Lizhenbin"  wrote:

Hi Acee,
Thank for your attention to the new draft. Please refer to my reply inline.

Best Regards,
Robin



-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Acee Lindem 
(acee)
Sent: Monday, July 02, 2018 9:24 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; grow@ietf.org; ops...@ietf.org
Subject: Re: [OPSAWG] [GROW] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Hi Yunan, Shunwan, and Zhenbin, 

What are the advantages of inventing a new protocol over just using YANG 
and NETCONF, RESTCONF, or gNMI? 
[Robin] In the draft we simply mention the difference between NMP and 
protocols you mentioned for the management plane. Though there is maybe some 
overlap between the two types of protocols, the protocols you mentioned is not 
enough for monitoring the control protocol. For example, would we like to use 
YANG and NETCONF, RESTCONF, or gNMI to export the packets of control protocols 
such as update message of BGP and/or ISIS PDU, etc. for the purpose of 
monitoring?


Operators and vendors are doing this anyway. A second alternative would be 
to listen passively in IS-IS (or OSPF for that matter). Why would anyone want 
this? 
[Robin] In fact we tried the method you proposed. From our point of view, 
the basic design principle should be that the monitoring entity should be 
decoupled from the monitored entity. This is to avoid following cases:
1. The failure of operation of the control protocol may affect the 
monitoring at the same time.
2. The limitation of the control protocol will also have effect on the 
monitoring. For example, for the method of listening passively, if there are 
multiple hops between the listener and the network devices, it has to set up a 
tunnel as the virtual link for direct connection. But the TCP-based monitoring 
protocol need not care about it. 


As far as where it belongs, we have a rather full agenda in LSR so I don't 
think we want to devote time to it there at IETF 102.  
[Robin] Though the WG the draft should belong to is not determined yet, we 
think the work belongs to OPS area and send the notice to GROW WG and OPSAWG. 
We also applied for the presentation in the two WGs. We should have copied the 
notice to the related WGs of RTG area. So the LSR WG and RTGWG WG mailing list 
are added. More comments and suggestions are welcome.

Thanks,
Acee



On 7/2/18, 8:20 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology 
Research Dept. NW)"  
wrote:

Dear GROW & OPSAWG WGs,

We have proposed a Network Monitoring Protocol (NMP) for the control 
plane OAM. NMP for ISIS is illustrated in this draft to showcase the benefit 
and operation of NMP. Yet, we haven't decided which WG it belongs to. 

   
Comments and suggestions are very welcome! 

Thank you!


Yunan Gu
Huawei Technologies Co. Ltd

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: 2018年7月2日 20:07
To: Zhuangshunwan ; Lizhenbin 
; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 

Subject: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt


A new version of I-D, draft-gu-network-mornitoring-protol-00.txt
has been successfully submitted by Yunan Gu and posted to the IETF 
repository.

Name:   draft-gu-network-mornitoring-protol
Revision:   00
Title:  Network Monitoring Protocol (NMP)
Document date:  2018-07-02
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/internet-drafts/draft-gu-ne