Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

[Don Fedyk <[e-mail]>]

Hi Qin

 

Yes my comments have been addressed,

 

Thanks, 

Don 

 

From: i2rs <[e-mail]> On Behalf Of Qin Wu
Sent: Thursday, August 27, 2020 9:08 AM
To: Don Fedyk <[e-mail]>; 'Susan Hares' <[e-mail]>; 'Glenn Parsons' <[e-mail]>; 'Scott Mansfield' <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

v-17 is posted

https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l2-network-topology-17

I believe Don’s comments are addressed in this version.

 

-Qin

发件人: i2rs [mailto:[e-mail]] 代表 Qin Wu
发送时间: 2020年8月27日 15:21
收件人: Don Fedyk <[e-mail] <mailto:[e-mail]> >; 'Susan Hares' <[e-mail] <mailto:[e-mail]> >; 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
抄送: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
主题: Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Hi, Don:

Thanks for your valuable feedback. I have integrated your additional proposed changes to v-17.

See my comments and clarification inline.

发件人: i2rs [mailto:[e-mail]] 代表 Don Fedyk
发送时间: 2020年8月26日 23:58
收件人: 'Susan Hares' <[e-mail] <mailto:[e-mail]> >; 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
抄送: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
主题: Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Hi 

 

As far as my individual comments – 

yes in my view the  terms in the v16  document have been changed match IEEE 802.1 topology attributes. 

(Many of these are optional identifiers)

Upon reflection, the bridge-id for example should probably represented as hexadecimal 8 octet string for readability.  (my original comment on this was listed as Uint64) but canonical form similar to the MAC address would allow people to see the base MAC in this the format.  

e.g.

type string {

         pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){7}';

       }

[Qin]:Changing type from uint64 into hexadecimal 8 octet string makes sense to me, thanks.

I have also validated the pattern, it works. 

The sample json test file provided has a few errors, although I see it was updated to support the new YANG,  I was able to make it parse in Yanglint with a few changes.  I think I understand the LAG representation, thanks.

Is the arrow int FIG 2 under 1-0-1-2 pointing in the right direction? I think it is two bidirectional links in a bidirectional link group but maybe I’m missing something. 

[Qin]: Becos LAG support is per termination-point, we didn’t show the direction of the link, but your understanding is correct, the link should be bidirectional, I will reflect this in the figure 2.

Also the ipv6 addresses have an invalid format. 

The LAG members need to be defined before they are referenced to in the lag group. I edited my local copy and it seemed to parse.  

[Qin]: Thanks for checking json snippet, I have incorporated it into v-16

Cheers,

Don

 

> data -t config -f json ietf-l2-topology-test.json

{

  "ietf-network:networks": {

    "network": [

      {

        "network-id": "l2-topo-example",

        "node": [

          {

            "node-id": "D1",

            "ietf-network-topology:termination-point": [

              {

                "tp-id": "1-0-1",

                "ietf-l2-topology:l2-termination-point-attributes": {

                  "mac-address": "00:00:5e:00:53:d0",

                  "lag": true,

                  "member-link-tp": [

                    "1-0-1-1",

                    "1-0-1-2"

                  ]

                }

              },

              {

                "tp-id": "1-0-1-1",

                "ietf-l2-topology:l2-termination-point-attributes": {

                  "mac-address": "00:00:5e:00:53:d3"

                }

              },

              {

                "tp-id": "1-0-1-2",

                "ietf-l2-topology:l2-termination-point-attributes": {

                  "mac-address": "00:00:5e:00:53:d4"

                }

              },

              {

                "tp-id": "1-2-1",

                "ietf-l2-topology:l2-termination-point-attributes": {

                  "mac-address": "00:00:5e:00:53:d1"

                }

              },

              {

                "tp-id": "1-3-1",

                "ietf-l2-topology:l2-termination-point-attributes": {

                  "mac-address": "00:00:5e:00:53:d2"

                }

              }

            ],

            "ietf-l2-topology:l2-node-attributes": {

              "management-address": [

                "192.0.2.1",

                "2001:db8:0:1::"

              ]

            }

          },

          {

            "node-id": "D2",

            "ietf-network-topology:termination-point": [

              {

                "tp-id": "2-0-1",

                "ietf-l2-topology:l2-termination-point-attributes": {

                  "mac-address": "00:00:5e:00:53:e0"

                }

              },

              {

                "tp-id": "2-1-1",

                "ietf-l2-topology:l2-termination-point-attributes": {

                  "mac-address": "00:00:5e:00:53:e1"

                }

              },

              {

                "tp-id": "2-3-1",

                "ietf-l2-topology:l2-termination-point-attributes": {

                  "mac-address": "00:00:5e:00:53:e2"

                }

              }

            ],

            "ietf-l2-topology:l2-node-attributes": {

              "management-address": [

                "192.0.2.2",

                "2001:db8:0:2::"

              ]

            }

          },

          {

            "node-id": "D3",

            "ietf-network-topology:termination-point": [

              {

                "tp-id": "3-1-1",

                "ietf-l2-topology:l2-termination-point-attributes": {

                  "mac-address": "00:00:5e:00:53:f0"

                }

              },

              {

                "tp-id": "3-2-1",

                "ietf-l2-topology:l2-termination-point-attributes": {

                  "mac-address": "00:00:5e:00:53:f1"

                }

              }

            ],

            "ietf-l2-topology:l2-node-attributes": {

              "management-address": [

                "192.0.2.3",

                "2001:db8:0:3::"

              ]

            }

          }

        ],

        "ietf-network-topology:link": [

          {

            "link-id": "D1,1-2-1,D2,2-1-1",

            "source": {

              "source-node": "D1",

              "source-tp": "1-2-1"

            },

            "destination": {

              "dest-node": "D2",

              "dest-tp": "2-1-1"

            },

            "ietf-l2-topology:l2-link-attributes": {

              "rate": "1000"

            }

          },

          {

            "link-id": "D2,2-1-1,D1,1-2-1",

            "source": {

              "source-node": "D2",

              "source-tp": "2-1-1"

            },

            "destination": {

              "dest-node": "D1",

              "dest-tp": "1-2-1"

            },

            "ietf-l2-topology:l2-link-attributes": {

              "rate": "1000"

            }

          },

          {

            "link-id": "D1,1-3-1,D3,3-1-1",

            "source": {

              "source-node": "D1",

              "source-tp": "1-3-1"

            },

            "destination": {

              "dest-node": "D3",

              "dest-tp": "3-1-1"

            },

            "ietf-l2-topology:l2-link-attributes": {

              "rate": "1000"

            }

          },

          {

            "link-id": "D3,3-1-1,D1,1-3-1",

            "source": {

              "source-node": "D3",

              "source-tp": "3-1-1"

            },

            "destination": {

              "dest-node": "D1",

              "dest-tp": "1-3-1"

            },

            "ietf-l2-topology:l2-link-attributes": {

              "rate": "1000"

            }

          },

          {

            "link-id": "D2,2-3-1,D3,3-2-1",

            "source": {

              "source-node": "D2",

              "source-tp": "2-3-1"

            },

            "destination": {

              "dest-node": "D3",

              "dest-tp": "3-2-1"

            },

            "ietf-l2-topology:l2-link-attributes": {

              "rate": "1000"

            }

          },

          {

            "link-id": "D3,3-2-1,D2,2-3-1",

            "source": {

              "source-node": "D3",

              "source-tp": "3-2-1"

            },

            "destination": {

              "dest-node": "D2",

              "dest-tp": "2-3-1"

            },

            "ietf-l2-topology:l2-link-attributes": {

              "rate": "1000"

            }

          }

        ]

      }

    ]

  }

}

> 

 

From: i2rs <[e-mail] <mailto:[e-mail]> > On Behalf Of Susan Hares
Sent: Wednesday, August 26, 2020 10:12 AM
To: 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Glenn:

 

The IETF culture suggests trying to work informally first.   We just have not heard back from Don Fedyk if our changes met his approval. 

We are trying to be good “citizens” of both societies – so we’ll wait a few more days.  

 

If we do not hear from Don or Scott by Friday,  I’ll check with Martin to see if he approves of us going the formal route.  

 

Thank you for your quick response. 

 

Sue 

 

From: Glenn Parsons [mailto:[e-mail]] 
Sent: Wednesday, August 26, 2020 9:33 AM
To: Susan Hares; [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield'; [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: RE: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Sue,

 

I would like to clarify that Don has provided IETF and I2RS with informal feedback as an individual.  This feedback was based on a review I requested from the YANGsters group in the IEEE 802.1 WG.  The informal feedback was provided to allow a more timely feedback to IETF.

 

If IETF or I2RS would like a formal liaison response, we can arrange that.

 

Cheers,

Glenn.

 

From: Susan Hares <[e-mail] <mailto:[e-mail]> > 
Sent: Wednesday, August 26, 2020 8:11 AM
To: [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; Glenn Parsons <[e-mail] <mailto:[e-mail]> >
Subject: FW: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Don and Scott:

 

We are awaiting feedback from you on the changes to the I2rs L2 model. 

Please let us know if you feel we have addressed all of your concerns. 

 

Susan Hares 

 

 

 

发件人: i2rs [mailto:[e-mail]] 代表 Qin Wu
发送时间: 2020年8月14日 13:59
收件人: Don Fedyk <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
抄送: 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >
主题: Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Don:

v-16 has just been posted,

see diff:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l2-network-topology-16.txt

Let us know if your comments are addressed.

 

-Qin

发件人: i2rs [mailto:[e-mail]] 代表 Qin Wu
发送时间: 2020年8月14日 13:41
收件人: Don Fedyk <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
抄送: 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >
主题: Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Thanks Don for clarification, I agree VID is per interface parameter, while management VLAN not.

 

-Qin

发件人: Don Fedyk [mailto:[e-mail]] 
发送时间: 2020年8月13日 21:22
收件人: Qin Wu <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
抄送: 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >
主题: RE: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Hi 

 

My point was you don’t know unambiguously VLAN ID (VID) all the time. 

If the Management address (MAC) is accessed by a particular interface the VID can be fixed for that interface. 

The VLAN is not configured but the set of VIDs that map to each VLAN is set per interface. 

A VID on an interface of the right TPID is distinct and MAPS to the VLAN.

 

If you only need the MAC as an identifier remove the VLAN or VID reference. 

If you want to access the Management address from this config it is: 

VID, MAC and interface (In many devices the VLAN is probably the same on several of the interfaces and VID suffices)

 

Cheers

Don 

 

From: i2rs <[e-mail] <mailto:[e-mail]> > On Behalf Of Qin Wu
Sent: Thursday, August 13, 2020 5:32 AM
To: Don Fedyk <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Cc: 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >
Subject: Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

One point to add:

How vlan-name is different from management-vlan?

      leaf management-vlan {

        type string;

        description

          "This is a VLAN that supports the Management address.

           The actual VLAN ID type and value would be a member of

           this VLAN.";

      }

Should we keep only one?

 

-Qin

发件人: i2rs [mailto:[e-mail]] 代表 Qin Wu
发送时间: 2020年8月13日 17:27
收件人: Don Fedyk <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
抄送: 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >
主题: Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Thanks Don for clarification.

I agree with your proposed changes. LAG usage will be added into  the example described in the appendix.

One more comment on VLAN NAME, VLAN NAME is defined as a leaf under “l2-node-attributes” while bridge-id

Is defined as leaf-list, 

“

      leaf-list bridge-id {

        type uint64;

        description

          "This is the 64-bit bridge identifier.  It has 4

           bits of priority, 12 bits of MSTI-ID and the base

           bridge identifier. There may be multiple one

           for each spanning tree instance.";

      }

      leaf vlan-name {

        type string;

        description

          "This is the name of the VLAN. Each VLAN can have

           any number of VLAN-IDs (1-4094).  The actual VLAN-ID

           are not enumerated. Each VLAN instance has a

           bridge-id.";

      }

”

Is the relation between vlan-name and bridge-id one to one? One to many?

Should VLAN NAME be defined as leaf-list, or is vlan-name redundant and should  it be removed?

 

-Qin

发件人: i2rs [mailto:[e-mail]] 代表 Don Fedyk
发送时间: 2020年8月12日 0:13
收件人: Qin Wu <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
抄送: 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >
主题: Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Hi Qin  

 

Inline [Don]

Note my answers are not definitive but I will attempt to address some points. 

 

Cheers

Don 

 

From: i2rs <[e-mail] <mailto:[e-mail]> > On Behalf Of Qin Wu
Sent: Friday, August 7, 2020 2:31 AM
To: Don Fedyk <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Cc: 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >
Subject: Re: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

Hi, Don:

Thanks for your valuable review, please see comments line.

 

-Qin

-----邮件原件-----
发件人: i2rs [mailto:[e-mail]] 代表 Don Fedyk
发送时间: 2020年8月6日 1:38
收件人: [e-mail] <mailto:[e-mail]> 
抄送: 'Glenn Parsons' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; 'Scott Mansfield' <[e-mail] <mailto:[e-mail]> >
主题: [i2rs] IEEE802.1 Feedback on draft-ietf-i2rs-yang-l2-network-topology-15.txt

 

IEEE 802.1 were asked to give feedback on the L2 topology model. 

We thank the I2RS WG for the opportunity.  

 

Executive Summary:

An alternative structure to the l2 topology information is suggested.  The rational is based on how bridges are described in IEEE 802.1Q-2018 and the structure used models the structure from analogous models.

[Qin]: Alignment with L3 topology model and IEEE 802.1Q terminologies and concept make sense to me. Thanks.

 

Detail:

 

As a reference we compared the L3 in topology in RFC8346 with L2 in draft-ietf-i2rs-yang-l2-network-topology-15.txt.

 

   module: ietf-l3-unicast-topology

     augment /nw:networks/nw:network/nw:network-types:

       +--rw l3-unicast-topology!

     augment /nw:networks/nw:network:

       +--rw l3-topology-attributes

          +--rw name?   string

          +--rw flag*   l3-flag-type

     augment /nw:networks/nw:network/nw:node:

       +--rw l3-node-attributes

          +--rw name?        inet:domain-name

          +--rw flag*        node-flag-type

          +--rw router-id*   rt-types:router-id

          +--rw prefix* [prefix]

             +--rw prefix    inet:ip-prefix

             +--rw metric?   uint32

             +--rw flag*     prefix-flag-type

     augment /nw:networks/nw:network/nt:link:

       +--rw l3-link-attributes

          +--rw name?      string

          +--rw flag*      link-flag-type

          +--rw metric1?   uint64

          +--rw metric2?   uint64

     augment /nw:networks/nw:network/nw:node/nt:termination-point:

       +--rw l3-termination-point-attributes

          +--rw (termination-point-type)?

             +--:(ip)

             |  +--rw ip-address*       inet:ip-address

             +--:(unnumbered)

             |  +--rw unnumbered-id?    uint32

             +--:(interface-name)

                +--rw interface-name?   string

 

This model augments a larger topology model as we understand it.  There are nodes and links and then termination points that represent the link attachment

to the nodes and ultimately a topology.   

 

 

Comment on draft-ietf-i2rs-yang-l2-network-topology-15.txt.

 

module: ietf-l2-topology

  augment /nw:networks/nw:network/nw:network-types:

    +--rw l2-network!

  augment /nw:networks/nw:network:

    +--rw l2-topology-attributes

       +--rw name?    string

       +--rw flags*   l2-flag-type

  augment /nw:networks/nw:network/nw:node:

    +--rw l2-node-attributes

       +--rw name?                 string

       +--rw description?          string

       +--rw management-address*   inet:ip-address

       +--rw sys-mac-address?      yang:mac-address

       +--rw management-vlan-id?   dot1q-types:vlanid {VLAN}?

       +--rw flags*                node-flag-type

 

Management address addresses the node but tells nothing of the L2 topology.

It is an informational attribute.  Management VLAN ID is only in context with a management interface.  Sys-MAC-address is not an IEEE 802.1 term.

Globally

unique bridge address is the MAC address that is the base of Bridge identifier and SystemID (the generic form of Bridge identifier) IEEE 802.1 Management MAC addresses are specified for some devices in 802.1Q primarily for Two port MAC relay which by definition has a limited number of ports and is men to be managed in-band. The address may part of a VLAN and reachable over a specific VLAN-ID. (that VLAN ID could be different depending on the interface used.) Management address are common on actual equipment. 

 

[Qin]: Agree. We can not find right reference when define these attributes, I am happy to adopt good definitions from IEEEE.

[Don] IEEE 802.1Q is the reference. Note  this is available freely on get program. 

https://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=68

 

  augment /nw:networks/nw:network/nt:link:

    +--rw l2-link-attributes

       +--rw name?    string

       +--rw flags*   link-flag-type

       +--rw rate?    uint64

       +--rw delay?   uint32

 

IEEE 802.1 Links have portIds or unnumbered identifiers (Shortest Path Bridging).  Delay is OK if it is a propagation delay between neighboring bridges. 

 

 

[Qin]: L2 topology model inherit portId (i..e, termination point, source-tp,dest-tp) from RFC8345. We will not redefine it.

[Don] Port Number is the term I should have used.   It is merely a number to identify a port which may be an interface or subset of an interface(link)

PortID is more specific to Spanning tree

  augment /nw:networks/nw:network/nw:node/nt:termination-point:

    +--rw l2-termination-point-attributes

       +--rw description?                   string

       +--rw maximum-frame-size?            uint32

       +--rw (l2-termination-point-type)?

       |  +--:(ethernet)

       |  |  +--rw mac-address?             yang:mac-address

       |  |  +--rw eth-encapsulation?       identityref

       |  |  +--rw lag?                     boolean

       |  |  +--rw member-link-tp*          -> /nw:networks/network

                                            /node/nt:termination-point/tp-id

       |  |  +--rw auto-negotiation?        boolean

       |  |  +--rw duplex?                  duplex-mode

       |  |  +--rw default-untagged-vlan?   dot1q-types:vlanid {VLAN}?

       |  |  +--rw vlans* [vlan-id] {VLAN}?

       |  |  |  +--rw vlan-id    dot1q-types:vlanid

       |  |  |  +--rw name?      string

       |  |  +--rw qinq* [svlan-id cvlan-id] {QinQ}?

       |  |  |  +--rw svlan-id    dot1q-types:vlanid

       |  |  |  +--rw cvlan-id    dot1q-types:vlanid

       |  |  +--rw vxlan {VXLAN}?

       |  |     +--rw vni-id?   vni

       |  +--:(legacy)

       |     +--rw layer-2-address?         yang:phys-address

       |     +--rw encapsulation?           identityref

       +--ro tp-state?                      Identityref

 

 

This part has a lot of detail.  It sees a termination point is a handoff of a particular packet or frame to an interface that specifies it layer and encapsulation.  But we are not sure.  A link mac-address may be present on a device, but we think it is irrelevant to the model. 

 

[Qin]: We have interface mac-address, which is relevant to termination point based on our understanding, also L2 node attribute need to have a relation to l2 termination point attribute, interface-mac-address can be this connection.

[Don] It occurred to me that there are two type of L2 termination. 

(I’m just enumerating the types-this is not official)  

Type 1) LAN termination to a higher level device.  These use NIC MAC addresses.  (for ARP for example).  

IEEE 802.1 does not defined these although the other side or a  LAN is connected to a bridge or HUB or it may be a point to point link ethernet link.

(Note VLAN tags are used to support priority queuing and marking  – which is defined in 802.1)   

Type 2)  L2 termination to a bridge control plane. In this case the MAC address does not have to be the MAC address of the NIC for the link it can be any supported MAC address on the bridge. 

The Bridge does not use the MAC address to identify links. That is where port number is used.

 

The encapsulation type is OK as specifying an instance of encapsulation. 

[Qin]:Yes, that is correct. So we need to keep it as l2 termination point attribute.

Lag at this level is a bit confusing. While one could view a LAG as either being a single large link it is useful to have LAG members identified directly for keeping traffic streams on a specific member link.  

[Qin]: Lag is Boolean attribute, see Lag definition " A link aggregation group (LAG) is the collection of physical ports combined together." It is related to termination point.

Lag is used to specify interface relationship or the relationship between termination points.

One example provided by IEEE in https://www.ieee802.org/1/files/public/docs2016/cp-mholness-YANG-Link-Aggregation-Model-Summary-0716-v12.pdf <https://protect2.fireeye.com/v1/url?k=a6cba32b-f86b43b5-a6cbe3b0-86ee86bd5107-0f9a7e00a3f0bb7e&q=1&e=031be243-d469-48e3-913a-0432f145f4bc&u=https%3A%2F%2Fwww.ieee802.org%2F1%2Ffiles%2Fpublic%2Fdocs2016%2Fcp-mholness-YANG-Link-Aggregation-Model-Summary-0716-v12.pdf> 



So we can use member-link-tp to describe if-3 and if-4 are member of if-2 when lag is set to true.

 

Member-link tp -  Is this being used to capture LAG members? 

 

[Qin]: Yes, see above.

[Don] This diagram is instance data- I can see the relationship.  – It would be beneficial to see the instance data for a similar LAG case In the topology view. 

Note LAGs are typically Bridge to Bridge  (Type 2) interface but they also can be server (Type 1) is on one side and the (type 2) bridge  on another side. 

 

We think Auto negation and duplex should be with the link properties. 

 

[Qin]: Okay, I have no objection to this.

 

The encapsulation is either no tag, priority tag, one tag C-VID or S-VID or two tags inner C-VID inner S-VID although other combinations are possible.

VLAN tags have type priority and VLAN ID.   Normally there is the addition

or

removal of only one tag. (VLAN tag) The VID can be specified here if it belong to the VLAN that support these links. 

Note in a bridge interface map to a Bridge component that supports a VLAN.

There is no mapping of VIDs to bridge components. Instead there is a filter or forward property for each VID on a VLAN.  There are also VID translation properties that are not captured by this model.  

It might be worth stating what the termination point model is expected here.

If an Interface and the supported VLANs is desired it would be a list of VLANs identified by names).  Then each VLAN would have the supported VLAN-IDs.

(Note that is per interface)..

If just the superset of all expected VLAN-ID received on an interface is portrayed, then that would say nothing about the connectivity to bridge components or the VLANs themselves. 

 

The other types of VXLAN and VPLS - We have not covered. 

[Qin]: Understand, this is not IEEE technology.

 

An L2 Model analogous to the L3 model:

 

It might help if we show how we think the L2 model could be analogous to the

L3 model.  Compared to the L3 Model L2 networks have a physical topology of nodes and links and build VLAN tree using spanning tree, RSTP, MSTP or SPB.

If IEEE were to build a model analogous to the L3 model but using L2 components it might look something like this: 

Note: This is a rough L2 physical model that follows the L3 paradigm.

 

module: ietf-l2-topology

     augment /nw:networks/nw:network/nw:network-types:

       +--rw l2-topology!

     augment /nw:networks/nw:network:

       +--rw l2-topology-attributes

          +--rw name?   string

          +--rw flag*   l2-flag-type

     augment /nw:networks/nw:network/nw:node:

       +--rw l2-node-attributes

          +--rw name         inet:domain-name

          +--rw description? string

          +--rw bridge-id          uint64

          +--rw vlan-name      string

          +--rw management-address*   inet:ip-address

          +--rw management-mac

          +--rw management-vlan   string

      augment /nw:networks/nw:network/nt:link-group

        +--rw l2-lag

             +--rw member[name]

             +--rw name-ref         -> /nw:networks/network/link

                                    /l2-link-attribute/name

     [Qin]: link-group is defined nowhere. Use link group to describe member link relationship is one option.

    But put them under termination point is more natural. See above clarification and example on LAG.

 

     augment /nw:networks/nw:network/nt:link:

       +--rw l2-link-attributes

          +--rw name?      string

          +--rw description?  String

          +--rw type       ianaift: interface-type

          +--rw flag*      link-flag-type

          +--rw rate       uint64

          +--rw delay      uint32

          +--rw auto-negotiation?        boolean

          +--rw duplex?                  duplex-mode         

 

     augment /nw:networks/nw:network/nw:node/nt:termination-point:

       +--rw l3-termination-point-attributes

          +--rw (termination-point-type)?

             +--:(ethernet)

             |  +--rw port-number?      uint32

             +--:(l2-unnumbered)

             |  +--rw unnumbered-id?    inet:ip-address

             +--:(interface-name)

                +--rw interface-name?   string

             +--rw outer-tag?      dot1q-types:vid-range-type

             +--rw outer-tpid?    vid-type

             +--rw inner-tag?     dot1q-types:vid-range-type

             +--rw inner-tpid?     vid-type

 

Explanation of the terms and assumptions:

bridge-id*   uint64 - This is the 64-bit bridge identifier.  It has 4 bits

of

priority 12 bits of MSTI-ID and the base bridge identifier. There may be multiple one for each spanning tree instance.  Note this is the closest analogy to router-id. It is unique per VLAN topology. 

 

vlan-name - This is the name of the VLAN. Each VLAN can have any number of VLAN-ID (1-4094).  The actual VLAN -ID are not enumerated. Each VLAN instance has a bridge-id. 

 

management-mac - this is a MAC address used the bridge management. I can be the Bridge Base VID or other.  

management-vlan - this is a VLAN that supports the Management address. The actual VLAN ID type and value would be a member of this VLAN. 

 

l2-lag - This is a Link aggregation group.  The attributes of the members must be the same and any encapsulation is inherited from the actual members. 

 

member[name] This is the list of links that belong to the group. 

 

Name This is the name of a link in the group as index and reference to a ll2 link. 

 

l2-link-attributes This is the L2 link attributes name - This is a string name type - this is an iana type description?  String

flag*      link-flag-type  We keep the flags - not sure what the flags are

rate       uint64  this is the link speed 

delay     unint32 this is link propagation delay (which is a function of

distance to the remote link endpoint.)  

auto-negotiation?    Boolean This should belong with the l2 link

duplex?              This should belong with the l2 links. 

[Qin]: Good input, it appears to me that we need to reorganize the model structure, move some of attributes from one place to another. I like it. Also thanks for providing a clear definition or modified definition for many attributes.

Termination point. 

We took a stab at the termination point

Note the IEEE bridges support VID translation - we have not capture this it is assumed that all VLAN -id received are accepted as on the wire.  The interface maps to the bridge component and the component filters or forwards the traffic.  Bridge Components also add and remove tags on the "leg" of the bridge based on the type of component.

We have suggested vlan tagging based on terminology similar to l2-sub-interfaces.

Typically only one tag is applied at a time but we have allow for 2. 

The type value a TPID allows the tags to be set appropriately (one tag or two). 

[Qin]: Make sense to me, I have added them, in addition, I think we should add if-feature for these parameters since as you clarified in some case only one tag is applied.

 

Physical topology versus VLAN topology information. 

Note: We don't believe the L2 document is trying to capture the VLAN topology. 

[Qin]:We are focusing define generic L2 topology, not tie to specific topology, this topology can be laid on top of another topology, therefore I am not sure we can simply see it as physical topology.

[Don] Understood but I can see a couple topologies 

1) Physical links and Nodes (Bridging) 

2) VLAN topologies on dedicated or shared links.

3) Subset of a VLAN identified by VLAN ID within a VLAN active topology. 

 

See my proposed tweak based on your proposed alternative model structure:

module: ietf-l2-topology

  augment /nw:networks/nw:network/nw:network-types:

    +--rw l2-topology!

  augment /nw:networks/nw:network:

    +--rw l2-topology-attributes

       +--rw name?    string

       +--rw flags*   l2-flag-type

  augment /nw:networks/nw:network/nw:node:

    +--rw l2-node-attributes

       +--rw name?                 string

       +--rw flags*                node-flag-type

       +--rw bridge-id*            uint64

       +--rw vlan-name?            string

       +--rw management-address*   inet:ip-address

       +--rw management-mac?       yang:mac-address

       +--rw management-vlan?      string

  augment /nw:networks/nw:network/nt:link:

    +--rw l2-link-attributes

       +--rw name?        string

       +--rw flags*       link-flag-type

       +--rw rate?        uint64

       +--rw delay?       uint32

       +--rw auto-nego?   boolean

       +--rw duplex?      duplex-mode

  augment /nw:networks/nw:network/nw:node/nt:termination-point:

    +--rw l2-termination-point-attributes

       +--rw (l2-termination-point-type)?

       |  +--:(ethernet)

       |  |  +--rw mac-address?      yang:mac-address

       |  +--:(l2-unnumbered)

       |  |  +--rw unnumbered-id?    uint32

       |  +--:(interface-name)

       |     +--rw interface-name?   string

       +--rw encapsulation-type?     identityref

       +--rw outer-tag?              dot1q-types:vid-range-type {QinQ}?

       +--rw outer-tpid?             dot1q-types:dot1q-tag-type {QinQ}?

       +--rw inner-tag?              dot1q-types:vid-range-type {QinQ}?

       +--rw inner-tpid?             dot1q-types:dot1q-tag-type {QinQ}?

       +--rw lag?                    boolean

       +--rw member-link-tp*         -> /nw:networks/network/node/nt:termination-point/tp-id

       +--rw vxlan {VXLAN}?

          +--rw vni-id?   vni

 

[Don] This is getting closer (IMHO)  I think there a couple of points – I see why you include a MAC-address as a termination point type 

The Bridge may use this address for logical link control (LLC).  Bridge control planes do not use MAC address for link identifier.  

It occurs to me that the MAC address is always on a link. 

The port Number is optional and may be multiple.  Same for unnumbered. 

 

Instead of  l2-termination-point-type)? 

I’d suggest 

+--rw (l2-termination-identifiers)?

       |  +--rw interface-name?   string

       |  +--rw mac-address?      yang:mac-address

       |  +--rw port-number*    

       |  +--unnumbered-id*

 

One interface:

Here you could have a MAC address (note in bridges YANG this is a config false value). 

A number of port identifiers or none.

A number of unnumbered interface identifiers or none. 

I think in many of the cases you are modeling with there would only be a interface with a MAC address.

 

 

The physical topology of Ethernet switches consists of nodes and links.

Often

these switches support routing as well as well as bridging. 

 

VLAN topology is different. VLAN had their origins with LANs and maintain a forwarding style that has served well for 40+ years.  VLANS are maintained on switched media today but maintain broadcast, multicast forwarding that enables MAC learning for unicast. 

 

Logically a L2 VLAN topology utilizes a forwarding tree and forwards or filters traffic over that tree based on traffic type, VLAN -ID and rules for that traffic type.

 

A VLAN topology is based on a forwarding tree (spanning trees or shortest path

trees) that resides on an active topology for that VLAN.  The active topology for a given VLAN is part or all of a physical bridged network and may be static or control plan driven.  

 

The traffic in a VLAN has a l2 header with a VLAN tag that contains a type, VLAN ID, priority code points and discard eligible indication.  The types support Customer (C-VLAN) and Service provider (S-VLAN) or Backbone Service provider (B-VLAN) topologies.  The VLAN-ID is a reusable 12 bit identifier that associates traffic to a VLAN at a point in the topology. The Value of the ID may change over the path of the frame as one way to avoid VLAN-ID contention.  Within a VLAN type it filters or forwards VLAN-ID tagged traffic based on static or dynamic (control plane) configuration.  MAC learning, broadcast and multicast occurs within this constrained VLAN tree.  These operations may be across all MACs within a VLAN (shared learning) or MAC-DA and VLAN ID (individual learning).

 

(Note: Shortest path trees have a slightly different behavior based on the SPB type. To keep this explanation simple we will use spanning tree here, but shortest path bridging is compatible with the spanning tree concepts.) It is possible to have a single spanning tree that supports all VLANs ID throughout the whole tree.  Simultaneously there could be another spanning tree that is disjoint (no shared interfaces) that also uses the same range and type of

VLAN-ID.   If at any point int eh network two VLANs share an interface the

VLAN IDs must be coordinated on that interface - the VLANs may use the same VLAN-IDs in different parts of the network where there is no conflict.

(usually the interface is of a single VLAN type). 

 

Best regards

Don

 

_______________________________________________

i2rs mailing list

 <mailto:[e-mail]> [e-mail]

 <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs