Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)
RFC 5254
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
07 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2017-05-16
|
07 | (System) | Changed document authors from "Matthew Bocci, Luca Martini" to "Matthew Bocci, Luca Martini, Nabil Bitar" |
|
2015-10-14
|
07 | (System) | Notify list changed from pwe3-chairs@ietf.org, draft-ietf-pwe3-ms-pw-requirements@ietf.org, Dan Romascanu <dromasca@avaya.com>, hartmans-ietf@mit.edu to hartmans-ietf@mit.edu, Dan Romascanu <dromasca@avaya.com> |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2008-10-22
|
07 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2008-10-22
|
07 | Amy Vezza | [Note]: 'RFC 5254' added by Amy Vezza |
|
2008-10-21
|
07 | (System) | RFC published |
|
2008-06-11
|
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2008-06-10
|
07 | (System) | IANA Action state changed to No IC from In Progress |
|
2008-06-10
|
07 | (System) | IANA Action state changed to In Progress |
|
2008-06-10
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2008-06-10
|
07 | Amy Vezza | IESG has approved the document |
|
2008-06-10
|
07 | Amy Vezza | Closed "Approve" ballot |
|
2008-06-10
|
07 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
|
2008-06-10
|
07 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
|
2008-06-09
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2008-06-09
|
07 | (System) | New version available: draft-ietf-pwe3-ms-pw-requirements-07.txt |
|
2008-04-17
|
07 | Mark Townsley | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Mark Townsley |
|
2008-04-17
|
07 | Mark Townsley | [Note]: 'Call with Pasi, Tim, authors/chairs and agreed on way forward.' added by Mark Townsley |
|
2008-04-09
|
07 | Pasi Eronen | [Ballot discuss] [Taking Sam's discuss] This document describes a significant new application and broadening of the applicability of PWE3. Especially in access/metro environments, there will … [Ballot discuss] [Taking Sam's discuss] This document describes a significant new application and broadening of the applicability of PWE3. Especially in access/metro environments, there will be a lot more PE devices involved, connected over less protected links. It seems that isolation is important, so that the compromise of one of the devices (or links) does not lead to compromise of other customer data from a completely unrelated PE. Some requirements relating to this need to be stated, probably related both to data and control plane. For data plane security services, RFC 4364 probably provides a reasonable starting point. It won't necessarily involve crypto, but if it doesn't, clear description of the applicability in environments where PEs or links close to customers could be compromised. About the inter-AS case: discussions with authors/WG chairs/ADs clarified that in the inter-AS case, TEs are always on the same link (and not communicating over arbitrary cloud). If this is indeed the case, the inter-AS case might be even simpler than the intra-AS case (concerning e.g. scalability of key management for control plane). |
|
2008-04-09
|
07 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
|
2008-03-06
|
07 | Sam Hartman | [Ballot discuss] Section 8.1: The threat model for the environments described in this document seems very similar to the Internet threat model. So, I think … [Ballot discuss] Section 8.1: The threat model for the environments described in this document seems very similar to the Internet threat model. So, I think BCP 61 applies in full force. What are the mandatory security services to provide for this threat model? It seems clear to me that isolation of one circuit's traffic from another is clearly such a mandatory service. Please provide an argument about what security is expected and about how the expected data plane security guarantees are met by mandatory to implement mechanisms. Section 8.2 > For a greater degree of security, an authentication mechanism that is > suitable to the associated protocol MUST be available. Furthermore > authentication using a signature for each individual MS-PW setup > messages MUST be available, in addition to an overall control > protocol session authentication , and message validation. Why do you need signatures of PWE3 setup messages? If you're going down that road, I think you may need a lot more description of what security services you are trying to provide and what you are protecting against. This document describes a significant new application and broadening of the applicability of PWE3 As such it is necessary to make sure the solution meets the latest IETF security requirements. In particular, take a look at RFC 4107 and perform that analysis. I expect you to find that MS-PWE3 protocols must provide mandatory to implement automated key management. If so, this needs to be stated as a requirement. General: the access metro environment seems to have significant security requirements. In particular there will be a lot more PE devices involved. It seems that isolation is important in this environment so that the compromise of one of these devices does not lead to compromise of other customer data from a completely unrelated PE. Surely requirements relating to this need to be stated. |
|
2008-02-28
|
07 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
|
2007-12-21
|
07 | Mark Townsley | [Note]: 'New version does not address Sam''s discuss. Need to check with Dan about his.' added by Mark Townsley |
|
2007-12-21
|
07 | Mark Townsley | -------- Original Message -------- Subject: Re: New Version Notification - draft-ietf-pwe3-ms-pw-requirements-06.txt Date: Thu, 20 Dec 2007 08:46:54 -0500 From: Sam Hartman <hartmans-ietf@mit.edu> To: … -------- Original Message -------- Subject: Re: New Version Notification - draft-ietf-pwe3-ms-pw-requirements-06.txt Date: Thu, 20 Dec 2007 08:46:54 -0500 From: Sam Hartman <hartmans-ietf@mit.edu> To: pwe3-chairs@tools.ietf.org, townsley@cisco.com, housley@vigilsec.com, dromasca@avaya.com, lars.eggert@nokia.com References: <E1J4MMf-0007m7-Ht@stiedprstage1.ietf.org> I don't see any attempt to respond to my comments in the new draft, so my discuss still stands. |
|
2007-12-21
|
07 | Mark Townsley | State Change Notice email list have been change to pwe3-chairs@tools.ietf.org, draft-ietf-pwe3-ms-pw-requirements@tools.ietf.org, Dan Romascanu <dromasca@avaya.com>, hartmans-ietf@mit.edu from pwe3-chairs@tools.ietf.org |
|
2007-12-18
|
07 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
|
2007-12-17
|
07 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2007-12-17
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2007-12-17
|
06 | (System) | New version available: draft-ietf-pwe3-ms-pw-requirements-06.txt |
|
2007-10-25
|
07 | Mark Townsley | [Note]: 'Discussions ongoing with Dan and Lars. Need response from Dan.' added by Mark Townsley |
|
2007-10-25
|
07 | Mark Townsley | Status date has been changed to 2007-11-14 from |
|
2007-06-03
|
07 | Russ Housley | [Ballot discuss] Based on the SecDir Review by Steve Hanna: PWE3 traffic may often come from legacy applications that were designed with an … [Ballot discuss] Based on the SecDir Review by Steve Hanna: PWE3 traffic may often come from legacy applications that were designed with an assumption that the underlying network provides some security. Therefore, I recommend that the document authors consider carefully whether the protections specified in this document are adequate for the intended purpose. If adequate, then please make an explicit statement in the security considerations of this document. Please include a statement of the minimal security protection that is provided for data plane traffic, and state that if additional protection is needed it must be provided by higher-layer protocols. The control plane security requirements described in this document are probably adequate. However, I think it would be better to say that the unspecified additional authentication mechanism must be strong and mandatory-to-implement (but not mandatory-to-deploy). **** I agreed to these changes to resolve this DISCUSS position... This is a requirement document. Such a statement needs to be in the particular MS-PW solution document. However the following is to added: "Some types pf PWs make assumptions about the security of the underling PSN. The minimal security provided by an MPLS PSN might not be sufficient to meet the security requirements expected by the applications using the MS-PW. This document does not place any requirements on protecting the privacy of a MS-PW PDU via encryption. However, encryption is required at a higher layer in the protocol stack, based on the application or network requirements." Changed the control plane text as follows: "An incoming MS-PW request/reply MUST NOT be accepted unless its IP source address is known to be the source of an "eligible" peer. If a peering adjacency has to be established prior to exchanging setup requests/responses, peering MUST only be done with eligible peers. The set of eligible peers could be pre-configured (either as a list of IP addresses, or as a list of address/mask combinations) or automatically generated from the local PW configuration information. Furthermore, the restriction of peering sessions to specific interfaces MUST also be provided. The S-PE and T-PE MUST drop the unaccepted signaling messages in the data path to avoid a DoS attack on the control plane. Even if a connection request appears to come from an eligible peer, its source address may have been spoofed. So some means of preventing source address spoofing must be in place. For example, if eligible peers are in the same network, source address filtering at the border routers of that network could eliminate the possibility of source address spoofing. The configuration and maintenance protocol MUST provide a strong authentication and control protocol data protection mechanism. This option MUST be implemented , but it should be deployed according to the specific PSN environment requirements. Furthermore authentication using a signature for each individual MS-PW setup messages MUST be available, in addition to an overall control protocol session authentication, and message validation." |
|
2007-05-25
|
07 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Steve Hanna. |
|
2007-05-25
|
07 | (System) | Removed from agenda for telechat - 2007-05-24 |
|
2007-05-24
|
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
|
2007-05-24
|
07 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2007-05-24
|
07 | Lars Eggert | [Ballot discuss] Section 3.1., paragraph 2: > This document specifies additional requirements that apply to MS-PWs. > These requirements do not apply to … [Ballot discuss] Section 3.1., paragraph 2: > This document specifies additional requirements that apply to MS-PWs. > These requirements do not apply to PSNs that only support SS-PWs. DISCUSS: Please add a statement saying that this document does not invalidate any parts of RFC3985. (I'm mostly thinking about the congestion control requirements, but I think this would be true in general.) Section 6.1.3., paragraph 0: > 6.1.3. Quality Of Service DISCUSS: Running PWs inside traffic-engineered PSN tunnels isn't only needed to protect the service quality that PWs receive. It's also essential to fulfill the congestion control requirements in RFC3985 Section 6.5, which requires the existence of a mechanism that controls the bandwidth use of PWs in a way that prevents congestion collapse and is sort-of fair to concurrent congestion-controlled flows over reasonable timescales. There currently isn't such a mechanism defined for PWs, although draft-ietf-pwe3-ms-pw-requirements has promising initial requirements. Consequently, existing PW encapsulation specifications - especially for TDM PWs, but also for packet-based PWs that can carry non-congestion-controlled traffic - have contained text that basically said "the PW MUST be run over a path that has been provisioned for the PW either through a bandwidth reservation or through a degree of over-provisioning that prevents the bandwidth use of the PW to have significant impact on concurrent traffic." This document should discuss that aspect of path provisioning as well. Essentially, path provisioning is REQUIRED to fulfill the congestion control requirements for all PW encapsulations that don't have their own congestion control mechanism (none of the published ones do). I'm stressing this here, because when MS-PW traffic crosses over into the network of another operator, there is the potential to cause harm (congestion) to others, whereas with the currently-defined SS-PWs, harm was restricted to the home operator's network. |
|
2007-05-24
|
07 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
|
2007-05-24
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2007-05-24
|
07 | Jari Arkko | [Ballot comment] > domains that PSN Tunnel 1 and PSN Tunnel 2 traverse could beIGP areas s/beIGP/be IGP/ |
|
2007-05-24
|
07 | Magnus Westerlund | [Ballot comment] I was very close to make this a discuss. But as my issue seems to be a result of an already existing requriement … [Ballot comment] I was very close to make this a discuss. But as my issue seems to be a result of an already existing requriement I don't see a need to block the document. In section 6.1.3 there is a strong requirment on congestion control and the possibility to signal information about its occurance to other segments. However for Section 6.3.4 there seem to me to be a lack of clarification what that implies for this type of MS-PWs. To me it seems that the static configured ones are the ones that will have most problems with the congestion control. This due to the issues of trying to move a PW when there are no altarnative paths, and the only course of action may be to shutdown or downgrade the capacity of the PW. I wished there was a bit more discussion on this issue and the requirement it introduces as I see it. |
|
2007-05-24
|
07 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2007-05-23
|
07 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2007-05-23
|
07 | Russ Housley | [Ballot discuss] Based on the SecDir Review by Steve Hanna: PWE3 traffic may often come from legacy applications that were designed with an … [Ballot discuss] Based on the SecDir Review by Steve Hanna: PWE3 traffic may often come from legacy applications that were designed with an assumption that the underlying network provides some security. Therefore, I recommend that the document authors consider carefully whether the protections specified in this document are adequate for the intended purpose. If adequate, then please make an explicit statement in the security considerations of this document. Please include a statement of the minimal security protection that is provided for data plane traffic, and state that if additional protection is needed it must be provided by higher-layer protocols. The control plane security requirements described in this document are probably adequate. However, I think it would be better to say that the unspecified additional authentication mechanism must be strong and mandatory-to-implement (but not mandatory-to-deploy). |
|
2007-05-23
|
07 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
|
2007-05-23
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2007-05-23
|
07 | Sam Hartman | [Ballot comment] I'd like to show strong support for Dan's comments. I think that more thought needs to be given to what management interfaces are … [Ballot comment] I'd like to show strong support for Dan's comments. I think that more thought needs to be given to what management interfaces are required. There are a lot of configuration settings especially in the static cases. For these to be easily managed, care needs to be given to management requirements. |
|
2007-05-23
|
07 | Sam Hartman | [Ballot discuss] Section 8.1: PWE3 has been marketed as having as good of security as the perceived technologies that it is replacinig. The threat model … [Ballot discuss] Section 8.1: PWE3 has been marketed as having as good of security as the perceived technologies that it is replacinig. The threat model for the environments described in this document seems very similar to the Internet threat model. So, I think BCP 61 applies in full force. What are the mandatory security services to provide for this threat model? It seems clear to me that isolation of one circuit's traffic from another is clearly such a mandatory service. Please provide an argument about what security is expected and about how the expected data plane security guarantees are met by mandatory to implement mechanisms. Section 8.2 > For a greater degree of security, an authentication mechanism that is > suitable to the associated protocol MUST be available. Furthermore > authentication using a signature for each individual MS-PW setup > messages MUST be available, in addition to an overall control > protocol session authentication , and message validation. Why do you need signatures of PWE3 setup messages? If you're going down that road, I think you may need a lot more description of what security services you are trying to provide and what you are protecting against. This document describes a significant new application and broadening of the applicability of PWE3 As such it is necessary to make sure the solution meets the latest IETF security requirements. In particular, take a look at RFC 4107 and perform that analysis. I expect you to find that MS-PWE3 protocols must provide mandatory to implement automated key management. If so, this needs to be stated as a requirement. General: the access metro environment seems to have significant security requirements. In particular there will be a lot more PE devices involved. It seems that isolation is important in this environment so that the compromise of one of these devices does not lead to compromise of other customer data from a completely unrelated PE. Surely requirements relating to this need to be stated. |
|
2007-05-23
|
07 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
|
2007-05-23
|
07 | Tim Polk | [Ballot comment] For completeness, a statement that the data plane security considerations for SS-PWs specified in RFC 3985 apply to MS-PWs should be included in … [Ballot comment] For completeness, a statement that the data plane security considerations for SS-PWs specified in RFC 3985 apply to MS-PWs should be included in this specification's security considerations section. |
|
2007-05-21
|
07 | Dan Romascanu | [Ballot discuss] I like Section 7 which defines the requirements for OAM. Howevwe, as management of pseudo-wires involves more than the definition of the OAM … [Ballot discuss] I like Section 7 which defines the requirements for OAM. Howevwe, as management of pseudo-wires involves more than the definition of the OAM protocols this information needs to be completed with manageability requirements. At a minimum there should be a requirement indicating what type of management interfaces are PWE3 entities required to provide (CLI at minimum, SNMP and MIB interface REQUIRED or RECOMMENDED), and how is a management solution required to be deployed (remote access over multiple domanis?). |
|
2007-05-21
|
07 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2007-05-21
|
07 | Dan Romascanu | [Ballot comment] 1. Add ITU-T I.610 specification http://www.itu.int/rec/T-REC-I.610-199902-I/en as an informative reference 2. Section 7 of this document is using the expansion of the OAM … [Ballot comment] 1. Add ITU-T I.610 specification http://www.itu.int/rec/T-REC-I.610-199902-I/en as an informative reference 2. Section 7 of this document is using the expansion of the OAM acronyms as 'Operations and Maintenance' (OAM) as per the ITU-T documents. Unfortunately in the industry there are different ways of expanding these, and the IETF has also at least adopted two different ones (see RFC 4377 which in its title expands OAM as 'Operations and Management'). I would suggest that section 7 makes the usage of OAM in this document clear by adding a note that says: 'Note that this document uses the term OAM as Operations and Management as per ITU-T I.610.' |
|
2007-05-17
|
07 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
|
2007-05-14
|
07 | Mark Townsley | State Changes to IESG Evaluation from Waiting for Writeup by Mark Townsley |
|
2007-05-14
|
07 | Mark Townsley | Placed on agenda for telechat - 2007-05-24 by Mark Townsley |
|
2007-05-14
|
07 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley |
|
2007-05-14
|
07 | Mark Townsley | Ballot has been issued by Mark Townsley |
|
2007-05-14
|
07 | Mark Townsley | Created "Approve" ballot |
|
2007-05-11
|
07 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
|
2007-05-06
|
07 | Yoshiko Fong | IANA Last Call Comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2007-05-03
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Steve Hanna |
|
2007-05-03
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Steve Hanna |
|
2007-04-27
|
07 | Amy Vezza | Last call sent |
|
2007-04-27
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2007-04-27
|
07 | Mark Townsley | Last Call was requested by Mark Townsley |
|
2007-04-27
|
07 | (System) | Ballot writeup text was added |
|
2007-04-27
|
07 | (System) | Last call text was added |
|
2007-04-27
|
07 | (System) | Ballot approval text was added |
|
2007-04-27
|
07 | Mark Townsley | State Changes to Last Call Requested from AD Evaluation by Mark Townsley |
|
2007-04-12
|
07 | Mark Townsley | State Changes to AD Evaluation from Publication Requested by Mark Townsley |
|
2007-04-02
|
07 | Dinara Suleymanova | PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, … PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Stewart Bryant (stbryant@cisco.com) PWE3 co-chair. The chairs have read this version of the document and it is now ready for consideration by the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been thoroughly reviewed by the PWE3 WG. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I have no concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no issues that the chairs are aware of. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=621 This was filed nearly two years on a solution draft rather this requirements draft and no one has commented on it. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus for the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No one has threatened to appeal. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? Yes - there is one minor issue with an out of date ref, but nothing to prevent the draft going forward. http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. There are no pending normative references (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Not applicable Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Not applicable (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonimous systems under the autonomous systems under the administrative control of two or more service providers, or administratevly established pseudowire domains. Working Group Summary This document has been reviewed by the experts in the PWE3 WG and there are no outstanding issues. Document Quality Are there existing implementations of the protocol? A number of vendor have MS PWs, but the exact design is a matter for the protocol drafts that follow. Have a significant number of vendors indicated their plan to implement the specification? Yes Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Not applicable. Personnel Who is the Document Shepherd for this document? Stewart Bryant (stbryant@cisco.com) Who is the Responsible Area Director? Mark Townsley (townsley@cisco.com) Is an IANA expert needed? |
|
2007-04-02
|
07 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
|
2007-03-28
|
05 | (System) | New version available: draft-ietf-pwe3-ms-pw-requirements-05.txt |
|
2007-01-15
|
04 | (System) | New version available: draft-ietf-pwe3-ms-pw-requirements-04.txt |
|
2006-10-11
|
03 | (System) | New version available: draft-ietf-pwe3-ms-pw-requirements-03.txt |
|
2006-05-16
|
02 | (System) | New version available: draft-ietf-pwe3-ms-pw-requirements-02.txt |
|
2005-10-26
|
01 | (System) | New version available: draft-ietf-pwe3-ms-pw-requirements-01.txt |
|
2005-06-16
|
00 | (System) | New version available: draft-ietf-pwe3-ms-pw-requirements-00.txt |