idnits 2.17.1 draft-ietf-netmod-sub-intf-vlan-model-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 216 has weird spacing: '...ag-type dot...' == Line 219 has weird spacing: '...ag-type dot...' == Line 279 has weird spacing: '...ag-type dot...' == Line 282 has weird spacing: '...ag-type dot...' == Line 293 has weird spacing: '...ag-type dot...' == (7 more instances...) == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7224' is defined on line 1277, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-netmod-intf-ext-yang-05 == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-08 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Wilton, Ed. 3 Internet-Draft D. Ball 4 Intended status: Informational T. Singh 5 Expires: January 3, 2019 Cisco Systems 6 S. Sivaraj 7 Juniper Networks 8 July 2, 2018 10 Sub-interface VLAN YANG Data Models 11 draft-ietf-netmod-sub-intf-vlan-model-04 13 Abstract 15 This document defines YANG modules to add support for classifying 16 traffic received on interfaces as Ethernet/VLAN framed packets to 17 sub-interfaces based on the fields available in the Ethernet/VLAN 18 frame headers. These modules allow configuration of Layer 3 and 19 Layer 2 sub-interfaces (e.g. attachment circuits) that can 20 interoperate with IETF based forwarding protocols; such as IP and 21 L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The 22 sub-interfaces also interoperate with VLAN tagged traffic orginating 23 from an IEEE 802.1Q compliant bridge. Primarily the classification 24 is based on VLAN identifiers in the 802.1Q VLAN tags, but the model 25 also has support for matching on some other layer 2 frame header 26 fields and is designed to be extensible to match on other arbitrary 27 header fields. 29 The model differs from an IEEE 802.1Q bridge model in that the 30 configuration is interface/sub-interface based as opposed to being 31 based on membership of an 802.1Q VLAN bridge. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 3, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Interoperability with IEEE 802.1Q compliant bridges . . . 4 72 2.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4 73 3. L3 Interface VLAN Model . . . . . . . . . . . . . . . . . . . 5 74 4. Flexible Encapsulation Model . . . . . . . . . . . . . . . . 5 75 5. L3 Interface VLAN YANG Module . . . . . . . . . . . . . . . . 7 76 6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 10 77 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 7.1. Layer 3 sub-interfaces with IPv6 . . . . . . . . . . . . 19 79 7.2. Layer 2 sub-interfaces with L2VPN . . . . . . . . . . . . 21 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 81 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 9.1. WG version -04 . . . . . . . . . . . . . . . . . . . . . 23 83 9.2. WG version -03 . . . . . . . . . . . . . . . . . . . . . 24 84 9.3. WG version -02 . . . . . . . . . . . . . . . . . . . . . 24 85 9.4. WG version -01 . . . . . . . . . . . . . . . . . . . . . 24 86 9.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 24 87 9.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 24 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 90 11.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 25 91 11.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 25 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 94 12.2. Informative References . . . . . . . . . . . . . . . . . 28 95 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 29 96 A.1. Sub-interface based configuration model overview . . . . 29 97 A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 30 98 A.3. Possible Overlap Between the Two Models . . . . . . . . . 30 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 101 1. Introduction 103 This document defines two YANG [RFC7950] modules that augment the 104 encapsulation choice YANG element defined in Interface Extensions 105 YANG [I-D.ietf-netmod-intf-ext-yang] and the generic interfaces data 106 model defined in [RFC8343]. The two modules provide configuration 107 nodes to support classification of Ethernet/VLAN traffic to sub- 108 interfaces, that can have interface based feature and service 109 configuration applied to them. 111 The purpose of these models is to allow IETF defined forwarding 112 protocols, such as IPv6 [RFC2460], Ethernet Pseudo Wires [RFC4448] 113 and VPLS [RFC4761] [RFC4762] to be configurable via YANG when 114 interoperating with VLAN tagged traffic received from an IEEE 802.1Q 115 compliant bridge. 117 In the case of layer 2 Ethernet services, the flexible encapsulation 118 module also supports flexible rewriting of the VLAN tags contained 119 the in frame header. 121 For reference, a comparison between the sub-interface based YANG 122 model documented in this draft and an IEEE 802.1Q bridge model is 123 described in Appendix A. 125 In summary, the YANG modules defined in this internet draft are: 127 if-l3-vlan.yang - Defines the model for basic classification of 128 VLAN tagged traffic to L3 transport services 130 flexible-encapsulation.yang - Defines the model for flexible 131 classification of Ethernet/VLAN traffic to L2 transport services 133 1.1. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 139 appear in all capitals, as shown here. 141 Sub-interface: A sub-interface is a small augmentation of a regular 142 interface in the standard YANG module for Interface Management that 143 represents a subset of the traffic handled by its parent interface. 144 As such, it supports both configuration and operational data using 145 any other YANG models that augment or reference interfaces in the 146 normal way. It is defined in Interface Extensions YANG 147 [I-D.ietf-netmod-intf-ext-yang]. 149 1.2. Tree Diagrams 151 A simplified graphical representation of the data model is used in 152 this document. The meaning of the symbols in these diagrams is as 153 follows: 155 o Brackets "[" and "]" enclose list keys. 157 o Abbreviations before data node names: "rw" means configuration 158 (read-write), and "ro" means state data (read-only). 160 o Symbols after data node names: "?" means an optional node, "!" 161 means a presence container, and "*" denotes a list or leaf-list. 163 o Parentheses enclose choice and case nodes, and case nodes are also 164 marked with a colon (":"). 166 o Ellipsis ("...") stands for contents of subtrees that are not 167 shown. 169 2. Objectives 171 The primary aim of the YANG modules contained in this draft is to 172 provide the core model that is required to implement VLAN transport 173 services on router based devices that is fully compatible with IEEE 174 802.1Q compliant bridges. 176 A secondary aim is for the modules to be structured in such a way 177 that they can be cleanly extended in future. 179 2.1. Interoperability with IEEE 802.1Q compliant bridges 181 The modules defined in this document are designed to fully 182 interoperate with IEEE 802.1Q compliant bridges. In particular, the 183 models are restricted to only matching, adding, or rewriting the 184 802.1Q VLAN tags in frames in ways that are compatible with IEEE 185 802.1Q compliant bridges. 187 2.2. Extensibility 189 The modules are structured in such a way that they can be sensibly 190 extended. In particular: 192 The tag stack is represented as a list to allow a tag stack of 193 more than two tags to be supported if necessary in future. 195 The tag stack list elements allow other models, or vendors, to 196 include additional forms of tag matching and rewriting. The 197 intention, however, is that it should not be necessary to have any 198 vendor specific extensions to any of the YANG models defined in 199 this document to implement standard Ethernet and VLAN services. 201 3. L3 Interface VLAN Model 203 The L3 Interface VLAN model provides appropriate leaves for 204 termination of an 802.1Q VLAN tagged segment to a sub-interface based 205 L3 service. It allows for termination of traffic with up to two 206 802.1Q VLAN tags. 208 The "if-l3-vlan" YANG module has the following structure: 210 module: ietf-if-l3-vlan 211 augment /if:interfaces/if:interface/if-cmn:encapsulation/ 212 if-cmn:encaps-type: 213 +--:(dot1q-vlan) 214 +--rw dot1q-vlan 215 +--rw outer-tag! 216 | +--rw tag-type dot1q-tag-type 217 | +--rw vlan-id ieee:vlanid 218 +--rw second-tag! 219 +--rw tag-type dot1q-tag-type 220 +--rw vlan-id ieee:vlanid 222 4. Flexible Encapsulation Model 224 The Flexible Encapsulation model is designed to allow for the 225 flexible provisioning of layer 2 services. It provides the 226 capability to classify Ethernet/VLAN frames received on an Ethernet 227 trunk interface to sub-interfaces based on the fields available in 228 the layer 2 headers. Once classified to sub-interfaces, it provides 229 the capability to selectively modify fields within the layer 2 230 headers before the frame is handed off to the appropriate forwarding 231 code for further handling. 233 The model supports a common core set of layer 2 header matches based 234 on the 802.1Q tag type and VLAN Ids contained within the header up to 235 a tag stack depth of two tags. 237 The model supports flexible rewrites of the layer 2 frame header for 238 data frames as they are processed on the interface. It defines a set 239 of standard tag manipulations that allow for the insertion, removal, 240 or rewrite of one or two 802.1Q VLAN tags. The expectation is that 241 manipulations are generally implemented in a symmetrical fashion, 242 i.e. if a manipulation is performed on ingress traffic on an 243 interface then the reverse manipulation is always performed on egress 244 traffic out of the same interface. However, the model also allows 245 for asymmetrical rewrites, which may be required to implement some 246 forwarding models (such as E-Tree). 248 The structure of the model is currently limited to matching or 249 rewriting a maximum of two 802.1Q tags in the frame header but has 250 been designed to be easily extensible to matching/rewriting three or 251 more VLAN tags in future, if required. 253 The final aim for the model design is for it to be cleanly extensible 254 to add in additional match and rewrite criteria of the layer 2 255 header, such as matching on the source or destination MAC address, 256 PCP or DEI fields in the 802.1Q tags, or the EtherType of the frame 257 payload. Rewrites can also be extended to allow for modification of 258 other fields within the layer 2 frame header. 260 The "flexible-encapsulation" YANG module has the following structure: 262 module: ietf-flexible-encapsulation 263 augment /if:interfaces/if:interface/if-cmn:encapsulation/ 264 if-cmn:encaps-type: 265 +--:(flexible) 266 +--rw flexible 267 +--rw match 268 | +--rw (match-type) 269 | +--:(default) 270 | | +--rw default? empty 271 | +--:(untagged) 272 | | +--rw untagged? empty 273 | +--:(dot1q-priority-tagged) 274 | | +--rw dot1q-priority-tagged 275 | | +--rw tag-type? dot1q-types:dot1q-tag-type 276 | +--:(dot1q-vlan-tagged) 277 | +--rw dot1q-vlan-tagged 278 | +--rw outer-tag! 279 | | +--rw tag-type dot1q-tag-type 280 | | +--rw vlan-id union 281 | +--rw second-tag! 282 | | +--rw tag-type dot1q-tag-type 283 | | +--rw vlan-id union 284 | +--rw match-exact-tags? empty 285 +--rw rewrite {flexible-rewrites}? 286 | +--rw (direction)? 287 | +--:(symmetrical) 288 | | +--rw symmetrical 289 | | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 290 | | +--rw pop-tags? uint8 291 | | +--rw push-tags 292 | | +--rw outer-tag! 293 | | | +--rw tag-type dot1q-tag-type 294 | | | +--rw vlan-id ieee:vlanid 295 | | +--rw second-tag! 296 | | +--rw tag-type dot1q-tag-type 297 | | +--rw vlan-id ieee:vlanid 298 | +--:(asymmetrical) {asymmetric-rewrites}? 299 | +--rw ingress 300 | | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 301 | | +--rw pop-tags? uint8 302 | | +--rw push-tags 303 | | +--rw outer-tag! 304 | | | +--rw tag-type dot1q-tag-type 305 | | | +--rw vlan-id ieee:vlanid 306 | | +--rw second-tag! 307 | | +--rw tag-type dot1q-tag-type 308 | | +--rw vlan-id ieee:vlanid 309 | +--rw egress 310 | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? 311 | +--rw pop-tags? uint8 312 | +--rw push-tags 313 | +--rw outer-tag! 314 | | +--rw tag-type dot1q-tag-type 315 | | +--rw vlan-id ieee:vlanid 316 | +--rw second-tag! 317 | +--rw tag-type dot1q-tag-type 318 | +--rw vlan-id ieee:vlanid 319 +--rw local-traffic-default-encaps! 320 +--rw outer-tag! 321 | +--rw tag-type dot1q-tag-type 322 | +--rw vlan-id ieee:vlanid 323 +--rw second-tag! 324 +--rw tag-type dot1q-tag-type 325 +--rw vlan-id ieee:vlanid 327 5. L3 Interface VLAN YANG Module 329 This YANG module augments the encapsultion container defined in 330 Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. 332 file "ietf-if-l3-vlan@2017-10-30.yang" 333 module ietf-if-l3-vlan { 334 yang-version 1.1; 336 namespace "urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan"; 338 prefix if-l3-vlan; 340 import ietf-interfaces { 341 prefix if; 342 } 344 import iana-if-type { 345 prefix ianaift; 346 } 348 import ieee802-dot1q-types { 349 prefix dot1q-types; 350 } 352 import ietf-interfaces-common { 353 prefix if-cmn; 354 } 356 organization 357 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 359 contact 360 "WG Web: 361 WG List: 363 WG Chair: Lou Berger 364 366 WG Chair: Kent Watsen 367 369 Editor: Robert Wilton 370 "; 372 description 373 "This YANG module models L3 VLAN sub-interfaces"; 375 revision 2017-10-30 { 376 description "Latest draft revision"; 378 reference 379 "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-03"; 380 } 381 /* 382 * Add support for the 802.1Q VLAN encapsulation syntax on layer 3 383 * terminated VLAN sub-interfaces. 384 */ 385 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + 386 "if-cmn:encaps-type" { 387 when 388 "derived-from-or-self(../if:type, 389 'ianaift:ethernetCsmacd') or 390 derived-from-or-self(../if:type, 391 'ianaift:ieee8023adLag') or 392 derived-from-or-self(../if:type, 393 'if-cmn:ethSubInterface')" { 394 description 395 "Applies only to Ethernet-like interfaces and 396 sub-interfaces"; 397 } 399 description 400 "Augment the generic interface encapsulation with an 401 basic 802.1Q VLAN encapsulation for sub-interfaces."; 403 /* 404 * Matches a single VLAN Id, or pair of VLAN Ids to classify 405 * traffic into an L3 service. 406 */ 407 case dot1q-vlan { 408 container dot1q-vlan { 409 must 410 'count(../../if-cmn:forwarding-mode) = 0 or ' + 411 'derived-from-or-self(../../if-cmn:forwarding-mode,' + 412 '"if-cmn:layer-3-forwarding")' { 413 error-message 414 "If the interface forwarding-mode leaf is set then it 415 must be set to an identity that derives from 416 layer-3-forwarding"; 418 description 419 "The forwarding-mode leaf on an interface can 420 optionally be used to enforce consistency of 421 configuration"; 422 } 424 description 425 "Match VLAN tagged frames with specific VLAN Ids"; 426 container outer-tag { 427 presence "The outermost VLAN tag exists"; 428 description 429 "Classifies traffic using the outermost VLAN tag on the 430 frame."; 432 uses dot1q-types:dot1q-tag-classifier-grouping; 433 } 435 container second-tag { 436 must 437 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 438 'tag-type = "dot1q-types:c-vlan"' { 440 error-message 441 "When matching two tags, the outermost tag must be 442 specified and of S-VLAN type and the second outermost 443 tag must be of C-VLAN tag type"; 445 description 446 "For IEEE 802.1Q interoperability, when matching two 447 tags, it is required that the outermost tag exists and 448 is an S-VLAN, and the second outermost tag is a 449 C-VLAN"; 450 } 452 presence "The second outermost VLAN tag exists"; 454 description 455 "Classifies traffic using the second outermost VLAN tag 456 on the frame."; 458 uses dot1q-types:dot1q-tag-classifier-grouping; 459 } 460 } 461 } 462 } 463 } 464 466 6. Flexible Encapsulation YANG Module 468 This YANG module augments the encapsultion container defined in 469 Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. 471 This YANG module also augments the interface container defined in 472 [RFC8343]. 474 file "ietf-flexible-encapsulation@2017-10-30.yang" 475 module ietf-flexible-encapsulation { 476 yang-version 1.1; 477 namespace 478 "urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation"; 480 prefix flex; 482 import ietf-interfaces { 483 prefix if; 484 } 486 import iana-if-type { 487 prefix ianaift; 488 } 490 import ietf-interfaces-common { 491 prefix if-cmn; 492 } 494 import ieee802-dot1q-types { 495 prefix dot1q-types; 496 } 498 organization 499 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 501 contact 502 "WG Web: 503 WG List: 505 WG Chair: Lou Berger 506 508 WG Chair: Kent Watsen 509 511 Editor: Robert Wilton 512 "; 514 description 515 "This YANG module describes interface configuration for flexible 516 VLAN matches and rewrites."; 518 revision 2017-10-30 { 519 description "Latest draft revision"; 521 reference 522 "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-03"; 523 } 525 feature flexible-rewrites { 526 description 527 "This feature indicates whether the network element supports 528 specifying flexible rewrite operations"; 529 } 531 feature asymmetric-rewrites { 532 description 533 "This feature indicates whether the network element supports 534 specifying different rewrite operations for the ingress 535 rewrite operation and egress rewrite operation."; 536 } 538 feature dot1q-tag-rewrites { 539 description 540 "This feature indicates whether the network element supports 541 the flexible rewrite functionality specifying flexible 802.1Q 542 tag rewrites"; 543 } 545 /* 546 * flexible-match grouping. 547 * 548 * This grouping represents a flexible match. 549 * 550 * The rules for a flexible match are: 551 * 1. default, untagged, priority tag, or a stack of tags. 552 * - Each tag in the stack of tags matches: 553 * 1. tag type (802.1Q or 802.1ad) + 554 * 2. tag value: 555 * i. single tag 556 * ii. set of tag ranges/values. 557 * iii. "any" keyword 558 */ 559 grouping flexible-match { 560 description "Flexible match"; 561 choice match-type { 562 mandatory true; 563 description "Provides a choice of how the frames may be 564 matched"; 566 case default { 567 description "Default match"; 568 leaf default { 569 type empty; 570 description 571 "Default match. Matches all traffic not matched to any 572 other peer sub-interface by a more specific 573 encapsulation."; 574 } // leaf default 575 } // case default 577 case untagged { 578 description "Match untagged Ethernet frames only"; 579 leaf untagged { 580 type empty; 581 description 582 "Untagged match. Matches all untagged traffic."; 583 } // leaf untagged 584 } // case untagged 586 case dot1q-priority-tagged { 587 description 588 "Match 802.1Q priority tagged Ethernet frames only"; 590 container dot1q-priority-tagged { 591 description "802.1Q priority tag match"; 592 leaf tag-type { 593 type dot1q-types:dot1q-tag-type; 594 description "The 802.1Q tag type of matched priority 595 tagged packets"; 596 } 597 } 598 } 600 case dot1q-vlan-tagged { 601 container dot1q-vlan-tagged { 602 description "Matches VLAN tagged frames"; 604 container outer-tag { 605 presence "The outermost VLAN tag exists"; 607 description 608 "Classifies traffic using the outermost VLAN tag on the 609 frame."; 611 uses 612 'dot1q-types:'+ 613 'dot1q-tag-ranges-or-any-classifier-grouping'; 614 } 616 container second-tag { 617 must 618 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 619 'tag-type = "dot1q-types:c-vlan"' { 621 error-message 622 "When matching two tags, the outermost tag must be 623 specified and of S-VLAN type and the second 624 outermost tag must be of C-VLAN tag type"; 626 description 627 "For IEEE 802.1Q interoperability, when matching two 628 tags, it is required that the outermost tag exists 629 and is an S-VLAN, and the second outermost tag is a 630 C-VLAN"; 631 } 633 presence "The second outermost VLAN tag exists"; 635 description 636 "Classifies traffic using the second outermost VLAN tag 637 on the frame."; 639 uses 640 'dot1q-types:'+ 641 'dot1q-tag-ranges-or-any-classifier-grouping'; 642 } 644 leaf match-exact-tags { 645 type empty; 646 description 647 "If set, indicates that all 802.1Q VLAN tags in the 648 Ethernet frame header must be explicitly matched, i.e. 649 the EtherType following the matched tags must not be a 650 802.1Q tag EtherType. If unset then extra 802.1Q VLAN 651 tags are allowed."; 652 } 653 } 654 } 655 } // encaps-type 656 } 658 /* 659 * Grouping for tag-rewrite that can be expressed either 660 * symmetrically, or in the ingress and/or egress directions 661 * independently. 662 */ 663 grouping dot1q-tag-rewrite { 664 description "Flexible rewrite"; 665 leaf pop-tags { 666 type uint8 { 667 range 1..2; 668 } 669 description "The number of tags to pop (or translate if used in 670 conjunction with push-tags)"; 671 } 673 container push-tags { 674 description "The 802.1Q tags to push (or translate if used in 675 conjunction with pop-tags)"; 677 container outer-tag { 678 presence 679 "Indicates existence of the outermost VLAN tag to 680 push/rewrite"; 682 description 683 "The outermost VLAN tag to push onto the frame."; 685 uses dot1q-types:dot1q-tag-classifier-grouping; 686 } 688 container second-tag { 689 must 690 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 691 'tag-type = "dot1q-types:c-vlan"' { 693 error-message 694 "When pushing/rewriting two tags, the outermost tag must be 695 specified and of S-VLAN type and the second outermost tag 696 must be of C-VLAN tag type"; 698 description 699 "For IEEE 802.1Q interoperability, when pushing two tags, 700 it is required that the outermost tag exists and is an 701 S-VLAN, and the second outermost tag is a C-VLAN"; 702 } 704 presence 705 "Indicates existence of a second outermost VLAN tag to 706 push/rewrite."; 708 description 709 "The second outermost VLAN tag to push onto the frame."; 711 uses dot1q-types:dot1q-tag-classifier-grouping; 712 } 713 } 715 } 717 /* 718 * Grouping for all flexible rewrites of fields in the L2 header. 719 * 720 * This currently only includes flexible tag rewrites, but is 721 * designed to be extensible to cover rewrites of other fields in 722 * the L2 header if required. 723 */ 724 grouping flexible-rewrite { 725 description "Flexible rewrite"; 727 /* 728 * Tag rewrite. 729 * 730 * All tag rewrites are formed using a combination of pop-tags 731 * and push-tags operations. 732 */ 733 container dot1q-tag-rewrite { 734 if-feature dot1q-tag-rewrites; 735 description "Tag rewrite. Translate operations are expressed 736 as a combination of tag push and pop operations."; 737 uses dot1q-tag-rewrite; 738 } 739 } 740 augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + 741 "if-cmn:encaps-type" { 742 when 743 "derived-from-or-self(../if:type, 744 'ianaift:ethernetCsmacd') or 745 derived-from-or-self(../if:type, 746 'ianaift:ieee8023adLag') or 747 derived-from-or-self(../if:type, 748 'if-cmn:ethSubInterface')" { 749 description 750 "Applies only to Ethernet-like interfaces and 751 sub-interfaces"; 752 } 753 description 754 "Add flexible match and rewrite for VLAN sub-interfaces"; 756 /* 757 * A flexible encapsulation allows for the matching of ranges and 758 * sets of VLAN Ids. The structure is also designed to be 759 * extended to allow for matching/rewriting other fields within 760 * the L2 frame header if required. 761 */ 762 case flexible { 763 description "Flexible encapsulation and rewrite"; 764 container flexible { 765 must 766 'count(../../if-cmn:forwarding-mode) = 0 or ' + 767 'derived-from-or-self(../../if-cmn:forwarding-mode,' + 768 '"if-cmn:layer-2-forwarding")' { 769 error-message 770 "If the interface forwarding-mode leaf is set then it 771 must be set to an identity that derives from 772 layer-2-forwarding"; 774 description 775 "The forwarding-mode leaf on an interface can 776 optionally be used to enforce consistency of 777 configuration"; 778 } 780 description "Flexible encapsulation and rewrite"; 782 container match { 783 description 784 "The match used to classify frames to this interface"; 785 uses flexible-match; 786 } 788 container rewrite { 789 if-feature flexible-rewrites; 790 description "L2 frame rewrite operations"; 791 choice direction { 792 description 793 "Whether the rewrite policy is symmetrical or 794 asymmetrical"; 795 case symmetrical { 796 container symmetrical { 797 uses flexible-rewrite; 798 description 799 "Symmetrical rewrite. Expressed in the ingress 800 direction, but the reverse operation is applied to 801 egress traffic"; 802 } 803 } 805 /* 806 * Allow asymmetrical rewrites to be specified. 807 */ 808 case asymmetrical { 809 if-feature asymmetric-rewrites; 810 description "Asymmetrical rewrite"; 811 container ingress { 812 uses flexible-rewrite; 813 description "Ingress rewrite"; 814 } 815 container egress { 816 uses flexible-rewrite; 817 description "Egress rewrite"; 818 } 819 } 820 } 821 } 823 /* 824 * For encapsulations that match a range of VLANs (or Any), 825 * allow configuration to specify the default 802.1Q VLAN tag 826 * values to use for any traffic that is locally sourced from 827 * an interface on the device. 828 */ 829 container local-traffic-default-encaps { 830 presence 831 "A local traffic default encapsulation has been 832 specified"; 833 description 834 "The 802.1Q VLAN tags to use by default for locally 835 sourced traffic"; 837 container outer-tag { 838 presence 839 "Indicates existence of the outermost VLAN tag"; 841 description 842 "The outermost VLAN tag for locally sourced traffic"; 844 uses dot1q-types:dot1q-tag-classifier-grouping; 845 } 847 container second-tag { 848 must 849 '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + 850 'tag-type = "dot1q-types:c-vlan"' { 852 error-message 853 "When specifying two tags, the outermost tag must be 854 specified and of S-VLAN type and the second outermost 855 tag must be of C-VLAN tag type"; 857 description 858 "For IEEE 802.1Q interoperability, when specifying two 859 tags, it is required that the outermost tag exists and 860 is an S-VLAN, and the second outermost tag is a 861 C-VLAN"; 862 } 864 presence 865 "Indicates existence of a second outermost VLAN tag."; 867 description 868 "The second outermost VLAN tag for locally sourced 869 traffic"; 871 uses dot1q-types:dot1q-tag-classifier-grouping; 872 } 873 } 874 } 875 } 876 } 877 } 878 880 7. Examples 882 The following sections give examples of configuring a sub-interface 883 supporting L3 forwarding, and also a sub-interface being used in 884 conjunction with the IETF L2VPN YANG model 885 [I-D.ietf-bess-l2vpn-yang]. 887 7.1. Layer 3 sub-interfaces with IPv6 889 This example illustrates a layer 3 sub-interface configured to match 890 traffic with a S-VLAN tag of 10, and C-VLAN tag of 20. 892 893 894 899 900 eth0 901 ianaift:ethernetCsmacd 902 903 904 eth0.1 905 ianaift:l2vlan 906 eth0 907 908 910 911 dot1q-types:s-vlan 912 10 913 914 915 dot1q-types:c-vlan 916 20 917 918 919 920 921 true 922
923 2001:db8::10 924 32 925
926 927 928 929 eth0.2 930 ianaift:l2vlan 931 eth0 932 933 935 936 dot1q-types:s-vlan 937 11 938 939 940 941 942 true 943
944 2001:db8::11 945 32 946
947 948 949 950 952 7.2. Layer 2 sub-interfaces with L2VPN 954 This example illustrates a layer 2 sub-interface 'eth0.3' configured 955 to match traffic with a S-VLAN tag of 10, and C-VLAN tag of 21; and 956 both tags removed before the traffic is passed off to the L2VPN 957 service. 959 It also illustrates another sub-interface 'eth1.0' under a separate 960 physical interface configured to match traffic with a C-VLAN of 50, 961 and the tag removed before traffic is given to any service. Sub- 962 interface 'eth1.0' is not currently bound to any service and hence 963 traffic classifed to that sub-interface is dropped. 965 966 967 972 973 eth0 974 ianaift:ethernetCsmacd 975 976 977 eth0.3 978 ianaift:l2vlan 979 eth0 980 981 983 984 985 986 dot1q-types:s-vlan 987 10 988 989 990 dot1q-types:c-vlan 991 21 992 993 994 995 996 997 998 2 1000 1001 1002 1003 1004 1005 1006 1007 eth1 1008 ianaift:ethernetCsmacd 1009 1010 1011 eth1.0 1012 ianaift:l2vlan 1013 eth0 1014 1015 1017 1018 1019 1020 dot1q-types:c-vlan 1021 50 1022 1023 1024 1025 1026 1027 1028 1 1029 1030 1031 1032 1033 1034 1035 1036 1038 1040 p2p-l2-1 1041 Point to point L2 service 1042 l2vpn:vpws-instance-type 1043 1044 l2vpn:ldp-signaling 1045 1046 1047 local 1048 1049 eth0.3 1050 1051 1052 1053 remote 1054 1055 pw1 1056 1057 1058 1059 1060 1061 1062 1064 1065 pw1 1066 1067 2001:db8::50> 1068 100 1069 1070 1071 1072 1074 8. Acknowledgements 1076 The authors would particularly like to thank John Messenger, Glenn 1077 Parsons, and Dan Romascanu for their help progressing this draft. 1079 The authors would also like to thank Alex Campbell, Eric Gray, Giles 1080 Heron, Marc Holness, Iftekhar Hussain, Neil Ketley, William Lupton, 1081 John Messenger, Glenn Parsons, Ludwig Pauwels, Joseph White, Vladimir 1082 Vassilev, and members of the IEEE 802.1 WG for their helpful reviews 1083 and feedback on this draft. 1085 9. ChangeLog 1087 9.1. WG version -04 1089 o Added examples 1091 9.2. WG version -03 1093 o Fix namespace bug in XPath identity references, removed extraneous 1094 'dot1q-tag' containers. 1096 9.3. WG version -02 1098 o Use explicit containers for outer and inner tags rather than 1099 lists. 1101 9.4. WG version -01 1103 o Tweaked the abstract. 1105 o Removed unnecessary feature for the L3 sub-interface module. 1107 o Update the 802.1Qcp type references. 1109 o Remove extra tag container for L3 sub-interfaces YANG. 1111 9.5. Version -04 1113 o IEEE 802.1 specific types have been removed from the draft. These 1114 are now referenced from the 802.1Qcp draft YANG modules. 1116 o Fixed errors in the xpath expressions. 1118 9.6. Version -03 1120 o Incorporates feedback received from presenting to the IEEE 802.1 1121 WG. 1123 o Updates the modules for double tag matches/rewrites to restrict 1124 the outer tag type to S-VLAN and inner tag type to C-VLAN. 1126 o Updates the introduction to indicate primary use case is for IETF 1127 forwarding protocols. 1129 o Updates the objectives to make IEEE 802.1Q bridge interoperability 1130 a key objective. 1132 10. IANA Considerations 1134 This document defines several new YANG module and the authors 1135 politely request that IANA assigns unique names to the YANG module 1136 files contained within this draft, and also appropriate URIs in the 1137 "IETF XML Registry". 1139 11. Security Considerations 1141 The YANG module defined in this memo is designed to be accessed via 1142 the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is 1143 the secure transport layer and the mandatory to implement secure 1144 transport is SSH RFC 6242 [RFC6242]. The NETCONF access control 1145 model RFC 6536 [RFC6536] provides the means to restrict access for 1146 particular NETCONF users to a pre-configured subset of all available 1147 NETCONF protocol operations and content. 1149 There are a number of data nodes defined in this YANG module which 1150 are writable/creatable/deletable (i.e. config true, which is the 1151 default). These data nodes may be considered sensitive or vulnerable 1152 in some network environments. Write operations (e.g. edit-config) to 1153 these data nodes without proper protection can have a negative effect 1154 on network operations. These are the subtrees and data nodes and 1155 their sensitivity/vulnerability: 1157 11.1. if-l3-vlan.yang 1159 The nodes in the if-l3-vlan YANG module are concerned with matching 1160 particular frames received on the network device to connect them to a 1161 layer 3 forwarding instance, and as such adding/modifying/deleting 1162 these nodes has a high risk of causing traffic to be lost because it 1163 is not being classified correctly, or is being classified to a 1164 separate sub-interface. The nodes, all under the subtree 1165 /interfaces/interface/encapsulation/dot1q-vlan, that are sensitive to 1166 this are: 1168 o outer-tag/tag-type 1170 o outer-tag/vlan-id 1172 o second-tag/tag-type 1174 o second-tag/vlan-id 1176 11.2. flexible-encapsulation.yang 1178 There are many nodes in the flexible-encapsulation YANG module that 1179 are concerned with matching particular frames received on the network 1180 device, and as such adding/modifying/deleting these nodes has a high 1181 risk of causing traffic to be lost because it is not being classified 1182 correctly, or is being classified to a separate sub-interface. The 1183 nodes, all under the subtree 1184 /interfaces/interface/encapsulation/flexible/match, that are 1185 sensitive to this are: 1187 o default 1189 o untagged 1191 o dot1q-priority-tagged 1193 o dot1q-priority-tagged/tag-type 1195 o dot1q-vlan-tagged/outer-tag/vlan-type 1197 o dot1q-vlan-tagged/outer-tag/vlan-id 1199 o dot1q-vlan-tagged/second-tag/vlan-type 1201 o dot1q-vlan-tagged/second-tag/vlan-id 1203 There are also many modes in the flexible-encapsulation YANG module 1204 that are concerned with rewriting the fields in the L2 header for 1205 particular frames received on the network device, and as such 1206 adding/modifying/deleting these nodes has a high risk of causing 1207 traffic to be dropped or incorrectly processed on peer network 1208 devices, or it could cause layer 2 tunnels to go down due to a 1209 mismatch in negotiated MTU. The nodes, all under the subtree 1210 /interfaces/interface/encapsulation/flexible/rewrite, that are 1211 sensitive to this are: 1213 o symmetrical/dot1q-tag-rewrite/pop-tags 1215 o symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/tag-type 1217 o symmetrical/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1219 o symmetrical/dot1q-tag-rewrite/push-tags/second-tag/tag-type 1221 o symmetrical/dot1q-tag-rewrite/push-tags/second-tag/vlan-id 1223 o asymmetrical/ingress/dot1q-tag-rewrite/pop-tags 1225 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/tag- 1226 type 1228 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1230 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/tag- 1231 type 1233 o asymmetrical/ingress/dot1q-tag-rewrite/push-tags/second-tag/vlan- 1234 id 1236 o asymmetrical/egress/dot1q-tag-rewrite/pop-tags 1238 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/tag-type 1240 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/outer-tag/vlan-id 1242 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/tag- 1243 type 1245 o asymmetrical/egress/dot1q-tag-rewrite/push-tags/second-tag/vlan-id 1247 Nodes in the flexible-encapsulation YANG module that are concerned 1248 with the VLAN tags to use for traffic sourced from the network 1249 element could cause protocol sessions (such as CFM) to fail if they 1250 are added, modified or deleted. The nodes, all under the subtree 1251 /interfaces/interface/flexible-encapsulation/local-traffic-default- 1252 encaps that are sensitive to this are: 1254 o outer-tag/vlan-type 1256 o outer-tag/vlan-id 1258 o second-tag/vlan-type 1260 o second-tag/vlan-id 1262 12. References 1264 12.1. Normative References 1266 [I-D.ietf-netmod-intf-ext-yang] 1267 Wilton, R., Ball, D., tsingh@juniper.net, t., and S. 1268 Sivaraj, "Common Interface Extension YANG Data Models", 1269 draft-ietf-netmod-intf-ext-yang-05 (work in progress), 1270 July 2017. 1272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1273 Requirement Levels", BCP 14, RFC 2119, 1274 DOI 10.17487/RFC2119, March 1997, 1275 . 1277 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1278 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1279 . 1281 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1282 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1283 . 1285 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1286 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1287 May 2017, . 1289 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1290 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1291 . 1293 12.2. Informative References 1295 [dot1Qcp] Holness, M., "802.1Qcp Bridges and Bridged Networks - 1296 Amendment: YANG Data Model", 2018. 1298 [I-D.ietf-bess-l2vpn-yang] 1299 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1300 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1301 L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress), 1302 February 2018. 1304 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1305 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1306 December 1998, . 1308 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 1309 "Encapsulation Methods for Transport of Ethernet over MPLS 1310 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 1311 . 1313 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1314 LAN Service (VPLS) Using BGP for Auto-Discovery and 1315 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1316 . 1318 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1319 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1320 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1321 . 1323 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1324 and A. Bierman, Ed., "Network Configuration Protocol 1325 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1326 . 1328 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1329 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1330 . 1332 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1333 Protocol (NETCONF) Access Control Model", RFC 6536, 1334 DOI 10.17487/RFC6536, March 2012, 1335 . 1337 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 1339 In addition to the sub-interface based YANG model proposed here, the 1340 IEEE 802.1Q working group is also developing a YANG model for the 1341 configuration of 802.1Q VLANs. This raises the valid question as to 1342 whether the models overlap and whether it is necessary or beneficial 1343 to have two different models for superficially similar constructs. 1344 This section aims to answer that question by summarizing and 1345 comparing the two models. 1347 A.1. Sub-interface based configuration model overview 1349 The key features of the sub-interface based configuration model can 1350 be summarized as: 1352 o The model is primarily designed to enable layer 2 and layer 3 1353 services on Ethernet interfaces that can be defined in a very 1354 flexible way to meet the varied requirements of service providers. 1356 o Traffic is classified from an Ethernet-like interface to sub- 1357 interfaces based on fields in the layer 2 header. This is often 1358 based on VLAN Ids contained in the frame, but the model is 1359 extensible to other arbitrary fields in the frame header. 1361 o Sub-interfaces are just a type of if:interface and hence support 1362 any feature configuration YANG models that can be applied 1363 generally to interfaces. For example, QoS or ACL models that 1364 reference if:interface can be applied to the sub-interfaces, or 1365 the sub-interface can be used as an Access Circuit in L2VPN or 1366 L3VPN models that reference if:interface. 1368 o In the sub-interface based configuration model, the classification 1369 of traffic arriving on an interface to a given sub-interface, 1370 based on fields in the layer 2 header, is completely independent 1371 of how the traffic is forwarded. The sub-interface can be 1372 referenced (via references to if:interface) by other models that 1373 specify how traffic is forwarded; thus sub-interfaces can support 1374 multiple different forwarding paradigms, including but not limited 1375 to: layer 3 (IPv4/IPv6), layer 2 pseudowires (over MPLS or IP), 1376 VPLS instances, EVPN instance. 1378 o The model is flexible in the scope of the VLAN Identifier space. 1379 I.e. by default VLAN Ids can be scoped locally to a single 1380 Ethernet-like trunk interface, but the scope is determined by the 1381 forwarding paradigm that is used. 1383 A.2. IEEE 802.1Q Bridge Configuration Model Overview 1385 The key features of the IEEE 802.1Q bridge configuration model can be 1386 summarized as: 1388 o Each VLAN bridge component has a set of Ethernet interfaces that 1389 are members of that bridge. Sub-interfaces are not used, nor 1390 required in the 802.1Q bridge model. 1392 o Within a VLAN bridge component, the VLAN tag in the packet is 1393 used, along with the destination MAC address, to determine how to 1394 forward the packet. Other forwarding paradigms are not supported 1395 by the 802.1Q model. 1397 o Classification of traffic to a VLAN bridge component is based only 1398 on the Ethernet interface that it arrived on. 1400 o VLAN Identifiers are scoped to a VLAN bridge component. Often 1401 devices only support a single bridge component and hence VLANs are 1402 scoped globally within the device. 1404 o Feature configuration is specified in the context of the bridge, 1405 or particular VLANs on a bridge. 1407 A.3. Possible Overlap Between the Two Models 1409 Both models can be used for configuring similar basic layer 2 1410 forwarding topologies. The 802.1Q bridge configuration model is 1411 optimised for configuring Virtual LANs that span across enterprises 1412 and data centers. 1414 The sub-interface model can also be used for configuring equivalent 1415 Virtual LAN networks that span across enterprises and data centers, 1416 but often requires more configuration to be able to configure the 1417 equivalent constructs to the 802.1Q bridge model. 1419 The sub-interface model really excels when implementing flexible L2 1420 and L3 services, where those services may be handled on the same 1421 physical interface, and where the VLAN Identifier is being solely 1422 used to identify the customer or service that is being provided 1423 rather than a Virtual LAN. The sub-interface model provides more 1424 flexibility as to how traffic can be classified, how features can be 1425 applied to traffic streams, and how the traffic is to be forwarded. 1427 Conversely, the 802.1Q bridge model can also be use to implement L2 1428 services in some scenarios, but only if the forwarding paradigm being 1429 used to implement the service is the native Ethernet forwarding 1430 specified in 802.1Q - other forwarding paradigms such as pseudowires 1431 or VPLS are not supported. The 802.1Q bridge model does not 1432 implement L3 services at all, although this can be partly mitigated 1433 by using a virtual L3 interface construct that is a separate logical 1434 Ethernet-like interface which is a member of the bridge. 1436 In conclusion, it is valid for both of these models to exist since 1437 they have different deployment scenarios for which they are 1438 optimized. Devices may choose which of the models (or both) to 1439 implement depending on what functionality the device is being 1440 designed for. 1442 Authors' Addresses 1444 Robert Wilton (editor) 1445 Cisco Systems 1447 Email: rwilton@cisco.com 1449 David Ball 1450 Cisco Systems 1452 Email: daviball@cisco.com 1454 Tapraj Singh 1455 Cisco Systems 1457 Email: tapsingh@cisco.com 1459 Selvakumar Sivaraj 1460 Juniper Networks 1462 Email: ssivaraj@juniper.net