idnits 2.17.1 draft-ietf-i2rs-yang-l3-topology-11.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 238 has weird spacing: '... prefix ine...' -- The document date (September 19, 2017) is 2404 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1195' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'RFC7223' is defined on line 860, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-16 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-02 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-10) exists of draft-acee-rtgwg-yang-rib-extend-02 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-09 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Clemm 3 Internet-Draft Huawei 4 Intended status: Standards Track J. Medved 5 Expires: March 23, 2018 Cisco 6 R. Varga 7 Pantheon Technologies SRO 8 X. Liu 9 Ericsson 10 H. Ananthakrishnan 11 Packet Design 12 N. Bahadur 13 Bracket Computing 14 September 19, 2017 16 A YANG Data Model for Layer 3 Topologies 17 draft-ietf-i2rs-yang-l3-topology-11.txt 19 Abstract 21 This document defines a YANG data model for layer 3 network 22 topologies. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 23, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 61 4. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Layer 3 Unicast Topology Model Overview . . . . . . . . . . . 5 63 6. Layer 3 Unicast Topology YANG Module . . . . . . . . . . . . 7 64 7. Interactions with Other YANG Modules . . . . . . . . . . . . 15 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 71 12.2. Informative References . . . . . . . . . . . . . . . . . 18 72 Appendix A. Companion YANG model for non-NMDA compliant 73 implementations . . . . . . . . . . . . . . . . . . 20 74 Appendix B. Extending the Model . . . . . . . . . . . . . . . . 24 75 B.1. Example OSPF Topology . . . . . . . . . . . . . . . . . . 24 76 B.1.1. Model Overview . . . . . . . . . . . . . . . . . . . 24 77 B.1.2. OSPF Topology YANG Module . . . . . . . . . . . . . . 26 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 80 1. Introduction 82 This document introduces a YANG [RFC7950] [RFC6991] data model for 83 Layer 3 network topologies, specifically Layer 3 Unicast. The model 84 allows an application to have a holistic view of the topology of a 85 Layer 3 network, all contained in a single conceptual YANG datastore. 86 The data model builds on top of, and augments, the data model for 87 network topologies defined in 88 [I-D.draft-ietf-i2rs-yang-network-topo]. 90 This document also shows how the model can be further refined to 91 cover different Layer 3 Unicast topology types. For this purpose, 92 example model is introduced that covers OSPF [RFC2328]. This example 93 is intended purely for illustrative purpose; we expect that full- 94 blown OSPF model will be more comprehensive and refined than the 95 example shown here. 97 There are multiple applications for a topology data model. A number 98 of use cases have been defined in section 6 of 99 [I-D.draft-ietf-i2rs-usecase-reqs-summary]. For example, nodes 100 within the network can use the data model to capture their 101 understanding of the overall network topology and expose it to a 102 network controller. A network controller can then use the 103 instantiated topology data to compare and reconcile its own view of 104 the network topology with that of the network elements that it 105 controls. Alternatively, nodes within the network could propagate 106 this understanding to compare and reconcile this understanding either 107 amongst themselves or with help of a controller. Beyond the network 108 element itself, a network controller might even use the data model to 109 represent its view of the topology that it controls and expose it to 110 applications north of itself. 112 The data model for Layer 3 Unicast topologies defined in this 113 document is specified in a YANG module "ietf-l3-unicast-topology". 114 To do so, it augments general network topology model defined in 115 [I-D.draft-ietf-i2rs-yang-network-topo] with information specific to 116 Layer 3 Unicast. This way, the general topology model is extended to 117 be able to meet the needs of Layer 3 Unicast topologies. 119 Information that is kept in the Traffic Engineering Database (TED) 120 will be specified in a separate model 121 [I-D.draft-ietf-teas-yang-te-topo] and outside the scope of this 122 specification. 124 2. Key Words 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 3. Definitions and Acronyms 134 As this document defines a YANG data model, in this document many 135 terms are used that have been defined in conjunction with YANG 136 [RFC7950] and NETCONF [RFC6241]. Some terms, such as datastore and 137 data tree, are repeated here for clarity and to put them in context. 139 Datastore: A conceptual store of instantiated management information, 140 with individual data items represented by data nodes which are 141 arranged in hierarchical manner. 143 Data subtree: An instantiated data node and the data nodes that are 144 hierarchically contained within it. 146 HTTP: Hyper-Text Transfer Protocol 148 IGP: Interior Gateway Protocol 150 IS-IS: Intermediate System to Intermediate System protocol 152 LSP: Label Switched Path 154 NETCONF: Network Configuration Protocol 156 NMDA: Network Management Datastore Architecture 158 OSPF: Open Shortest Path First, a link state routing protocol 160 URI: Uniform Resource Identifier 162 ReST: Representational State Transfer, a style of stateless interface 163 and protocol that is generally carried over HTTP 165 SRLG: Shared Risk Link Group 167 TED: Traffic Engineering Database 169 YANG: A data definition language for NETCONF 171 4. Model Structure 173 The Layer 3 Unicast topology model is defined by YANG module "l3- 174 unicast-topology". The relationship of this module with other YANG 175 modules is roughly depicted in the figure below. 177 +-----------------------------+ 178 | +-----------------------+ | 179 | | ietf-network | | 180 | +----------^------------+ | 181 | | | 182 | +-----------------------+ | 183 | | ietf-network-topology | | 184 | +----------+------------+ | 185 +-------------^---------------+ 186 | 187 | 188 +-----------^-------------+ 189 | L3-UNICAST-TOPOLOGY | 190 +----+------^--------+----+ 191 | 192 | 193 +-------^-------+ 194 | ospf-topology | 195 +---------------+ 197 Figure 1: Overall model structure 199 YANG modules "ietf-network" and "ietf-network-topology" collectively 200 define the basic network topology model. YANG module "ietf-l3- 201 unicast-topology" augments those models with additional definitions 202 needed to represent Layer 3 Unicast topologies. This module in turn 203 can be augmented by YANG modules with additional definitions for 204 specific types of Layer 3 Unicast topologies, such as OSPF and for 205 IS-IS topologies. 207 The YANG modules ietf-network and ietf-network are designed to be 208 used in conjunction with implementations that support the Network 209 Management Datastore Architecture (NMDA) defined in 210 [I-D.draft-ietf-netmod-revised-datastores]. Accordingly, the same is 211 true for the YANG modules that augment it. In order to allow 212 implementations to use the model even in cases when NMDA is not 213 supported, companion YANG modules (that SHOULD NOT be supported by 214 implementations that support NMDA) are defined in an Appendix, see 215 Appendix A. 217 5. Layer 3 Unicast Topology Model Overview 219 The Layer 3 Unicast topology model is defined by YANG module "ietf- 220 l3-unicast-topology". Its structure is depicted in the following 221 diagram. The notation syntax follows 222 [I-D.draft-ietf-netmod-yang-tree-diagrams]. For purposes of brevity, 223 notifications are not depicted. 225 module: ietf-l3-unicast-topology 226 augment /nd:networks/nd:network/nd:network-types: 227 +--rw l3-unicast-topology! 228 augment /nd:networks/nd:network: 229 +--rw l3-topology-attributes 230 +--rw name? string 231 +--rw flag* l3-flag-type 232 augment /nd:networks/nd:network/nd:node: 233 +--rw l3-node-attributes 234 +--rw name? inet:domain-name 235 +--rw flag* node-flag-type 236 +--rw router-id* inet:ip-address 237 +--rw prefix* [prefix] 238 +--rw prefix inet:ip-prefix 239 +--rw metric? uint32 240 +--rw flag* prefix-flag-type 241 augment /nd:networks/nd:network/lnk:link: 242 +--rw l3-link-attributes 243 +--rw name? string 244 +--rw flag* link-flag-type 245 +--rw metric1? uint64 246 +--rw metric2? uint64 247 augment /nd:networks/nd:network/nd:node/lnk:termination-point: 248 +--rw l3-termination-point-attributes 249 +--rw (termination-point-type)? 250 +--:(ip) 251 | +--rw ip-address* inet:ip-address 252 +--:(unnumbered) 253 | +--rw unnumbered-id? uint32 254 +--:(interface-name) 255 +--rw interface-name? string 257 The module augments the original ietf-network and ietf-network- 258 topology modules as follows: 260 o A new network topology type is introduced, l3-unicast-topology. 261 The corresponding container augments the network-types of the 262 ietf-network module. 264 o Additional topology attributes are introduced, defined in a 265 grouping, which augments the "network" list of the network module. 266 The attributes include a name for the topology, as well as a set 267 of flags (represented through a leaf-list). Each type of flag is 268 represented by a separate identity. This allows to introduce 269 additional flags in augmenting modules using additional identities 270 without needing to revise this module. 272 o Additional data objects for nodes are introduced by augmenting the 273 "node" list of the network module. New objects include again a 274 set of flags, as well as a list of prefixes. Each prefix in turn 275 includes an ip prefix, a metric, and a prefix-specific set of 276 flags. 278 o Links (in the ietf-network-topology module) are augmented with a 279 set of parameters as well, allowing to associate a link with a 280 link name, another set of flags, and a link metric. 282 o Termination points (in the ietf-network-topology module as well) 283 are augmented with a choice of IP address, identifier, or name. 285 In addition, the module defines a set of notifications to alert 286 clients of any events concerning links, nodes, prefixes, and 287 termination points. Each notification includes an indication of the 288 type of event, the topology from which it originated, and the 289 affected node, or link, or prefix, or termination point. In 290 addition, as a convenience to applications, additional data of the 291 affected node, or link, or termination point (respectively) is 292 included. While this makes notifications larger in volume than they 293 would need to be, it avoids the need for subsequent retrieval of 294 context information, which also might have changed in the meantime. 296 6. Layer 3 Unicast Topology YANG Module 298 file "ietf-l3-unicast-topology@2017-09-19.yang" 299 module ietf-l3-unicast-topology { 300 yang-version 1.1; 301 namespace 302 "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology"; 303 prefix "l3t"; 304 import ietf-network { 305 prefix "nd"; 306 } 307 import ietf-network-topology { 308 prefix "lnk"; 309 } 310 import ietf-inet-types { 311 prefix "inet"; 312 } 313 organization 314 "IETF I2RS (Interface to the Routing System) Working Group"; 315 contact 316 "WG Web: 317 WG List: 318 Editor: Alexander Clemm 319 321 Editor: Jan Medved 322 323 Editor: Robert Varga 324 325 Editor: Xufeng Liu 326 327 Editor: Nitin Bahadur 328 329 Editor: Hariharan Ananthakrishnan 330 "; 331 description 332 "This module defines a model for Layer 3 Unicast 333 topologies. 334 Copyright (c) 2017 IETF Trust and the persons identified as 335 authors of the code. All rights reserved. 336 Redistribution and use in source and binary forms, with or 337 without modification, is permitted pursuant to, and subject 338 to the license terms contained in, the Simplified BSD License 339 set forth in Section 4.c of the IETF Trust's Legal Provisions 340 Relating to IETF Documents 341 (http://trustee.ietf.org/license-info). 342 This version of this YANG module is part of 343 draft-ietf-i2rs-yang-l3-topology-11; 344 see the RFC itself for full legal notices. 345 NOTE TO RFC EDITOR: Please replace above reference to 346 draft-ietf-i2rs-yang-l3-topology-11 with RFC 347 number when published (i.e. RFC xxxx)."; 348 revision "2017-09-19" { 349 description 350 "Initial revision. 351 NOTE TO RFC EDITOR: Please replace the following reference 352 to draft-ietf-i2rs-yang-l3-topology-11 with 353 RFC number when published (i.e. RFC xxxx)."; 354 reference 355 "draft-ietf-i2rs-yang-l3-topology-11"; 356 } 358 identity flag-identity { 359 description "Base type for flags"; 360 } 362 typedef l3-event-type { 363 type enumeration { 364 enum "add" { 365 description 366 "An Layer 3 node or link or prefix or termination-point has 367 been added"; 368 } 369 enum "remove" { 370 description 371 "An Layer 3 node or link or prefix or termination-point has 372 been removed"; 373 } 374 enum "update" { 375 description 376 "An Layer 3 node or link or prefix or termination-point has 377 been updated"; 378 } 379 } 380 description "Layer 3 Event type for notifications"; 381 } 383 typedef prefix-flag-type { 384 type identityref { 385 base "flag-identity"; 386 } 387 description "Prefix flag attributes"; 388 } 390 typedef node-flag-type { 391 type identityref { 392 base "flag-identity"; 393 } 394 description "Node flag attributes"; 395 } 397 typedef link-flag-type { 398 type identityref { 399 base "flag-identity"; 400 } 401 description "Link flag attributes"; 402 } 404 typedef l3-flag-type { 405 type identityref { 406 base "flag-identity"; 407 } 408 description "L3 flag attributes"; 409 } 411 grouping l3-prefix-attributes { 412 description 413 "L3 prefix attributes"; 414 leaf prefix { 415 type inet:ip-prefix; 416 description 417 "IP prefix value"; 418 } 419 leaf metric { 420 type uint32; 421 description 422 "Prefix metric"; 423 } 424 leaf-list flag { 425 type prefix-flag-type; 426 description 427 "Prefix flags"; 428 } 429 } 430 grouping l3-unicast-topology-type { 431 description "Identify the topology type to be L3 unicast."; 432 container l3-unicast-topology { 433 presence "indicates L3 Unicast Topology"; 434 description 435 "The presence of the container node indicates L3 Unicast 436 Topology"; 437 } 438 } 439 grouping l3-topology-attributes { 440 description "Topology scope attributes"; 441 container l3-topology-attributes { 442 description "Containing topology attributes"; 443 leaf name { 444 type string; 445 description 446 "Name of the topology"; 447 } 448 leaf-list flag { 449 type l3-flag-type; 450 description 451 "Topology flags"; 452 } 453 } 454 } 455 grouping l3-node-attributes { 456 description "L3 node scope attributes"; 457 container l3-node-attributes { 458 description 459 "Containing node attributes"; 460 leaf name { 461 type inet:domain-name; 462 description 463 "Node name"; 464 } 465 leaf-list flag { 466 type node-flag-type; 467 description 468 "Node flags"; 469 } 470 leaf-list router-id { 471 type inet:ip-address; 472 description 473 "Router-id for the node"; 474 } 475 list prefix { 476 key "prefix"; 477 description 478 "A list of prefixes along with their attributes"; 479 uses l3-prefix-attributes; 480 } 481 } 482 } 483 grouping l3-link-attributes { 484 description 485 "L3 link scope attributes"; 486 container l3-link-attributes { 487 description 488 "Containing link attributes"; 489 leaf name { 490 type string; 491 description 492 "Link Name"; 493 } 494 leaf-list flag { 495 type link-flag-type; 496 description 497 "Link flags"; 498 } 499 leaf metric1 { 500 type uint64; 501 description 502 "Link Metric 1"; 503 } 504 leaf metric2 { 505 type uint64; 506 description 507 "Link Metric 2"; 508 } 509 } 510 } 511 grouping l3-termination-point-attributes { 512 description "L3 termination point scope attributes"; 513 container l3-termination-point-attributes { 514 description 515 "Containing termination point attributes"; 516 choice termination-point-type { 517 description 518 "Indicates the termination point type"; 519 case ip { 520 leaf-list ip-address { 521 type inet:ip-address; 522 description 523 "IPv4 or IPv6 address."; 524 } 525 } 526 case unnumbered { 527 leaf unnumbered-id { 528 type uint32; 529 description 530 "Unnumbered interface identifier. 531 The identifier will correspond to the ifIndex value 532 of the interface, i.e. the ifIndex value of the 533 ifEntry that represents the interface in 534 implementations where the Interfaces Group MIB 535 (RFC 2863) is supported."; 536 reference 537 "RFC 2863: The Interfaces Group MIB"; 538 } 539 } 540 case interface-name { 541 leaf interface-name { 542 type string; 543 description 544 "A name of the interface. The name can (but does not 545 have to) correspond to an interface reference of a 546 containing node's interface, i.e. the path name of a 547 corresponding interface data node on the containing 548 node reminiscent of data type if-ref defined in 549 RFC 7223. It should be noted that data type if-ref of 550 RFC 7223 cannot be used directly, as this data type 551 is used to reference an interface in a datastore of 552 a single node in the network, not to uniquely 553 reference interfaces across a network."; 554 } 555 } 556 } 557 } 558 } 559 augment "/nd:networks/nd:network/nd:network-types" { 560 description 561 "Introduce new network type for L3 unicast topology"; 562 uses l3-unicast-topology-type; 563 } 564 augment "/nd:networks/nd:network" { 565 when "nd:network-types/l3-unicast-topology" { 566 description 567 "Augmentation parameters apply only for networks with 568 L3 unicast topology"; 569 } 570 description 571 "L3 unicast for the network as a whole"; 572 uses l3-topology-attributes; 573 } 574 augment "/nd:networks/nd:network/nd:node" { 575 when "../nd:network-types/l3-unicast-topology" { 576 description 577 "Augmentation parameters apply only for networks with 578 L3 unicast topology"; 579 } 580 description 581 "L3 unicast node level attributes "; 582 uses l3-node-attributes; 583 } 584 augment "/nd:networks/nd:network/lnk:link" { 585 when "../nd:network-types/l3-unicast-topology" { 586 description 587 "Augmentation parameters apply only for networks with 588 L3 unicast topology"; 589 } 590 description 591 "Augment topology link attributes"; 592 uses l3-link-attributes; 593 } 594 augment "/nd:networks/nd:network/nd:node/" 595 +"lnk:termination-point" { 596 when "../../nd:network-types/l3-unicast-topology" { 597 description 598 "Augmentation parameters apply only for networks with 599 L3 unicast topology"; 600 } 601 description "Augment topology termination point configuration"; 602 uses l3-termination-point-attributes; 603 } 604 notification l3-node-event { 605 description 606 "Notification event for L3 node"; 607 leaf l3-event-type { 608 type l3-event-type; 609 description 610 "Event type"; 611 } 612 uses nd:node-ref; 613 uses l3-unicast-topology-type; 614 uses l3-node-attributes; 615 } 616 notification l3-link-event { 617 description 618 "Notification event for L3 link"; 619 leaf l3-event-type { 620 type l3-event-type; 621 description 622 "Event type"; 623 } 624 uses lnk:link-ref; 625 uses l3-unicast-topology-type; 626 uses l3-link-attributes; 627 } 628 notification l3-prefix-event { 629 description 630 "Notification event for L3 prefix"; 631 leaf l3-event-type { 632 type l3-event-type; 633 description 634 "Event type"; 635 } 636 uses nd:node-ref; 637 uses l3-unicast-topology-type; 638 container prefix { 639 description 640 "Containing L3 prefix attributes"; 641 uses l3-prefix-attributes; 642 } 643 } 644 notification termination-point-event { 645 description 646 "Notification event for L3 termination point"; 647 leaf l3-event-type { 648 type l3-event-type; 649 description 650 "Event type"; 651 } 652 uses lnk:tp-ref; 653 uses l3-unicast-topology-type; 654 uses l3-termination-point-attributes; 655 } 656 } 657 659 7. Interactions with Other YANG Modules 661 As described in section Section 4, the model builds on top of, and 662 augments, the YANG modules defined in 663 [I-D.draft-ietf-i2rs-yang-network-topo]. Specifically, module ietf- 664 l3-unicast-topology augments modules "ietf-network" and "ietf- 665 network-topology". In addition, the model makes use of data types 666 that have been defined in [RFC6991]. 668 The moodel defines a protocol independent YANG data model with layer 669 3 topology information. It is separate from and not linked with data 670 models that are used to configure routing protocols or routing 671 information. This includes e.g. model "ietf-routing" [RFC8022] and 672 model "ietf-fb-rib" [I-D.draft-acee-rtgwg-yang-rib-extend]. 674 The model obeys the requirements for the ephemeral state found in the 675 document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral 676 topology data that is server provided, the process tasked with 677 maintaining topology information will load information from the 678 routing process (such as OSPF) into the data model without relying on 679 a configuration datastore. 681 8. IANA Considerations 683 This document registers the following namespace URIs in the "IETF XML 684 Registry" [RFC3688]: 686 URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology 687 Registrant Contact: The IESG. 688 XML: N/A; the requested URI is an XML namespace. 690 URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state 691 Registrant Contact: The IESG. 692 XML: N/A; the requested URI is an XML namespace. 694 This document registers the following YANG modules in the "YANG 695 Module Names" registry [RFC6020]: 697 Name: ietf-l3-unicast-topology 698 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology 699 Prefix: l3t 700 Reference: draft-ietf-i2rs-yang-l3-topology-11.txt (RFC form) 702 Name: ietf-l3-unicast-topology-state 703 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state 704 Prefix: l3t-s 705 Reference: draft-ietf-i2rs-yang-l3-topology-11.txt (RFC form) 707 9. Security Considerations 709 The YANG module defined in this document is designed to be accessed 710 via network management protocols such as NETCONF [RFC6241] or 711 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 712 layer, and the mandatory-to-implement secure transport is Secure 713 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 714 mandatory-to-implement secure transport is TLS [RFC5246]. 716 The NETCONF access control model [RFC6536] provides the means to 717 restrict access for particular NETCONF or RESTCONF users to a 718 preconfigured subset of all available NETCONF or RESTCONF protocol 719 operations and content. 721 In general, Layer 3 Unicast topologies are system-controlled and 722 provide ephemeral topology information. In an NMDA-complient server, 723 they are only part of which provides read-only access 724 to clients, they are less vulnerable. That said, the YANG module 725 does in principle allow information to be configurable. 727 There are a number of data nodes defined in this YANG module that are 728 writable/creatable/deletable (i.e., config true, which is the 729 default). These data nodes may be considered sensitive or vulnerable 730 in some network environments. Write operations (e.g., edit-config) 731 to these data nodes without proper protection can have a negative 732 effect on network operations. These are the subtrees and data nodes 733 and their sensitivity/vulnerability in the ietf-network module: 735 l3-topology-attributes: A malicious client could attempt to 736 sabotage the configuration of any of the ctonained attributes, 737 i.e. the name or the flag data nodes. 739 l3-node-attributes: A malicious client could attempt to sabotage 740 the configuration of important node attributes, such as the 741 router-id or node prefix. 743 l3-link-attributes: A malicious client could attempt to sabotage 744 the configuration of important link attributes, such as name, 745 flag, and metrics of the link respectively corresponding data 746 nodes. 748 l3-termination-point-attributes: A malicious client could attempt 749 to sabotage the configuration information of a termination point, 750 such as its ip-address and interface name, respectively the 751 corresponding data nodes. 753 10. Contributors 755 The model presented in this document was contributed to by more 756 people than can be listed on the author list. Additional 757 contributors include: 759 o Vishnu Pavan Beeram, Juniper 761 o Igor Bryskin, Huawei 763 o Ken Gray, Cisco 765 o Aihua Guo, Huawei 767 o Tom Nadeau, Brocade 769 o Tony Tkacik 771 o Aleksandr Zhdankin, Cisco 773 11. Acknowledgements 775 We wish to acknowledge the helpful contributions, comments, and 776 suggestions that were received from Alia Atlas, Andy Bierman, Benoit 777 Claise, Joel Halpern, Susan Hares, Ladislav Lhotka, Carl Moberg, 778 Carlos Pignataro, Juergen Schoenwaelder, and Kent Watsen. 780 12. References 782 12.1. Normative References 784 [I-D.draft-ietf-i2rs-yang-network-topo] 785 Clemm, A., Medved, J., Varga, R., Bahadur, N., 786 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 787 Network Topologies", I-D draft-ietf-i2rs-yang-network- 788 topo-16, September 2017. 790 [I-D.draft-ietf-netmod-revised-datastores] 791 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 792 and R. Wilton, "A Revised Conceptual Model for YANG 793 Datastores", I-D draft-ietf-netmod-revised-datastores-02, 794 May 2017. 796 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 797 Dual Environments", RFC 1195, December 1990. 799 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 800 requirement levels", RFC 2119, March 1997. 802 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 804 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 805 MIB", RFC 2863, June 2000. 807 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 808 2004. 810 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 811 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 813 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 814 Network Configuration Protocol (NETCONF)", RFC 6020, 815 October 2010. 817 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 818 Bierman, "Network Configuration Protocol (NETCONF)", 819 RFC 6241, June 2011. 821 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 822 Shell (SSH)", RFC 6242, June 2011. 824 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 825 Protocol (NETCONF) Access Control Model", RFC 6536, March 826 2012. 828 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 829 July 2013. 831 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 832 RFC 7950, August 2016. 834 12.2. Informative References 836 [I-D.draft-acee-rtgwg-yang-rib-extend] 837 Lindem, A. and Y. Qu, "YANG Data Model for RIB 838 Extensions", I-D draft-acee-rtgwg-yang-rib-extend-02, 839 October 2016. 841 [I-D.draft-ietf-i2rs-ephemeral-state] 842 Haas, J. and S. Hares, "I2RS Ephemeral State 843 Requirements", I-D draft-ietf-i2rs-ephemeral-state-23, 844 November 2016. 846 [I-D.draft-ietf-i2rs-usecase-reqs-summary] 847 Hares, S. and M. Chen, "Summary of I2RS Use Case 848 Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- 849 03, November 2016. 851 [I-D.draft-ietf-netmod-yang-tree-diagrams] 852 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", I-D 853 draft-ietf-netmod-yang-tree-diagrams, June 2017. 855 [I-D.draft-ietf-teas-yang-te-topo] 856 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 857 O. Gonzalez De Dios, "YANG Data Model for TE Topologies", 858 I-D draft-ietf-teas-yang-te-topo-09, June 2017. 860 [RFC7223] Bjorklund, M., "A YANG Data Model for Routing Management", 861 RFC 7223, May 2014. 863 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 864 Management", RFC 8022, November 2016. 866 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 867 Protocol", RFC 8040, January 2017. 869 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 870 2119 Key Words", RFC 8174, May 2017. 872 Appendix A. Companion YANG model for non-NMDA compliant implementations 874 The YANG module ietf-l3-unicast-topology defined in this document 875 augments two modules, ietf-network and ietf-network-topology, that 876 are designed to be used in conjunction with implementations that 877 support the Network Management Datastore Architecture (NMDA) defined 878 in [I-D.draft-ietf-netmod-revised-datastores]. In order to allow 879 implementations to use the model even in cases when NMDA is not 880 supported, a set of companion modules have been defined that 881 represent a state model of networks and network topologies, ietf- 882 network-state and ietf-network-topology-state, respectively. 884 In order to be able to use the model for layer 3 topologies defined 885 in this in this document in conjunction with non-NMDA compliant 886 implementations, a corresponding companion module needs to be 887 introduced as well. This companion module, ietf-l3-unicast-topology- 888 state, mirrors ietf-l3-unicast-topology. However, the module 889 augments ietf-network-state and ietf-network-topology-state (instead 890 of ietf-network and ietf-network-state) and all of its data nodes are 891 non-configurable. 893 Similar considerations apply for any modules that augment ietf-l3- 894 unicast-topology, such as the example modules defined in see 895 Appendix B, example-ietf-ospf-topology. For non-NMDA compliant 896 implementations, companion modules will need to be introduced that 897 represent state information and are non-configurable, augmenting 898 ietf-l3-unicast-topology-state instead of ietf-l3-unicast-topology. 899 Because they served as examples only, companion modules for those 900 examples are not given. 902 Like ietf-network-state and ietf-network-topology-state, ietf-l3- 903 unicast-topology SHOULD NOT be supported by implementations that 904 support NMDA. It is for this reason that the module is defined in 905 the Appendix. 907 The definition of the module follows below. As the structure of the 908 module mirrors that of its underlying module, the YANG tree is not 909 depicted separately. 911 file "ietf-l3-unicast-topology-state@2017-09-19.yang" 912 module ietf-l3-unicast-topology-state { 913 yang-version 1.1; 914 namespace 915 "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state"; 916 prefix "l3t-s"; 917 import ietf-network-state { 918 prefix "nd-s"; 919 } 920 import ietf-network-topology-state { 921 prefix "lnk-s"; 922 } 923 import ietf-l3-unicast-topology { 924 prefix "l3t"; 925 } 926 organization 927 "IETF I2RS (Interface to the Routing System) Working Group"; 928 contact 929 "WG Web: 930 WG List: 931 Editor: Alexander Clemm 932 933 Editor: Jan Medved 934 935 Editor: Robert Varga 936 937 Editor: Xufeng Liu 938 939 Editor: Nitin Bahadur 940 941 Editor: Hariharan Ananthakrishnan 942 "; 943 description 944 "This module defines a model for Layer 3 Unicast topology 945 state, representing topology that is either learned, or topology 946 that results from applying topology that has been configured per 947 the ietf-l3-unicast-topology model, mirroring the corresponding 948 data nodes in this model. 950 The model mirrors ietf-l3-unicast-topology, but contains only 951 read-only state data. The model is not needed when the 952 underlying implementation infrastructure supports the Network 953 Management Datastore Architecture (NMDA). 955 Copyright (c) 2017 IETF Trust and the persons identified as 956 authors of the code. All rights reserved. 957 Redistribution and use in source and binary forms, with or 958 without modification, is permitted pursuant to, and subject 959 to the license terms contained in, the Simplified BSD License 960 set forth in Section 4.c of the IETF Trust's Legal Provisions 961 Relating to IETF Documents 962 (http://trustee.ietf.org/license-info). 963 This version of this YANG module is part of 964 draft-ietf-i2rs-yang-l3-topology-11; 965 see the RFC itself for full legal notices. 966 NOTE TO RFC EDITOR: Please replace above reference to 967 draft-ietf-i2rs-yang-l3-topology-11 with RFC 968 number when published (i.e. RFC xxxx)."; 969 revision "2017-09-19" { 970 description 971 "Initial revision. 972 NOTE TO RFC EDITOR: Please replace the following reference 973 to draft-ietf-i2rs-yang-l3-topology-11 with 974 RFC number when published (i.e. RFC xxxx)."; 975 reference 976 "draft-ietf-i2rs-yang-l3-topology-11"; 977 } 979 augment "/nd-s:networks/nd-s:network/nd-s:network-types" { 980 description 981 "Introduce new network type for L3 unicast topology"; 982 uses l3t:l3-unicast-topology-type; 983 } 984 augment "/nd-s:networks/nd-s:network" { 985 when "nd-s:network-types/l3-unicast-topology" { 986 description 987 "Augmentation parameters apply only for networks with 988 L3 unicast topology"; 989 } 990 description 991 "L3 unicast for the network as a whole"; 992 uses l3t:l3-topology-attributes; 993 } 994 augment "/nd-s:networks/nd-s:network/nd-s:node" { 995 when "../nd-s:network-types/l3-unicast-topology" { 996 description 997 "Augmentation parameters apply only for networks with 998 L3 unicast topology"; 999 } 1000 description 1001 "L3 unicast node level attributes "; 1002 uses l3t:l3-node-attributes; 1003 } 1004 augment "/nd-s:networks/nd-s:network/lnk-s:link" { 1005 when "../nd-s:network-types/l3-unicast-topology" { 1006 description 1007 "Augmentation parameters apply only for networks with 1008 L3 unicast topology"; 1009 } 1010 description 1011 "Augment topology link attributes"; 1012 uses l3t:l3-link-attributes; 1013 } 1014 augment "/nd-s:networks/nd-s:network/nd-s:node/" 1015 +"lnk-s:termination-point" { 1017 when "../../nd-s:network-types/l3-unicast-topology" { 1018 description 1019 "Augmentation parameters apply only for networks with 1020 L3 unicast topology"; 1021 } 1022 description "Augment topology termination point configuration"; 1023 uses l3t:l3-termination-point-attributes; 1024 } 1025 notification l3-node-event { 1026 description 1027 "Notification event for L3 node"; 1028 leaf l3-event-type { 1029 type l3t:l3-event-type; 1030 description 1031 "Event type"; 1032 } 1033 uses nd-s:node-ref; 1034 uses l3t:l3-unicast-topology-type; 1035 uses l3t:l3-node-attributes; 1036 } 1037 notification l3-link-event { 1038 description 1039 "Notification event for L3 link"; 1040 leaf l3-event-type { 1041 type l3t:l3-event-type; 1042 description 1043 "Event type"; 1044 } 1045 uses lnk-s:link-ref; 1046 uses l3t:l3-unicast-topology-type; 1047 uses l3t:l3-link-attributes; 1048 } 1049 notification l3-prefix-event { 1050 description 1051 "Notification event for L3 prefix"; 1052 leaf l3-event-type { 1053 type l3t:l3-event-type; 1054 description 1055 "Event type"; 1056 } 1057 uses nd-s:node-ref; 1058 uses l3t:l3-unicast-topology-type; 1059 container prefix { 1060 description 1061 "Containing L3 prefix attributes"; 1062 uses l3t:l3-prefix-attributes; 1063 } 1064 } 1065 notification termination-point-event { 1066 description 1067 "Notification event for L3 termination point"; 1068 leaf l3-event-type { 1069 type l3t:l3-event-type; 1070 description 1071 "Event type"; 1072 } 1073 uses lnk-s:tp-ref; 1074 uses l3t:l3-unicast-topology-type; 1075 uses l3t:l3-termination-point-attributes; 1076 } 1077 } 1079 1081 Appendix B. Extending the Model 1083 The model can be extended for specific Layer 3 Unicast types. 1084 Examples include OSPF and IS-IS topologies. In the following, one 1085 additional YANG module is introduced that define simple topology 1086 model for OSPF. This module is intended to serve as an example that 1087 illustrates how the general topology model can be refined across 1088 multiple levels. It does not constitute full-fledged OSPF topology 1089 model which may be more comprehensive and refined than the model that 1090 is described here. 1092 B.1. Example OSPF Topology 1094 B.1.1. Model Overview 1096 The following model shows how the Layer 3 Unicast topology model can 1097 be extended to cover OSFP topologies. For this purpose, a set of 1098 augmentations are introduced in a separate YANG module, "example- 1099 ietf-ospf-topology", whose structure is depicted in the following 1100 diagram. As before, the notation syntax follows 1101 [I-D.draft-ietf-netmod-yang-tree-diagrams]. 1103 module: example-ietf-ospf-topology 1104 augment /nd:networks/nd:network/nd:network-types/l3t:l3-unicast-topology: 1105 +--rw ospf! 1106 augment /nd:networks/nd:network/l3t:l3-topology-attributes: 1107 +--rw ospf-topology-attributes 1108 +--rw area-id? area-id-type 1109 augment /nd:networks/nd:network/nd:node/l3t:l3-node-attributes: 1110 +--rw ospf-node-attributes 1111 +--rw (router-type)? 1112 | +--:(abr) 1113 | | +--rw abr? empty 1114 | +--:(asbr) 1115 | | +--rw asbr? empty 1116 | +--:(internal) 1117 | | +--rw internal? empty 1118 | +--:(pseudonode) 1119 | +--rw pseudonode? empty 1120 +--rw dr-interface-id? uint32 1121 augment /nd:networks/nd:network/lnk:link/l3t:l3-link-attributes: 1122 +--rw ospf-link-attributes 1123 augment /l3t:l3-node-event: 1124 +---- ospf! 1125 +---- ospf-node-attributes 1126 +---- (router-type)? 1127 | +--:(abr) 1128 | | +---- abr? empty 1129 | +--:(asbr) 1130 | | +---- asbr? empty 1131 | +--:(internal) 1132 | | +---- internal? empty 1133 | +--:(pseudonode) 1134 | +---- pseudonode? empty 1135 +---- dr-interface-id? uint32 1136 augment /l3t:l3-link-event: 1137 +---- ospf! 1138 +---- ospf-link-attributes 1140 The module augments "ietf-l3-unicast-topology" as follows: 1142 o A new topology type for an OSPF topology is introduced. 1144 o Additional topology attributes are defined in a new grouping which 1145 augments l3-topology-attributes of the ietf-l3-unicast-topology 1146 module. The attributes include an OSPF area-id identifying the 1147 OSPF area. 1149 o Additional data objects for nodes are introduced by augmenting the 1150 l3-node-attributes of the l3-unicast-topology module. New objects 1151 include router-type and dr-interface-id for pseudonodes. 1153 o Links are augmented with ospf link attributes. 1155 In addition, the module extends notifications for events concerning 1156 Layer 3 nodes and links with OSPF attributes. 1158 It should be noted that the model defined here represents topology 1159 and is intended as an example. It does not define how to configure 1160 OSPF routers or interfaces. 1162 B.1.2. OSPF Topology YANG Module 1164 The OSPF Topology YANG Module is specified below. As mentioned, the 1165 module is intended as an example for how the Layer 3 Unicast topology 1166 model can be extended to cover OSFP topologies, but it is not 1167 normative. Accordingly, the module is not delimited with CODE BEGINS 1168 and CODE ENDS tags. 1170 file "example-ietf-ospf-topology@2017-09-19.yang" 1171 module example-ietf-ospf-topology { 1172 yang-version 1.1; 1173 namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology"; 1174 prefix "ospft"; 1175 import ietf-yang-types { 1176 prefix "yang"; 1177 } 1178 import ietf-network { 1179 prefix "nd"; 1180 } 1181 import ietf-network-topology { 1182 prefix "lnk"; 1183 } 1184 import ietf-l3-unicast-topology { 1185 prefix "l3t"; 1186 } 1187 organization 1188 "IETF I2RS (Interface to the Routing System) Working Group"; 1189 contact 1190 "WG Web: 1191 WG List: 1192 Editor: Alexander Clemm 1193 1194 Editor: Jan Medved 1195 1196 Editor: Robert Varga 1197 1198 Editor: Xufeng Liu 1199 1200 Editor: Nitin Bahadur 1201 1202 Editor: Hariharan Ananthakrishnan 1203 "; 1204 description 1205 "This module defines a model for OSPF network topologies. 1206 Copyright (c) 2017 IETF Trust and the persons identified as 1207 authors of the code. All rights reserved. 1208 Redistribution and use in source and binary forms, with or 1209 without modification, is permitted pursuant to, and subject 1210 to the license terms contained in, the Simplified BSD License 1211 set forth in Section 4.c of the IETF Trust's Legal Provisions 1212 Relating to IETF Documents 1213 (http://trustee.ietf.org/license-info). 1214 This version of this YANG module is part of 1215 draft-ietf-i2rs-yang-l3-topology-11; 1216 see the RFC itself for full legal notices. 1217 NOTE TO RFC EDITOR: Please replace above reference to 1218 draft-ietf-i2rs-yang-l3-topology-11 with RFC 1219 number when published (i.e. RFC xxxx)."; 1220 revision "2017-09-19" { 1221 description 1222 "Initial revision. 1223 NOTE TO RFC EDITOR: Please replace the following reference 1224 to draft-ietf-i2rs-yang-l3-topology-11 with 1225 RFC number when published (i.e. RFC xxxx)."; 1226 reference 1227 "draft-ietf-i2rs-yang-l3-topology-11"; 1228 } 1229 typedef area-id-type { 1230 type yang:dotted-quad; 1231 description 1232 "Area ID type."; 1233 } 1234 grouping ospf-topology-type { 1235 description 1236 "Identifies the OSPF topology type."; 1237 container ospf { 1238 presence "indiates OSPF Topology"; 1239 description 1240 "Its presence identifies the OSPF topology type."; 1241 } 1242 } 1243 augment "/nd:networks/nd:network/nd:network-types/" 1244 + "l3t:l3-unicast-topology" { 1245 description 1246 "Defines the OSPF topology type."; 1247 uses ospf-topology-type; 1248 } 1249 augment "/nd:networks/nd:network/l3t:l3-topology-attributes" { 1250 when "../nd:network-types/l3t:l3-unicast-topology/ospf" { 1251 description 1252 "Augment only for OSPF topology"; 1253 } 1254 description 1255 "Augment topology configuration"; 1256 container ospf-topology-attributes { 1257 description 1258 "Containing topology attributes"; 1259 leaf area-id { 1260 type area-id-type; 1261 description 1262 "OSPF area ID"; 1263 } 1264 } 1265 } 1266 augment "/nd:networks/nd:network/nd:node/l3t:l3-node-attributes" { 1267 when "../../nd:network-types/l3t:l3-unicast-topology/ospf" { 1268 description 1269 "Augment only for OSPF topology"; 1270 } 1271 description 1272 "Augment node configuration"; 1273 uses ospf-node-attributes; 1274 } 1275 augment "/nd:networks/nd:network/lnk:link/l3t:l3-link-attributes" { 1276 when "../../nd:network-types/l3t:l3-unicast-topology/ospf" { 1277 description 1278 "Augment only for OSPF topology"; 1279 } 1280 description 1281 "Augment link configuration"; 1282 uses ospf-link-attributes; 1283 } 1284 grouping ospf-node-attributes { 1285 description 1286 "OSPF node scope attributes"; 1287 container ospf-node-attributes { 1288 description 1289 "Containing node attributes"; 1290 choice router-type { 1291 description 1292 "Indicates router type"; 1294 case abr { 1295 leaf abr { 1296 type empty; 1297 description 1298 "The node is ABR"; 1299 } 1300 } 1301 case asbr { 1302 leaf asbr { 1303 type empty; 1304 description 1305 "The node is ASBR"; 1306 } 1307 } 1308 case internal { 1309 leaf internal { 1310 type empty; 1311 description 1312 "The node is internal"; 1313 } 1314 } 1315 case pseudonode { 1316 leaf pseudonode { 1317 type empty; 1318 description 1319 "The node is pseudonode"; 1320 } 1321 } 1322 } 1323 leaf dr-interface-id { 1324 when "../pseudonode" { 1325 description 1326 "Valid only for pseudonode"; 1327 } 1328 type uint32; 1329 default "0"; 1330 description 1331 "For pseudonodes, DR interface-id"; 1332 } 1333 } 1334 } 1335 grouping ospf-link-attributes { 1336 description 1337 "OSPF link scope attributes"; 1338 container ospf-link-attributes { 1339 description 1340 "Containing OSPF link attributes"; 1341 } 1343 } // ospf-link-attributes 1344 augment "/l3t:l3-node-event" { 1345 description 1346 "OSPF node event"; 1347 uses ospf-topology-type; 1348 uses ospft:ospf-node-attributes; 1349 } 1350 augment "/l3t:l3-link-event" { 1351 description 1352 "OSPF link event"; 1353 uses ospf-topology-type; 1354 uses ospft:ospf-link-attributes; 1355 } 1356 } 1358 Authors' Addresses 1360 Alexander Clemm 1361 Huawei 1363 EMail: ludwig@clemm.org 1365 Jan Medved 1366 Cisco 1368 EMail: jmedved@cisco.com 1370 Robert Varga 1371 Pantheon Technologies SRO 1373 EMail: robert.varga@pantheon.sk 1375 Xufeng Liu 1376 Ericsson 1378 EMail: xliu@kuatrotech.com 1380 Hariharan Ananthakrishnan 1381 Packet Design 1383 EMail: hari@packetdesign.com 1384 Nitin Bahadur 1385 Bracket Computing 1387 EMail: nitin_bahadur@yahoo.com