Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN
draft-ietf-pwe3-cw-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Sam Hartman |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Brian Carpenter |
2005-11-10
|
06 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2005-11-05
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
2005-11-05
|
06 | Amy Vezza | IESG has approved the document |
2005-11-05
|
06 | Amy Vezza | Closed "Approve" ballot |
2005-11-05
|
06 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2005-10-09
|
06 | Mark Townsley | Proto Questionairre From Stewart Bryant, 7/8/05 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is … Proto Questionairre From Stewart Bryant, 7/8/05 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes. In addition rteview in PWE3 WG the draft includes an MPLS chair as co-author. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. There is the issue of the IETF at some time in the future wishing to reclaim IP version 0 and 1. This is unlikely. Will a note need to be included in the IP versions registry? 5) 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 this design. There is the issue of whether there needs to be any L2TPv3 text included, but the opinion of the WG is that this should be a seperate document. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes 8) Does the document a) split references into normative/informative, and b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (Note: the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) a) yes b) No 9) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: |
2005-10-06
|
06 | Brian Carpenter | [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter |
2005-10-03
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-10-03
|
06 | (System) | New version available: draft-ietf-pwe3-cw-06.txt |
2005-08-19
|
06 | (System) | Removed from agenda for telechat - 2005-08-18 |
2005-08-18
|
06 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2005-08-18
|
06 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman |
2005-08-18
|
06 | Amy Vezza | State Changes to IESG Evaluation from Waiting for Writeup by Amy Vezza |
2005-08-18
|
06 | Sam Hartman | [Ballot discuss] I don't think this document is appropriate for the standards track because it specifies no protocol; I don't see how you could have … [Ballot discuss] I don't think this document is appropriate for the standards track because it specifies no protocol; I don't see how you could have multiple interoperable implementations of this spec. Instead, as best I can tell it should be a BCP. It provides normative requirements for future pseudowire specifications over the MPLS PSN. If these requirements are not followed, things will break. However the specific format of the control word is up to the encapsulation for the pseudowire, not this spec. For example, I don't see a need for a normative reference between the ethernet encapsulation and this spec. |
2005-08-18
|
06 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded for Sam Hartman by Sam Hartman |
2005-08-18
|
06 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2005-08-18
|
06 | Brian Carpenter | [Ballot discuss] Points raised by John Loughney in Gen-ART review: ... 2) Section 2 says: A PW carried over an MPLS PSN that uses … [Ballot discuss] Points raised by John Loughney in Gen-ART review: ... 2) Section 2 says: A PW carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path SHOULD employ the PW MPLS Control Word described in Section 3 for data, or the PW Associated Channel Header described in Section 4 for channel associated traffic. Why SHOULD it employ the PW MPLS control word or PW associated channel header? What if an implementation doesn't? [BC - the real question is when can this SHOULD be ignored? If the answer is "never", it must be a MUST] 3) In section 3, you have: When a PWMCW is used, it MUST adhere to the Generic MPLS Control Word format as illustrated in Figure 1 above. It SHOULD also follow the following format: What if it doesn't follow the format? Why would an implementation want to follow the format? [BC - the real question is when can this SHOULD be ignored? If the answer is "never", it must be a MUST] 4) Security Considerations section doesn't really address how a PW Associated Channel could be abused, which I think makes it harder for someone reading this document to be able to deterime what security considerations they should take when deploying this. I think some text explaining what the threats are would be useful [BC - this text: An application using PW Associated Channel to provide an OAM [VCCV] or other message channel MUST be aware that this can potentially be misused. Any application using the Associated Channel must therefore fully consider the resultant security issues, ... indeed provides no information as to what threats may or may not exist.] |
2005-08-18
|
06 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
2005-08-18
|
06 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
2005-08-18
|
06 | Allison Mankin | [Ballot comment] Advice to new user of proto method: the wg chair shepherd's questionnaire items before the normal writeup should go into the log, not … [Ballot comment] Advice to new user of proto method: the wg chair shepherd's questionnaire items before the normal writeup should go into the log, not in the ballot. |
2005-08-18
|
06 | Allison Mankin | [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin by Allison Mankin |
2005-08-18
|
06 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2005-08-17
|
06 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2005-08-17
|
06 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2005-08-17
|
06 | Michelle Cotton | IANA Follow-up comments: Here are some follow-up Last Call Comments from the Authors: > The Pseudowire Format Identifiers has > the value 0 reserved in … IANA Follow-up comments: Here are some follow-up Last Call Comments from the Authors: > The Pseudowire Format Identifiers has > the value 0 reserved in the document. I don't think we have a proper > name (the draft just says "as shown in figure 3". I think we need a > name. Not sure if you have to add it to the IANA considerations. > > For the Pseudowire Associated Channel Types, > I also thought we were going to reserve the value 0021 for IPv4 (same > value as assigned in PPP). Will a new version address these comments? This information should be added in the IANA Considerations section. |
2005-08-17
|
06 | Russ Housley | [Ballot comment] Please spell out the first use of "OAM." |
2005-08-17
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
2005-08-17
|
06 | Brian Carpenter | [Ballot comment] 1. The draft cites RFC 1883 which was obsoleted by RFC 2460. 2. [From Gen-ART review by John Loughney] I'm not an … [Ballot comment] 1. The draft cites RFC 1883 which was obsoleted by RFC 2460. 2. [From Gen-ART review by John Loughney] I'm not an MPLS expert, so reading the abstract (two sentences) with a large number of acronyms presents a bit of a barrier for understanding exactly what is going on here: ... The design of these fields is chosen so that an MPLS LSR performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload. Suggestion: expand most of the acronyms. |
2005-08-17
|
06 | Brian Carpenter | [Ballot discuss] Points raised by John Lougney in Gen-ART review: ... 2) Section 2 says: A PW carried over an MPLS PSN that uses … [Ballot discuss] Points raised by John Lougney in Gen-ART review: ... 2) Section 2 says: A PW carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path SHOULD employ the PW MPLS Control Word described in Section 3 for data, or the PW Associated Channel Header described in Section 4 for channel associated traffic. Why SHOULD it employ the PW MPLS control word or PW associated channel header? What if an implementation doesn't? [BC - the real question is when can this SHOULD be ignored? If the answer is "never", it must be a MUST] 3) In section 3, you have: When a PWMCW is used, it MUST adhere to the Generic MPLS Control Word format as illustrated in Figure 1 above. It SHOULD also follow the following format: What if it doesn't follow the format? Why would an implementation want to follow the format? [BC - the real question is when can this SHOULD be ignored? If the answer is "never", it must be a MUST] 4) Security Considerations section doesn't really address how a PW Associated Channel could be abused, which I think makes it harder for someone reading this document to be able to deterime what security considerations they should take when deploying this. I think some text explaining what the threats are would be useful [BC - this text: An application using PW Associated Channel to provide an OAM [VCCV] or other message channel MUST be aware that this can potentially be misused. Any application using the Associated Channel must therefore fully consider the resultant security issues, ... indeed provides no information as to what threats may or may not exist.] |
2005-08-17
|
06 | Brian Carpenter | [Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Brian Carpenter |
2005-08-15
|
06 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2005-08-10
|
06 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2005-07-28
|
06 | Mark Townsley | Placed on agenda for telechat - 2005-08-18 by Mark Townsley |
2005-07-28
|
06 | Mark Townsley | Note field has been cleared by Mark Townsley |
2005-07-28
|
06 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley |
2005-07-28
|
06 | Mark Townsley | Ballot has been issued by Mark Townsley |
2005-07-28
|
06 | Mark Townsley | Created "Approve" ballot |
2005-07-25
|
06 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2005-07-13
|
06 | Michelle Cotton | IANA Last Call Comments: Upon approval of this document the IANA will create 2 new registries: Pseudowire Associated Channel Types (16-bit values)(IETF Consensus) Pseudowire Format … IANA Last Call Comments: Upon approval of this document the IANA will create 2 new registries: Pseudowire Associated Channel Types (16-bit values)(IETF Consensus) Pseudowire Format Identifiers (4-bit values)(IETF Consensus) Do we understand correctly that this document itself does not assign any new values? |
2005-07-11
|
06 | Amy Vezza | Last call sent |
2005-07-11
|
06 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2005-07-11
|
06 | Mark Townsley | State Changes to Last Call Requested from AD Evaluation::AD Followup by Mark Townsley |
2005-07-11
|
06 | Mark Townsley | Last Call was requested by Mark Townsley |
2005-07-11
|
06 | (System) | Ballot writeup text was added |
2005-07-11
|
06 | (System) | Last call text was added |
2005-07-11
|
06 | (System) | Ballot approval text was added |
2005-07-08
|
05 | (System) | New version available: draft-ietf-pwe3-cw-05.txt |
2005-05-31
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-05-31
|
04 | (System) | New version available: draft-ietf-pwe3-cw-04.txt |
2005-04-22
|
06 | Mark Townsley | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Mark Townsley |
2005-04-22
|
06 | Mark Townsley | [Note]: 'Waiting on new version addressing comments from my review and associated discussion on PWE3 list.' added by Mark Townsley |
2005-03-28
|
06 | Mark Townsley | State Changes to AD Evaluation from AD Evaluation::External Party by Mark Townsley |
2005-03-28
|
06 | Mark Townsley | [Note]: 'Stewart Bryant wrote: > I submitted a new WG draft, but when it appears I want the WG to have > a chance to … [Note]: 'Stewart Bryant wrote: > I submitted a new WG draft, but when it appears I want the WG to have > a chance to look at it before you action it. ' added by Mark Townsley |
2005-03-25
|
06 | Mark Townsley | State Changes to AD Evaluation::External Party from AD Evaluation::AD Followup by Mark Townsley |
2005-03-25
|
06 | Mark Townsley | [Note]: ' Stewart Bryant wrote: > I submitted a new WG draft, but when it appears I want the WG to have > a chance … [Note]: ' Stewart Bryant wrote: > I submitted a new WG draft, but when it appears I want the WG to have > a chance to look at it before you action it. ' added by Mark Townsley |
2005-03-24
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-03-24
|
03 | (System) | New version available: draft-ietf-pwe3-cw-03.txt |
2005-03-23
|
06 | Mark Townsley | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Mark Townsley |
2005-03-23
|
06 | Mark Townsley | [Note]: 'Note from chair/author: There is another pass in final edit that I will be sending out this week with the corrections agreed at the … [Note]: 'Note from chair/author: There is another pass in final edit that I will be sending out this week with the corrections agreed at the WG mtg. Then I said at the meeting that I would 2 week LC it - remember that both chairs are authors so we need to make sure we follow the protocol quite carefully. We will release it back to you in just over two weeks. Stewart' added by Mark Townsley |
2005-03-11
|
06 | Mark Townsley | Shepherding AD has been changed to Mark Townsley from Thomas Narten |
2005-02-24
|
06 | Thomas Narten | [Note]: '2005-02-24: WG is still discussing changes to the following set of documents (which will be sent to the IESG together): draft-ietf-pwe3-control-protocol-15.txt, draft-ietf-pwe3-cw-02.txt, … [Note]: '2005-02-24: WG is still discussing changes to the following set of documents (which will be sent to the IESG together): draft-ietf-pwe3-control-protocol-15.txt, draft-ietf-pwe3-cw-02.txt, draft-ietf-pwe3-ethernet-encap-09.txt, draft-ietf-pwe3-iana-allocation-08.txt. ' added by Thomas Narten |
2005-02-22
|
02 | (System) | New version available: draft-ietf-pwe3-cw-02.txt |
2005-01-25
|
06 | Thomas Narten | [Note]: '2005-01-25: AD review raises questions. Also, this document needs to be advanced together as part of a 4-doc set: draft-ietf-pwe3-ethernet-encap-07.txt draft-ietf-pwe3-cw-01.txt draft-ietf-pwe3-control-protocol-14.txt draft-ietf-pwe3-iana-allocation-07.txt ' … [Note]: '2005-01-25: AD review raises questions. Also, this document needs to be advanced together as part of a 4-doc set: draft-ietf-pwe3-ethernet-encap-07.txt draft-ietf-pwe3-cw-01.txt draft-ietf-pwe3-control-protocol-14.txt draft-ietf-pwe3-iana-allocation-07.txt ' added by Thomas Narten |
2005-01-25
|
06 | Thomas Narten | expand abbreviations in abstract. > The standard MPLS encapsulations have no explicit protocol > identifier. In order for a pseudo wire (PW) [ARCH] … expand abbreviations in abstract. > The standard MPLS encapsulations have no explicit protocol > identifier. In order for a pseudo wire (PW) [ARCH] to operate > correctly over an MPLS packet switched network (PSN) that performs > deep packet inspection, a PW packet must not appear to the LSR as if > it were an IP packet [BCP]. An example of an LSR that performs deep Is "deep packet inspection" defined somewhere? I don't see the word "deep" in the cited document. > though the PSN. This may result in misordered packet deliver to the > egress PE. The inability to ensure that all packets belonging to a s/deliver/being delivered/? > All IP packets [RFC791][RFC1883] start with a version number that is > checked by LSRs performing deep packet inspection. To prevent the > incorrect inspection of packets, PW packets carried over an MPLS PSN > SHOULD NOT start with the value 4 (IPv4) or the value 6 (IPv6) in > the first nibble [BCP]. Better (?): To prevent the incorrect processing of packets carried within a PW, PW packets carried over an MPLS PSN SHOULD NOT start with the value 4 (IPv4) or the value 6 (IPv6) in the first nibble [BCP], as those are assumed to carry normal IP. > When a PW-CW is used, it SHOULD have the following preferred form: s/SHOULD/has/ This document should just say this is how it is done. If something else is done, its not a PW-CW anymore. > These bits are available for per payload signalling. Their s/per payload/per-payload/ > FRG (bits 8 and 9): > > These bits are used when fragmenting a PW payload. Their use > is defined in [FRAG] which is currently work in progress. FRAG is listed as a normative reference. I suspect that is not what is desired (nor is it required). > If the MPLS > payload is between 46 bytes and 63 bytes the implementation > MAY either set to the length of the MPLS payload, or it MAY > set it to 0. > > Note to the reader: In the definition above, both the MUSTs > are needed to make the mechanism work, the MAY provides > backwards compatibility with deployed systems. Is this really what is needed? Seems like the spec should be saying. The sender MUST or SHOULD set it to (pick one or the other), but (and this is what is critical) on receipt should be prepared to handle _either_ value. That is what gives you interoperability. Or, if you want new implementation to work with old, than say the SHOULD (or MAY) also support sending a 0, but that this should be configurable??? Or something. Kind of depends on what you are trying to acheive. Is it interoperability with implementations that send a 0? Or those that expect 0 on receipt and don't handle the "correct" value? > If the sequence number is not used, it is set to zero by the > sender and ignored by the receiver. Otherwise it specifies > the sequence number of a packet. A circular list of sequence > numbers is used. A sequence number takes a value from 1 to > 65535 (2**16-1). The sequence number window size for packet > acceptance is dependent on the parameters of the PSN, and > SHOULD be configurable. The mechanism used by the > decapsulating PE to (re)acquire the correct sequence number > is implementation dependent. when you say "should be configurable" and "implementation dependent", is it really the case that this is PW-specific, with the details defined in those docs? IANA considerations for all these documents need to be synced up, as there are redundencies > 6. Security Considerations > > An application using this mechanism to provide an OAM [VCCV] or > other message channel MUST be aware that this can potentially be which mechanism does "this mechanism" refer to? > If a PW has been configured to operate without a CW, the PW > Associated Channel Type mechanism described in the document MUST NOT > be used. This is to prevent user payloads being fabricated in such a > way that they mimic the PW Associated Channel header, and thereby > provide a method of attacking the application that is using the > Associated Channel. what does "MUST NOT be used" mean? Is there a way to _prevent_ it from being used? > 10. Normative References I suspect many, if not most, of these references should be informative. |
2005-01-25
|
06 | Thomas Narten | State Changes to AD Evaluation from Publication Requested by Thomas Narten |
2005-01-25
|
06 | Thomas Narten | State Change Notice email list have been change to stbryant@cisco.com, danny@tcb.net,swallow@cisco.com from stbryant@cisco.com, danny@tcb.net |
2004-12-17
|
06 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2004-12-16
|
01 | (System) | New version available: draft-ietf-pwe3-cw-01.txt |
2004-10-19
|
00 | (System) | New version available: draft-ietf-pwe3-cw-00.txt |