Re: [Lsr] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

2018-07-05 Thread Ketan Talaulikar (ketant)
Hi Xiaohu,

The IGP drafts define MSD as a framework that enable advertisements for various 
type of SID limits – starting with the Base MSD Type – 1. You are referring to 
this generic construct of MSD in the text you quote below. It is, however, the 
Base MSD (type 1) which is aligned with the definition in PCEP-SR.

IMHO the PCEP-SR draft definition should be updated to refer to this base MSD 
type.

Thanks,
Ketan

From: mpls  On Behalf Of ???(??)
Sent: 06 July 2018 06:55
To: Jeff Tantsura ; stephane.litkowski 
; m...@ietf.org
Cc: lsr@ietf.org; p...@ietf.org
Subject: Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi Jeff,

Thanks for your clarification. IMHO, no matter the MSD information is provided 
by whatever protocol, the semantics of the MSD itself should be unified in the 
IETF community. Otherwise, it would introduce unnecessary confusion to 
implementors and operators.

It said in the OSPF-MSD draft:
"

   MSD: Maximum SID Depth - the number of SIDs a node or one of its

   links can support"



What does the "support" exactly mean? It seems at least to me a little bit 
ambiguous compared to the MSD concept as defined in the PCEP-SR draft.



Best regards,

Xiaohu




--
From:Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Send Time:2018年7月6日(星期五) 07:48
To:stephane.litkowski 
mailto:stephane.litkow...@orange.com>>; 徐小虎(义先) 
mailto:xiaohu@alibaba-inc.com>>; 
m...@ietf.org mailto:m...@ietf.org>>
Cc:lsr@ietf.org mailto:lsr@ietf.org>>; 
p...@ietf.org mailto:p...@ietf.org>>
Subject:Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label

Hi,

Please see inline (MSD section).
Hope this clarifies, thanks!

Cheers,
Jeff



[jeff] both IGP drafts have identical description of the BMI-MSD:
“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a 
node is capable of imposing, including all service/transport/special labels.”
PCEP draft supports only a subset of overall MSD functionality and in general 
it is expected that this info would come from IGPs(BGP-LS).
However the functoriality provided by PCEP is inline with the  BMI-MSD 
definition in the IGP drafts, at the node granularity only though.


3. Section 5 introduces the MSD concept. I wonder whether this concept is 
aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept 
as defined in the IGP-MSD draft. In PCEP-SR draft, it said "

The "Maximum SID Depth" (1

   octet) field (MSD) specifies the maximum number of SIDs (MPLS label

   stack depth in the context of this document) that a PCC is capable of

   imposing on a packet.



In the IGP-MSD draft, it said "

MSD of type 1 (IANA Registry), called Base MSD is used to signal the

   total number of SIDs a node is capable of imposing, to be used by a

   path computation element/controller.  "



If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR 
draft==the Base MSD (i.e., the MSD of type 1), No?

[SLI] Today, the two IGP drafts does not seem to agree on the definition

ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all
   service/transport/special labels.”

OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation
   element/controller and is only relevant to the part of the stack
   created as the result of the computation.”

MSD is just MSD is defines a maximum number of labels to be pushed. This is the 
definition we use and it is compliant with the one used in PCEP-SR:

“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in context of this document) that a PCC is capable of
   imposing on a packet.”

As we also say: “This includes any kind of labels (service, entropy, 
transport...).”, we are compliant with the BMI-MSD defined in IS-IS.



Best regards,
Xiaohu

_



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,

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, Orange is not 

Re: [Lsr] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

2018-07-05 Thread 徐小虎(义先)
Hi Jeff,

Thanks for your clarification. IMHO, no matter the MSD information is provided 
by whatever protocol, the semantics of the MSD itself should be unified in the 
IETF community. Otherwise, it would introduce unnecessary confusion to 
implementors and operators.

It said in the OSPF-MSD draft:
"
   MSD: Maximum SID Depth - the number of SIDs a node or one of its
   links can support"

What does the "support" exactly mean? It seems at least to me a little bit 
ambiguous compared to the MSD concept as defined in the PCEP-SR draft.

Best regards,
Xiaohu
 



--
From:Jeff Tantsura 
Send Time:2018年7月6日(星期五) 07:48
To:stephane.litkowski ; 徐小虎(义先) 
; m...@ietf.org 
Cc:lsr@ietf.org ; p...@ietf.org 
Subject:Re: [mpls] Comments on draft-ietf-mpls-spring-entropy-label


Hi,

Please see inline (MSD section).
Hope this clarifies, thanks!

Cheers,
Jeff



[jeff] both IGP drafts have identical description of the BMI-MSD:
“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a 
node is capable of imposing, including all service/transport/special labels.”
PCEP draft supports only a subset of overall MSD functionality and in general 
it is expected that this info would come from IGPs(BGP-LS).
However the functoriality provided by PCEP is inline with the  BMI-MSD 
definition in the IGP drafts, at the node granularity only though. 


3. Section 5 introduces the MSD concept. I wonder whether this concept is 
aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept 
as defined in the IGP-MSD draft. In PCEP-SR draft, it said "
The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in the context of this document) that a PCC is capable of
   imposing on a packet.
 
In the IGP-MSD draft, it said "
MSD of type 1 (IANA Registry), called Base MSD is used to signal the
   total number of SIDs a node is capable of imposing, to be used by a
   path computation element/controller.  "
 
If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR 
draft==the Base MSD (i.e., the MSD of type 1), No?

[SLI] Today, the two IGP drafts does not seem to agree on the definition
ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all
   service/transport/special labels.”
OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation
   element/controller and is only relevant to the part of the stack
   created as the result of the computation.”

MSD is just MSD is defines a maximum number of labels to be pushed. This is the 
definition we use and it is compliant with the one used in PCEP-SR:
“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in context of this document) that a PCC is capable of
   imposing on a packet.”

As we also say: “This includes any kind of labels (service, entropy, 
transport...).”, we are compliant with the BMI-MSD defined in IS-IS.



Best regards,
Xiaohu
_
 
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,
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, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___ mpls mailing list m...@ietf.org 
https://www.ietf.org/mailman/listinfo/mpls

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2018-07-05 Thread 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 
; g...@ietf.org; ops...@ietf.org
Cc: lsr@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) 
; g...@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: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

2018-07-05 Thread 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 ; g...@ietf.org; ops...@ietf.org
Cc: Guyunan (Yunan Gu, IP Technology Research Dept. NW) ; 
lsr@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) 
; g...@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: