Subject: [netmod] Comments on draft-tissa-netmod-oam-01

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 4 Jul 2014 17:08:47 +0000

Hi Tissa, authors,

First of all, intent of this document seems widely beneficial. I am interested to see how and In what form this document will progress.

Please find below few comments I have on the draft-tissa-netmod-oam-01, from a quick look at the document.

Comment #1: Section 6

[snip]
     typedef CCM-Interval {
       default "interval-1min";
       type enumeration {
         enum "interval-invalid" {
           value 0;
         }
         ...
         enum "interval-10min" {
           value 7;
         }
       }
       ...
     }
[snip]

When considering all OAM tools out there, defining a hard coded set of intervals (via enum) may not be a good idea. BFD implementations (SW/HW) springs to my mind immediately. For HW based BFD, BFD WG is working on an informational document for recommended set of intervals: draft-ietf-bfd-intervals. However, intervals outside of that set can still be implemented by vendors for HW based BFD. SW based BFD, obviously, has much more flexibility in the range of intervals to use. A better approach may be to change above from enum to identify ref (or something else) which can be augmented.

Comment #2: Section 6

[snip]
     typedef ecmp-choices {
       type enumeration {
         enum "ecmp-use-platform-hash" {
           value 0;
         }
         enum "ecmp-use-round-robin" {
           value 1;
         }
       }
     }
[snip]
                 leaf ecmp-choice {
                   config true;
                   type ecmp-choices;
                   description
                     "0 means use the specified interface
                      1 means use round robin";
                 }
[snip]

Above two seems a bit conflicting for the value of zero(0). Former states that zero(0) indicates usage of platform hash but the latter indicates that specific interface is used (i.e. not hashed?). Thinking about this, I believe "ecmp-choices" is overloaded. You actually want to be able to describe 3 different things here.

1. Configuring a specific load balancing technique on a system (ex: EL, round-robin or something else).
2. Describing the output behavior on the OAM instance (ex: out to specific interface vs. load balanced).
3. Describe the setting on the path discovery OAM instance (ex: LSP tree trace using multipath 2, 4, 8, 9, 10).

Perhaps a different object for each may be a good idea. (2) can be an enum but it'll be beneficial to be able for various OAM tools to augment (1) and (3).

Comment #3: Section 6

[snip]
     typedef oam-counter32 {
       type yang:zero-based-counter32;
       description
         "defines 32 bit counter for OAM";
     }
[snip]

No 64 bit counter?

Thanks!

-Nobo

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 7 Jul 2014 15:16:15 +0000

Hi Nobo

Thanks for the comments, please see in-line

-----Original Message-----
From: Nobo Akiya (nobo) 
Sent: Friday, July 04, 2014 10:09 AM
To: Tissa Senevirathne (tsenevir)
Cc: [email-masked]
Subject: Comments on draft-tissa-netmod-oam-01

Hi Tissa, authors,

Comment #1: Section 6

[snip]
     typedef CCM-Interval {
       default "interval-1min";
       type enumeration {

[Answer] good point shall update in the next revision

Comment #2: Section 6

[snip]
     typedef ecmp-choices {
       type enumeration {

Perhaps a different object for each may be a good idea. (2) can be an enum but it'll be beneficial to be able for various OAM tools to augment (1) and (3).
[Answer] agree on #1 and #2, let me think how to  best bring that in into the next revisions. #3 is part of flow-entropy discovery, which is independent of how it is treated. Way it is done is to have each of the technology to have its specific way of ECMP discovery, which is more like an RPC command. In the base YANG model, use can populate the flow entropy why XML imterface and #1 and #2 will dictates the behavior.

Comment #3: Section 6

[snip]
     typedef oam-counter32 {

No 64 bit counter?

[Answer] most counters in CFM are 32 bit hence taken this. But we can extend to 64 bit very easily. We can consider for next revision making the counters 64 bit.

Thanks!

-Nobo

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Jul 2014 17:28:49 +0200

> [Answer] most counters in CFM are 32 bit hence taken this. But we can extend to 64 bit very easily. We can consider for next revision making the counters 64 bit.

But what is the value of this typedef? Why introduce oam-counter32 if
it is exactly yang:zero-based-counter32?

/js

PS: It has been good practice to consider roll-over time while
    deciding whether between 32-bit and 64-bit counters. Making all
    counter 64-bit may be as wrong as making all counters 32-bit.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 7 Jul 2014 15:32:44 +0000

See in line

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, July 07, 2014 8:29 AM
To: Tissa Senevirathne (tsenevir)
Cc: Nobo Akiya (nobo); [email-masked]
Subject: Re: [netmod] Comments on draft-tissa-netmod-oam-01

> [Answer] most counters in CFM are 32 bit hence taken this. But we can extend to 64 bit very easily. We can consider for next revision making the counters 64 bit.

But what is the value of this typedef? Why introduce oam-counter32 if it is exactly yang:zero-based-counter32?

[answer] this is was done  for pragmatic reasons, that is in future if we have to change the counter definition then no need to change many places, just the generic typedef. Just like it is happening now.

/js

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 7 Jul 2014 23:26:18 +0000

Hi Tissa, Juergen,

> Above two seems a bit conflicting for the value of zero(0). Former states
> that zero(0) indicates usage of platform hash but the latter indicates that
> specific interface is used (i.e. not hashed?). Thinking about this, I believe
> "ecmp-choices" is overloaded. You actually want to be able to describe 3
> different things here.
> 
> Perhaps a different object for each may be a good idea. (2) can be an enum
> but it'll be beneficial to be able for various OAM tools to augment (1) and (3).
> [Answer] agree on #1 and #2, let me think how to  best bring that in into the
> next revisions.

As for #2, the two choices, specific interface (pre-routed/pre-switched) and load balanced (switched/routed), should suffice.

As for #1, this is a tricky one as we lack standards on the most of the load balancing techniques that employed on various products. There are some common load balancing techniques that can be listed (ex: n-tuple, round-robin, Entropy Label, etc), but would that suffice for this need? Exactly, what do we want to be able to do this #1?

>  #3 is part of flow-entropy discovery, which is independent of
> how it is treated. Way it is done is to have each of the technology to have its
> specific way of ECMP discovery, which is more like an RPC command. In the
> base YANG model, use can populate the flow entropy why XML imterface
> and #1 and #2 will dictates the behavior.

Agree, each technology being able to describe this separately will be good.

> [Answer] most counters in CFM are 32 bit hence taken this. But we can
> extend to 64 bit very easily. We can consider for next revision making the
> counters 64 bit.
> 

[from Juergen]
>     counter 64-bit may be as wrong as making all counters 32-bit.

Good point. Sending or receiving an OAM packet every 3.3 millisecond will cause 32 bit counter to wrap in 164 days (23 weeks and few days), we will definitely need a bigger counter for some OAM.

Thanks!

-Nobo

---

From: Qin Wu <[email-masked]>
Date: Tue, 8 Jul 2014 13:09:46 +0000

Sorry to chime in.
See some comments inline below.
-----邮件原件-----
>发件人: netmod [mailto:[email-masked]] 代表 Nobo Akiya (nobo)
>发送时间: 2014年7月5日 1:09
>收件人: Tissa Senevirathne (tsenevir)
>抄送: [email-masked]
>主题: [netmod] Comments on draft-tissa-netmod-oam-01

         ...
       ...

>When considering all OAM tools out there, defining a hard coded set of intervals (via enum) may not be a good idea. BFD implementations (SW/HW) springs to my mind immediately. For HW 
>based BFD, BFD WG is working on an informational document for recommended set of intervals: draft-ietf-bfd-intervals. However, intervals outside of that set can still be implemented by 
>vendors for HW based BFD. SW based BFD, obviously, has much more flexibility in the range of intervals to use. A better approach may be to change above from enum to identify ref (or
>something else) which can be augmented.

>Above two seems a bit conflicting for the value of zero(0). Former states that zero(0) indicates usage of platform hash but the latter indicates that specific interface is used (i.e. not hashed?). >Thinking about this, I believe "ecmp-choices" is overloaded. You actually want to be able to describe 3 different things here.

>1. Configuring a specific load balancing technique on a system (ex: EL, round-robin or something else).

[Qin]: are you proposing to replace ecmp-use-platform-hash with EL and have the following change to ecmp-choices typdef
NEW TEXT:
"
     typedef ecmp-choices {
       type enumeration {
         enum "Entropy Lable" {
           value 0;
         }
         enum "ecmp-use-round-robin" {
           value 1;
         }
       }
     }
"
However draft-tissa also has flow-entropy grouping to be defined
"
     grouping flow-entropy {
       description
         "defines the grouping statement for flow-entropy";
       choice flow-entropy {
         case flow-entropy-null;
       }
     }
"
Which make me difficult to understand how flow-entropy grouping is related to ecmp-choices

>2. Describing the output behavior on the OAM instance (ex: out to specific interface vs. load balanced).

[Qin]: I am wondering why not consider input behavior or input key to load balancing technique.

>3. Describe the setting on the path discovery OAM instance (ex: LSP tree trace using multipath 2, 4, 8, 9, 10).

[Qin]: Is this setting on path discovery OAM instance common setting? Or different OAM tool have different setting for path discovery mechanism.
Or you are just talking about different path have different setting?
I am trying to understand this.

>but it'll be beneficial to be able for various OAM tools to augment (1) and (3).

[Qin]: I tend to agree with this.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 10 Jul 2014 13:17:01 +0000

Hi Qin,

Please see in-line with [NOBO].

> From: Qin Wu [mailto:[email-masked]]
> Sent: Tuesday, July 08, 2014 9:10 AM
> To: Nobo Akiya (nobo); Tissa Senevirathne (tsenevir)
> Cc: [email-masked]; [email-masked]
> Subject: RE: Comments on draft-tissa-netmod-oam-01
> 
> Sorry to chime in.
> >First of all, intent of this document seems widely beneficial. I am
> interested to see how and In what form this document will progress.
> 
> >When considering all OAM tools out there, defining a hard coded set of
> >intervals (via enum) may not be a good idea. BFD implementations
> >(SW/HW) springs to my mind immediately. For HW based BFD, BFD WG is
> >working on an informational document for recommended set of intervals:
> draft-ietf-bfd-intervals. However, intervals outside of that set can still be
> implemented by vendors for HW based BFD. SW based BFD, obviously, has
> much more flexibility in the range of intervals to use. A better approach
> may be to change above from enum to identify ref (or something else)
> which can be augmented.
> 
> 
> >Comment #2: Section 6
> 
> > [snip]
> >     typedef ecmp-choices {
> >       type enumeration {
> specific interface is used (i.e. not hashed?). >Thinking about this, I believe
> [Qin]: are you proposing to replace ecmp-use-platform-hash with EL and
> have the following change to ecmp-choices typdef NEW TEXT:

[NOBO] We should probably take a step back, and decide if configuring load balancing behaviors on systems is something that belongs within draft-tissa-netmod-oam or not.

> However draft-tissa also has flow-entropy grouping to be defined "
>      grouping flow-entropy {
>        description

[NOBO] The goal here is to describe how OAM packets are sent from the system, so it's not that input behavior but it's the output behavior that we need to describe. Additionally, if the OAM packet is to get load balanced out from the system, then the fields from the packet contents should be used for load balancing, and not a separate input key. We will need to set certain fields of the OAM packets (ex: EL value, IP address, port), so if you meant "input key" to set those fields, then I agree.

> [Qin]: Is this setting on path discovery OAM instance common setting? Or
> different OAM tool have different setting for path discovery mechanism.

[NOBO] Probably both. At least with RFC4379, it is one mechanism but allows multiple path discovery techniques within it.

> [Qin]: I tend to agree with this.

:)

Thanks!

-Nobo

---

From: Qin Wu <[email-masked]>
Date: Thu, 10 Jul 2014 13:26:33 +0000

-----邮件原件-----
发件人: Nobo Akiya (nobo) [mailto:[email-masked]] 
发送时间: 2014年7月10日 21:17
收件人: Qin Wu; Tissa Senevirathne (tsenevir)
抄送: [email-masked]; [email-masked]
主题: RE: Comments on draft-tissa-netmod-oam-01

Hi Qin,

> >Please find below few comments I have on the 
> >draft-tissa-netmod-oam-01,
> from a quick look at the document.
> 
> 
> >Comment #1: Section 6
> 
> > [snip]
> >     typedef CCM-Interval {
> >       default "interval-1min";
> >       type enumeration {
> >When considering all OAM tools out there, defining a hard coded set 
> >of intervals (via enum) may not be a good idea. BFD implementations
> draft-ietf-bfd-intervals. However, intervals outside of that set can 
> still be implemented by vendors for HW based BFD. SW based BFD, 
> obviously, has much more flexibility in the range of intervals to use. 
> A better approach may be to change above from enum to identify ref (or 
> that zero(0) indicates usage of platform hash but the latter indicates 
> that specific interface is used (i.e. not hashed?). >Thinking about 
> this, I believe "ecmp-choices" is overloaded. You actually want to be 
> able to describe 3 different things here.
> 
> >1. Configuring a specific load balancing technique on a system (ex: 
> >EL,
> round-robin or something else).
> 

[Qin]: Make sense to me.

> >2. Describing the output behavior on the OAM instance (ex: out to 
> >specific
> interface vs. load balanced).
> 

[Qin]: Yes, I means those fields. Thanks for your clear clarification.