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

[Robert Wilton]

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:

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 namestring
   |   +--rw description?string
   |   +--rw typeidentityref
   |   +--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 namestring
   |   +--rw description?string
   |   +--rw typeidentityref
   |   +--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 

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

[Juergen Schoenwaelder]

On Wed, Nov 11, 2015 at 09:28:57AM +, William Lupton wrote:
> All,
> 
> 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 

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

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

[William Lupton]

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

> On 11 Nov 2015, at 10:49, Robert Wilton  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 
> '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! 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?

> Thanks,
> Rob
> 
> On 11/11/2015 09:28, William Lupton wrote:
>> 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 namestring
>>| +--rw description?string
>>| +--rw typeidentityref
>>| +--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 

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

[Robert Wilton]

Hi Juergen,

On 11/11/2015 12:13, Juergen Schoenwaelder wrote:

On Wed, Nov 11, 2015 at 09:28:57AM +, William Lupton wrote:

All,

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.
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




/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.



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

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

[Robert Wilton]

Hi William,

Please see inline ...

On 11/11/2015 12:21, William Lupton wrote:

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

On 11 Nov 2015, at 10:49, Robert Wilton > 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).


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.




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.
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.




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! 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





Thanks,
Rob

On 11/11/2015 09:28, William Lupton wrote:

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 

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

[Ladislav Lhotka]

Robert Wilton  writes:

> 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.

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

>
> 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:
>> 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 namestring
>>|   +--rw description?string
>>|   +--rw typeidentityref
>>|   +--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 namestring
>>|   +--rw description?string
>>|   +--rw type