Subject: [netmod] Modelling ports that can support multiple physical layer standards

From: William Lupton <[email-masked]>
Date: Wed, 11 Nov 2015 09:28:57 +0000

All,

We would much appreciate comments and suggestions on the question posed below.

Thanks,
William Lupton
(Software Architect, Broadband Forum)

----------------

In the Broadband Forum we need to model a port that can support several physical layer standards, but only one at a time. An initial handshake mechanism determines which of these standards will actually be used. We have been trying to decide how best to model this according to the letter and spirit of RFCs 6020, 6087, 7223 etc.

Consider a port, a handshake mechanism "color-selector" and two physical layer standards "green" and "red". Each of these is modelled via a YANG module of the same name ("port" probably uses the ietf-entity module). Here are the approaches that we have considered:

**** Option 1 "direct augment" ****

color-selector, green and red all directly augment /if:interfaces/if:interface. An instance of each of them is associated with the port. See part of the tree here (YANG on request).

module: ietf-interfaces
   +--rw interfaces
   |  +--rw interface* [name]
   |     +--rw name                        string
   |     +--rw description?                string
   |     +--rw type                        identityref
   |     +--rw enabled?                    boolean
   |     +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   |     +--rw color-sel:line
   |     +--rw green:line
   |     +--rw red:line

Note that this means that each port needs three separate interface objects. For each additional possible supported physical layer standard, an additional interface object would be needed.

**** Option 2 "indirect augment" ****

An additional if-multicolor module directly augments /if:interfaces/if:interface. An instance of if-multicolor is associated with the port. if-multicolor has a supported-type leaf-list that indicates the physical layer standards that are supported by the port (green and red in this case). color-selector, green and red are similar to before but this time they augment /if:interfaces/if:interface/multi:line, and the green and red "when" (existence) criteria are tied to if-multicolor's supported-type leaf-list rather than to their own type leaf. See part of the tree here (YANG on request).

module: ietf-interfaces
   +--rw interfaces
   |  +--rw interface* [name]
   |     +--rw name                        string
   |     +--rw description?                string
   |     +--rw type                        identityref
   |     +--rw enabled?                    boolean
   |     +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   |     +--rw multi:line
   |        +--rw multi:supported-type*   identityref
   |        +--rw color-sel:line
   |        +--rw green:line
   |        +--rw red:line

The nice thing about this approach is that it models the port in a way that is close to how it actually _is_. Each port needs only a single interface that's directly associated with the handshake mechanism and the supported physical layer standards.

A possible disadvantage of this approach is that it is a bit less well aligned with RFC 7223, e.g there is only one interface-level enable/disable that has to be "shared" by color-selector, green and red.

---

From: Robert Wilton <[email-masked]>
Date: Wed, 11 Nov 2015 10:49:51 +0000

Hi William,

I'm not that familiar with Broadband physical layer standards, but I 
have an interest in figuring out some of the physical layer and 
interface layer relationships in YANG.

There are a couple of things that are not clear to me from your email, 
so I have two questions:

1) Am I right to presume that the "type" of the port is fixed, and can't 
be changed by the handshake mechanism?
2) I don't quite understand your last sentence regarding only one 
interface-level enable/disable leaf.  I would have thought that this 
would be a benefit.  Please can you elaborate.

There is possibly a third way to model this, which is to have an 
augmentation of a choice statement, i.e.:
1. Your base model would define a choice statement representing the 
physical-layer 'color'.
2. Each physical layer 'color' would be a separate augmentation of the 
choice statement.

Using this design ensures that the model can only ever have a single 
physical-layer at a given time, and yet still makes it clear which 
physical-layer is in use and also allows for different configuration 
nodes for each color.

I've used this structure for modelling layer 2 encapsulation in the IDs 
that I've put forward:
E.g. see "choice encaps-type" in draft-wilton-netmod-intf-ext-yang-01 
for the base model, and two instances of

'augment "/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type"'

in draft-wilton-netmod-intf-vlan-yang-01 for two example augmentation 
cover a basic VLAN layer 2 encapsulation, and a more flexible layer 2 
encapsulation.  Other layer 2 encapsulations could also be defined for 
PPP, cHDLC, FR, ATM, etc in separate drafts.

Perhaps this choice + augmentation design would also work well in your case?

Thanks,
Rob

On 11/11/2015 09:28, William Lupton wrote:
> In the Broadband Forum we need to model a port that can support 
> several physical layer standards, but only one at a time. An initial 
> handshake mechanism determines which of these standards will actually 
> be used. We have been trying to decide how best to model this 
> according to the letter and spirit of RFCs 6020, 6087, 7223 etc.
>
> Consider a port, a handshake mechanism "color-selector" and two 
> physical layer standards "green" and "red". Each of these is modelled 
> via a YANG module of the same name ("port" probably uses the 
> ietf-entity module). Here are the approaches that we have considered:
>
> ***** Option 1 "direct augment" *****
>
> color-selector, green and red all directly augment 
> /if:interfaces/if:interface. An instance of each of them is associated 
> with the port. See part of the tree here (YANG on request).
>
> module: ietf-interfaces
> +--rw interfaces
> Note that this means that each port needs three separate interface 
> objects. For each additional possible supported physical layer 
> standard, an additional interface object would be needed.
>
> ***** Option 2 "indirect augment" *****
>
> An additional if-multicolor module directly augments 
> /if:interfaces/if:interface. An instance of if-multicolor is 
> associated with the port. if-multicolor has a supported-type leaf-list 
> that indicates the physical layer standards that are supported by the 
> port (green and red in this case). color-selector, green and red are 
> similar to before but this time they augment 
> /if:interfaces/if:interface/multi:line, and the green and red "when" 
> (existence) criteria are tied to if-multicolor's supported-type 
> leaf-list rather than to their own type leaf. See part of the tree 
> here (YANG on request).
>
> module: ietf-interfaces
> +--rw interfaces
> The nice thing about this approach is that it models the port in a way 
> that is close to how it actually _is_. Each port needs only a single 
> interface that's directly associated with the handshake mechanism and 
> the supported physical layer standards.
>
> A possible disadvantage of this approach is that it is a bit less well 
> aligned with RFC 7223, e.g there is only one interface-level 
> enable/disable that has to be "shared" by color-selector, green and red.
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Nov 2015 13:13:36 +0100

> We would much appreciate comments and suggestions on the question posed below.

[...]

Good question. Is this question comparable to IEEE 802.3 interfaces
and Medium Attachment Units (MAUs)? In the past, I think we have seen
different approaches and I am not sure there is agreement on a common
approach. For 802.3 MAUs, MAU details were modeled in data models
extending a single interface. For other technologies, interface
layering seemed to be more appropriate. It would be nice if there
would a common understanding how to model interface specifics
consistently but I am afraid we have no common model. The
ietf-interfaces module essentially allows both approaches. It leaves
it open, however, to decide which approach is appropriate.

/js

PS: A pure layering approach would treat an IP interface as an
    interface layered on top of say an IEEE 802.3 interface but
    the ietf-ip module does not really force this since many
    implementations do not expose this layering. If I would do
    a clean slate design, I would likely, from a architectural
    point of view, go with a layering approach.

-- 
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: William Lupton <[email-masked]>
Date: Wed, 11 Nov 2015 12:21:40 +0000

Rob, Thanks! Please see inline. Cheers, William.

> On 11 Nov 2015, at 10:49, Robert Wilton <[email-masked]> wrote:
> 
> Hi William,
> 
> I'm not that familiar with Broadband physical layer standards, but I have an interest in figuring out some of the physical layer and interface layer relationships in YANG.
> 
> There are a couple of things that are not clear to me from your email, so I have two questions:
> 
> 1) Am I right to presume that the "type" of the port is fixed, and can't be changed by the handshake mechanism?

I'd say "no" in the sense that the port is initially a color-selector port, and then (after the colour selection) will be either a green port or a red port. These are all types (interface types).

> 2) I don't quite understand your last sentence regarding only one interface-level enable/disable leaf.  I would have thought that this would be a benefit.  Please can you elaborate.

In the second case (indirect augment), a single multi:line interface is associated with the port, so the standard "enabled" leaf node (administrative enable/disable) will apply to the the multi:line interface. This means that there is no way (should you wish it) to individually disable green or red. This would require addition of such controls at the green and red level.

> There is possibly a third way to model this, which is to have an augmentation of a choice statement, i.e.:
> 1. Your base model would define a choice statement representing the physical-layer 'color'.
> 2. Each physical layer 'color' would be a separate augmentation of the choice statement.
> 
> Using this design ensures that the model can only ever have a single physical-layer at a given time, and yet still makes it clear which physical-layer is in use and also allows for different configuration nodes for each color.
> 
> I've used this structure for modelling layer 2 encapsulation in the IDs that I've put forward:
> E.g. see "choice encaps-type" in draft-wilton-netmod-intf-ext-yang-01 for the base model, and two instances of 
> in draft-wilton-netmod-intf-vlan-yang-01 for two example augmentation cover a basic VLAN layer 2 encapsulation, and a more flexible layer 2 encapsulation.  Other layer 2 encapsulations could also be defined for PPP, cHDLC, FR, ATM, etc in separate drafts.
> 

Thanks! I'll take a look at those drafts. Would this approach allow green and red config to exist simultaneously on an interface? I think we'd want to be able to do that. Perhaps the choice approach might be used only in the state tree?

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Nov 2015 13:54:54 +0100

> 2. Each physical layer 'color' would be a separate augmentation of the 

Another option might be to come up with a hierarchy of interface types and
then make conditional augments based on the type.

For example, a simple hierarchy could be like this:

multi-color
  red
  green

Now that YANG 1.1 supports multiple inheritance of identities, this
would be just another interface property axis.  

This design is extensible and also allows for fine control of how
individual properties are shared among the "colors".

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Robert Wilton <[email-masked]>
Date: Wed, 11 Nov 2015 14:44:47 +0000

Hi Juergen,

> it open, however, to decide which approach is appropriate.
I think that a further issue here is that different vendors may have 
different ideas of how to model the layers.  Some vendors have a single 
interface representing both the physical and network layers, but other 
vendors have two separate interfaces (which must have different names to 
appear in if:interfaces) representing both layers (in some cases, if not 
all).  But any such ambiguity is surely going to make models harder to 
use by operators, and hence it would be sensible if the standard IETF 
models could define the expected interface layering behaviour for common 
interface types, even if the base interface model(s) allow for 
alternative interface layering architectures.

Cheers,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 11 Nov 2015 15:03:04 +0000

Hi William,

Please see inline ...

On 11/11/2015 12:21, William Lupton wrote:
>> On 11 Nov 2015, at 10:49, Robert Wilton <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi William,
>>
>> 1) Am I right to presume that the "type" of the port is fixed, and 
>> can't be changed by the handshake mechanism?
>
> I'd say "no" in the sense that the port is initially a color-selector 
> port, and then (after the colour selection) will be either a green 
> port or a red port. These are all types (interface types).

OK.  I'm not sure whether changing the type of an existing interface is 
a good idea.  E.g. shouldn't the interface type of the base interface 
represent the physical interface that you are operating over.

> In the second case (indirect augment), a single multi:line interface 
> is associated with the port, so the standard "enabled" leaf node 
> (administrative enable/disable) will apply to the the multi:line 
> interface. This means that there is no way (should you wish it) to 
> individually disable green or red. This would require addition of such 
> controls at the green and red level.
OK.  But if I understand it correctly a particular port could only ever 
be running as either green or red, never both at the same time.  Is that 
right?  Is so, then I would have thought that a single interface 
enable/disable is sufficient.

Presumably disabling green or red colours could be accomplished by 
removing the associated configuration.

>> encapsulation.  Other layer 2 encapsulations could also be defined 
>> for PPP, cHDLC, FR, ATM, etc in separate drafts.
>>
> Thanks! I'll take a look at those drafts. Would this approach allow 
> green and red config to exist simultaneously on an interface?
No.  The choice statement means that there can be only one colour of 
config at a given time.

Is your requirement effectively a templating one?  I.e. the need to 
define possible configuration for both red and green and then allow the 
protocol to negotiate which colour and hence configuration is used?

> I think we'd want to be able to do that. Perhaps the choice approach 
> might be used only in the state tree?
Yes possibly, although equally if the leaves in the state tree are not 
mandatory then the information for the unavailable colour could just not 
be returned.

Thanks,
Rob

>>> handshake mechanism determines which of these standards will 
>>> actually be used. We have been trying to decide how best to model 
>>> this according to the letter and spirit of RFCs 6020, 6087, 7223 etc.
>>>
>>> physical layer standards "green" and "red". Each of these is 
>>> modelled via a YANG module of the same name ("port" probably uses 
>>> the ietf-entity module). Here are the approaches that we have 
>>> considered:
>>>
>>> /if:interfaces/if:interface. An instance of each of them is 
>>> associated with the port. See part of the tree here (YANG on request).
>>>
>>> module: ietf-interfaces
>>>    +--rw interfaces
>>> associated with the port. if-multicolor has a supported-type 
>>> leaf-list that indicates the physical layer standards that are 
>>> supported by the port (green and red in this case). color-selector, 
>>> green and red are similar to before but this time they augment 
>>> The nice thing about this approach is that it models the port in a 
>>> way that is close to how it actually _is_. Each port needs only a 
>>> single interface that's directly associated with the handshake 
>>> mechanism and the supported physical layer standards.
>>>
>>> A possible disadvantage of this approach is that it is a bit less 
>>> well aligned with RFC 7223, e.g there is only one interface-level