Hi Stephen:

发件人: Stephen Cheng [mailto:[email protected]]
发送时间: 2020年7月9日 12:53
收件人: [email protected]; [email protected]
主题: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

Dear authors,

I have a number of questions regarding this L2 topology YANG.


  1.  Does draft-ietf-i2rs-yang-l2-network-topology support the modelling of a 
termination point that maps to a VLAN sub-interface?
This capability would facilitate the creation of a topology stack for the 
following use cases:

     *   Mapping a ietf-l3-topology TP over a vlan sub-interface
In this case a TP in ietf-l3-topology instance would be supported by a VLAN 
sub-interface TP in the l2-topology
     *   Mapping different VLAN IDs in a L2 ports to different services

                                                               i.      For 
example, on a particular L2 port, VLAN 23 might be an attachment circuit for 
VPLS #78, where as VLAN 99 might be an attachment circuit for L3VPN #999

If draft-ietf-i2rs-yang-l2-network-topology does not have the capability to 
model VLAN sub-interface as a TP, is there a different way for 
draft-ietf-i2rs-yang-l2-network-topology to support the above use cases?

[Qin]: Good question, this could be documented in another new draft.  Also see 
4.4.2 (Underlay Hierarchies and Mappings) of RFC8345 for guideline.

  1.  The VLAN sub-interface YANG 
(https://tools.ietf.org/pdf/draft-ietf-netmod-sub-intf-vlan-model-06.pdf) being 
developed has some overlap with draft-ietf-i2rs-yang-l2-network-topology. It 
would be good if there would be better alignment between the two:
     *   Use similar definition/fields where possible; even better use shared 
grouping definition

                                                               i.      For 
example outer-tag and inner-tag

     *   VLAN sub-interface YANG 
(https://tools.ietf.org/pdf/draft-ietf-netmod-sub-intf-vlan-model-06.pdf) 
flexible encapsulation supports symmetric and asymmetric rewrites, which does 
not appear to be supported by draft-ietf-i2rs-yang-l2-network-topology.
            [Qin]: Both drafts import ieee802-dot1q-types, this is how we align 
with each other. The big difference between the model proposed by both drafts 
is one is device model, the other is network model.

  1.  Consider the scenario where a domain controller implementing 
draft-ietf-i2rs-yang-l2-network-topology is also implementing schema mounted 
ietf-interface to model the interface stacks of the managed devices:
-          Is there a mechanism in draft-ietf-i2rs-yang-l2-network-topology to 
associate a L2 TP with the corresponding interface entry in the schema mounted 
ietf-interface?
          [Qin]: This is the base model, if you want to support this complicate 
case, I think base model extension is needed.

  1.  For a LAG link, would the LAG TP be expected to be also represented by 
/nw:networks/nw:network/nw:node:termination-point/tp-id/supporting-termination-point
 to its membership TPs?
It would be useful to clarify for uniform implementation across different 
vendors.
           [Qin] Lag and member-link-tp under l2-termination-point-type choice 
can be used to support the case you mentioned below. See the definition of Lag 
and member-link for more details.
Aslo See section 4.4.6 Multihoming and link aggregation of RFC8345 for 
guideline.
Thank you.

Warm regards,
Stephen Cheng
Aviat Networks
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to