| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
-----Original Message-----
From: Raj Sharma [mailto:raj@xxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, January 04, 2001 2:48 PM
To: Albert Herrera
Cc: Raj Sharma; Prasad Jogalekar; Sanjay Agrawal; Arun Sastry; 'Russ White'; 'jfu@xxxxxxxxxxxxxxx'; 'Khaled Amer'; Frank Kastenholz; 'Pankaj K Jha'; stds-802-rprsg@xxxxxxxx
Subject: RE: Bridge codeAlbert,I think it would be best if we addressed the framework document for now.As far as what IPORPR should indicate to IEEE 802.17 WG as expectationsand opportunities I think a summary of the framework document in slide form wouldsuffice for now. However, the framework documnet comes across as jibberish andneeds work. We need to work on this immediately to earn our IETF breadLet me give the team some food for thought pertaining to the framework document.Section 3.1The goals and objective of the IPORPR WG should not be made a part of a "framework"document. This is a charter and scope issue of the WG. The spirit of the 1st paragraphis well intended but is irrelevant within the context of a framework document. I suggestyou delete this paragraph.Your claim that current network layer treats these rings as a broadcast capable LAN mediais too preassumptious. I am assuming "these rings" imply RPR.What additional layer 3 intelligence will alter destination stripping in RPR?Once a unicast Layer 2 RPR frame is formed the packet is stripped off the ringby the destination. It is that simple. Multicast and broadcast will follow the 802guidelines for group address mappings.My suggestion is that 3.1 be called "overview of RPR". This is where we shoulddescribe the basic operation of RPR and establish to IEEE of what behavior Layer 3expects of RPR.Section 3.2How many "link" layers are there that makes forwarding decisions on Layer 3administrative weights? If this is a requirment then a short rationale is warranted.As stated it appears more like a solution waiting for a problem.Traffic engineering support in RPR must support ALL traffic engineering extensions.Picking MPLS-TE sounds too specific. Why not RSVP-TE. I have no preference forany, but just simply stating one looks like we havent given this enough thought.Section 3.2 must fully address ALL requirments of layer 3 of a link layer. This shouldinclude ARP and RARP capabilities, broadcast/multicast support. In fact, ARP responsesand multicast support opens up some novel issues in RPR.IPoRPR is not a protocol but the name of a WG (or maybe one) in IETF. The last 3 bulletsdoes nothing more than fill spaces in the document.Section 3.4The first paragraph should perhaps belong in section 3.1 that introduces RPRlink layer technology.The second paragraph is a "duh". Ethernet too is made up of point to point physicallinks and appears as a bradcast media to Layer 3. So why should that be a surprise'in RPR or cause for special consideration?The last paragraph of 3.4 blows RPR IEEE efforts out of the water. According to thisparagraph if a ring spans consisted of SONET links than one would like layer 3 tobe aware of this (gory) details of such a topology to make layer 3 forwarding decisions.The point made here is that there is NO NEED FOR RPR (a data link layer).I must say that there are somethings to be read between the lines here. First of all,not all boxes sitting on an RPR ring will be a router. I am sure router vendors wouldshrivel at that thought. Hence Layer 2 topology and layer 3 topology are two seperateissues. Now if one only wishes to put routers on a ring than once can use either RPRor just point -2-point SONET links. However, RPR cannot assume that all boxes onthe ring are routers.Section 3.4.1This section pointificates that there are benefits in synchronizing L2 and L3 routingcost metrics. But why ?Section 3.4.2I am lost and my simple mind cannot fathom this deep thought of how L2 AND L3 cost metricsare closely tied to Layer 3 adjacency. Perhaps, this goes back to the preassumption of routerson a ring !Look, there is no meat in this document. We better focus ourselves in doing this beforewe jump the gun on changing routing protocols.
[Raj Sharma]-----Original Message-----
From: Pankaj K Jha [mailto:pkj@xxxxxxxxxxx]
Sent: Thursday, January 04, 2001 11:18 AM
To: Albert Herrera
Cc: Raj Sharma; Prasad Jogalekar; Sanjay Agrawal; Arun Sastry; 'Russ White'; 'jfu@xxxxxxxxxxxxxxx'; 'Khaled Amer'; Frank Kastenholz
Subject: Re: Bridge codeDear Albert:I think what you suggest is related to IPoRPR, not what IEEE RPR is concerned with. Also, what we have here is a framework document for L2/L3 work. We need to discuss what specific scopes & issues we are going to raise at RPR. We cannot go to RPR and just announce that IPoRPR has been formed. We have to come up with specifics that RPR can consider in its scope.
So let us consider what points are. If we cannot come up with something today, chances are low that we can come up with points spontaneously while on the phone tomorrow.
Regards,
PankajAlbert Herrera wrote:
I would suggest we go through the attached Framework and
come up with expansions to specific sections. In particular, the
Technical approaches.We might also want to outline a position to 802.17 as to what we
need and what we expect.We might also want to discuss the joint extensions-to-routing
document that's in progress. Just a reminder that this cannot be a
WG document given that our charter only mandates a framework.
I'm sure we can still submit as joint individual to the routing area
for feedback.Albert
Raj Sharma wrote:
What is the agenda for tomorrow's call?
-----Original Message-----
From: Pankaj K Jha [mailto:pkj@xxxxxxxxxxx]
Sent: Friday, December 22, 2000 4:33 PM
To: Albert Herrera
Cc: Raj Sharma; Prasad Jogalekar; Sanjay Agrawal; Arun Sastry; 'Russ
White'; 'jfu@xxxxxxxxxxxxxxx'; 'Khaled Amer'; Frank Kastenholz
Subject: Bridge codeTeam:
Here is the bridge code for dialing in on January 5:
Dial 408 943 2496. When asked for a conference code, enter 5409.
In case (and only in case, to save our phone line charges) the 408 943
2496 number does not work, or is busy, feel free to use800 541 2158 Bridge 5409
Should you have any difficulty, call me at my cellphone at 510 589 3428.
Regards,
Pankaj
Network Working Group Albert Herrera Internet Draft Russ White draft-ietf-iporpr-framework-00.txt Cisco Systems Expiration Date: June, 2001 Pankaj K. Jha Cypress Semiconductor Raj Sharma Sanjay Agrawal Prasad Jogalekar Arun Sastry Luminous Networks Khaled Amer AmerNet December, 2000 A Framework for IP over Resilient Packet Rings <draft-ietf-iporpr-framework-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Herrera, et al Expires June, 2001 [Page 1] INTERNET-DRAFT A Framework for IP over RPR November, 2000 1. Abstract This document discusses technical issues and requirements for the IP over Packet Transport Rings working group. It is the intent of this document to produce a coherent description of all significant approaches, which were and are being considered by the working group. Selections of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. 2. Acknowledgments The ideas and text in this document have been collected from a number of sources and comments received. We would like to thank Alvaro Retana, Don Slice, Liem Nyueng, Jason Fan, Vinay Bannai for their inputs and ideas. 3. Introduction and Requirements 3.1 Overview of IPoRPR The primary goal of the IPoRPR Working Group is to standardize a base technology that integrates RPR (Resilient Packet Rings) MAC functions as defined by the IEEE 802.17 Working Group with network layer routing. The IPoRPR working group expects to optimize packet transport over rings on LAN, MAN and WAN topologies. Current network layer routing treats these rings as a broadcast capable LAN media similar to Ethernet. IPoRPR will enable additional Layer 3 intelligence to fully utilize MAC features, such as destination stripping and protection switching, to improve efficiencies and scalability at the network layer 3.2 Requirements o L3 protocols MAY need the option to communicate administrative weights to RPR. o L3 protocols MAY need to have the option to choose the ring direction. o L3 protocols MAY need to have knowledge of the fault occurrences within the ring o Traffic Engineering specifications MUST support MPLS-TE over RPR. o L3 and MPLS QoS mappings MAY need to be communicated to RPR QoS Herrera, et al Expires June, 2001 [Page 2] INTERNET-DRAFT A Framework for IP over RPR November, 2000 mechanisms o IPoRPR MUST address a wide range of routing protocols. Considerable optimizations can be achieved in some cases by small enhancements to existing protocols. Such enhancements MAY be considered in the case of IETF standard routing protocols, and if appropriate, coordinated with the relevant working group(s). o IPoRPR MUST support operations, administration, and maintenance facilities that are at least as extensive as those supported in current IP networks. Current network management and diagnostic tools SHOULD continue to work in order to provide some backward compatibility. o The IPoRPR should scale across hierarchical networks. 3.3 Acronyms and Abbreviations LSP Label Switched Path LSR Label Switch Router NBMA Non-Broadcast Multiple Access network RPR Resilient Packet Rings (IEEE802.17) MPLS Multi-Protocol Label Switching 3.4 Motivation for IPoRPR The evolution of Metro access networks has driven the industry to develop a new IEEE WG called RPR. This defines a MAC layer that has to be integrated to the upper layer protocols. This allows additional mechanisms and support for Traffic Engineering, routing, QoS and fast protection switching. This section describes the expected benefits of IPoRPR. At the physical layer, RPR looks like a set of point-to-point spans while at the datalink layer it appears to be a broadcast media LAN (equivalent to Ethernet, for instance). While current link-state routing protocols provide various media access models, such broadcast, point-to-point, and point-to multipoint, none of the existing models can fully exploit the benefits RPR has to offer. IPoRPR will define a logical model that closely reflects the underlying physical model and in the process enable routing protocols to directly utilize features not available in other ring topologies. Herrera, et al Expires June, 2001 [Page 3] INTERNET-DRAFT A Framework for IP over RPR November, 2000 3.4.1 Benefits Related to Cost Metrics Awareness There are benefits associated with synchronizing L2 and L3 routing cost metrics as per different policies. RPR, at the MAC layer, implements its own topology discovery mechanism within a single ring implementation. This involves tracking source/destination MAC addresses and utilizing the different matrices, including number of hops, to determine the most efficient ring direction (inner or outer) for delivery of unicast packets. In networks such as this, then, communicating layer 3 metrics to the MAC layer, and vise-versa, can optimize packet delivery--especially in topologies with dramatic differences in node distances and costs. 3.4.2 Benefits Related to Adjacency Awareness Adjacency awareness is closely tied to the cost metrics interaction between L2 and L3. 3.4.3 Benefits Related to TE/Explicit Routing/QoS Routing Support RPR has inherent abilities to re-route around faults. It can be exploited by TE protocols to route tunnels across these rings. To take full advantage of RPR, TE must manage bandwidth on both the inner and outer ring. This enables proper accounting at each node and allows for full Traffic Engineering capabilities within the ring. MPLS allows explicit routing of Label Switched Paths to ensure that any particular stream of data takes a preferred path. This preferred path could be the long-path around the ring towards a destination node. This same mechanism will enable QoS Routing in which the route chosen for a particular stream is chosen in response to the QoS required. 4. Technical Approaches Technical approaches for IPoRPR may have to address policy management, QoS, Traffic Engineering, L2/L3 fault interaction and L3 routing. Future contributions will address these mechanisms in detail with appropriate assumptions in conjunction with the evolving RPR specification. Given the work-in-progress nature of RPR, individual contributions may have to address different assumptions. Herrera, et al Expires June, 2001 [Page 4] INTERNET-DRAFT A Framework for IP over RPR November, 2000 5. Security Security in a network using IPoRPR should be relatively similar to security in a normal IP network. The route filtering and packet filtering features are unchanged. 6. Full Copyright Statement "Copyright (C) The Internet Society. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into._ 7. References 1. ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)" [Also republished as RFC 1142] 2. RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R. W. Callon, Dec. 1990 3. RFC 2178, "OSPF Version 2", J. Moy. July 1997 4. "Multiprotocol Label Switching Architecture", E. Rosen, A. Viswanathan, R. Callon, work in progress, draft-ietf-mpls-arch- 06.txt, August 1999. 5. IEEE 802.17 RPR PAR and 5 Criteria, http://www.ieee802.org/17 , November 2000. 8. Author's Addresses Herrera, et al Expires June, 2001 [Page 5] INTERNET-DRAFT A Framework for IP over RPR November, 2000 Albert Herrera Cisco Systems, Inc. 365 March Road, Kanata, ON K2K 2C9 Phone: 613-271-3635 Email: albherre@xxxxxxxxx Russ White Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC Phone: 919 392-3139 Email: ruwhite@xxxxxxxxx Pankaj K Jha Cypress Semiconductor 3901 N First Street San Jose, CA 95134 Phone: 408 432 7091 pkj@xxxxxxxxxxx Raj Sharma (raj) Sanjay Agrawal (sanjay) Prasad Jogalekar (prasad) Arun Sastry (arun@xxxxxxxxxxxxxxxxxxxx) Luminous Networks 10460 Bubb Road Cupertino, CA 95014 Tel: 408-342-6400 Khaled Amer AmerNet Email: khaledamer@xxxxxxx Herrera, et al Expires June, 2001 [Page 6]