Pseudowire Preferential Forwarding Status Bit
draft-ietf-pwe3-redundancy-bit-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-02-19
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-01-22
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-01-14
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-01-13
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-01-11
|
09 | (System) | IANA Action state changed to In Progress |
2013-01-11
|
09 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-01-10
|
09 | Cindy Morgan | State changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2013-01-10
|
09 | Cindy Morgan | IESG has approved the document |
2013-01-10
|
09 | Cindy Morgan | Closed "Approve" ballot |
2013-01-10
|
09 | Cindy Morgan | Ballot approval text was generated |
2013-01-10
|
09 | Stewart Bryant | Ballot writeup was changed |
2013-01-05
|
09 | Adrian Farrel | [Ballot comment] Thank you with your patient work to address my Discuss. --- I continue to be disappointed by the piecemeal invention of bolt-on signaling … [Ballot comment] Thank you with your patient work to address my Discuss. --- I continue to be disappointed by the piecemeal invention of bolt-on signaling features for PW management. It really seems that the working group needs to work on a functional architecture for pseudowires to work out all of the bits and pieces that are needed for redundancy, bandwidth, multi-segment routing, etc., etc. I wish this would happen before we incrementally munge the protocol too much, but I understand that this is not directly actionable for the authors of this document. |
2013-01-05
|
09 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
2013-01-04
|
09 | Mustapha Aissaoui | New version available: draft-ietf-pwe3-redundancy-bit-09.txt |
2012-12-03
|
08 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss |
2012-09-25
|
08 | Benoît Claise | [Ballot discuss] 1. In the section 10, you wrote: This document makes the following update to the PwOperStatusTC textual convention in RFC 5542 … [Ballot discuss] 1. In the section 10, you wrote: This document makes the following update to the PwOperStatusTC textual convention in RFC 5542 [9]: You can't simply update a Textual Convention (TC) like this, but putting a new TC, out of context. A TC belongs to a MIB module. You need a new revision of that MIB module: RFC5542bis. Note: you could cut/paste the new revision of the MIB module in this document, and obsolete RFC5542, but that would be misleading from the document title. Also, having a new RFC5542bis will cause some problems: there are many TCs in there, so surely, many references to RFC5542... which in turn will need to be updated. Now, looking more closely at your proposed change. - dormant(4): The PW is not in a condition to pass packets but is in a 'pending' state, waiting for some external event. For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY". The only change that you require is the addition of "For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY" in dormant(4). IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't require the extra work to produce RFC5542bis. Indeed, you don't change the TC semantic. What I believe you should be doing is: - a sentence such as (I trust you on the exact wording): this document illustrates how the dormant value of the PwOperStatusTC TC can be used to ..." and you include the meaning of your initial extra sentence - you remove "update: RFC 5542" Your proposed solution is: 10. MIB Considerations New MIB objects for the support of PW redundancy will be defined in a separate document. I don't understand why you went that route. Dan and I gave you a solution in the text above. 2. - Section 5.1 "independent mode". What do you mean by "management indication" in: In steady state with consistent configuration, a PE will always find an active PW. However, it is possible that such a PW is not found due to a mis-configuration. In the event that an active PW is not found, a management indication SHOULD be generated. If a management indication for failure to find an active PW was generated and an active PW is subsequently found, a management indication SHOULD be generated, so clearing the previous failure indication. Additionally, a PE MAY use the optional request switchover procedures described in Section 6.3. to have both PE nodes switch to a common PW. A syslog message, a SNMP notification, something else, or this is left completely open... in other words: "please do a little bit of management to please the OPS people ;-)" Can you justify why you don't even mention "management indication" in the second mode, i.e. section 5.2 "master/slave mode" note: I never seen the term management "indication". Do you want to say "management notification"? You have not replied to: Can you justify why you don't even mention "management indication" in the second mode, i.e. section 5.2 "master/slave mode"? 3. Here is another point, reported by Dan Romascanu, which I cut/pasted here: I did not have the time for a full OPS-DIR review, but I had a look at draft-ietf-pwe3-redundancy-bit which is on the IESG agenda tomorrow. Benoit entered a DISCUSS on a specific issue related to a proposed modification of the PwOperStatusTC from RFC 5542, which I support, but I think that the manageability problems with this I-D are broader. From an operator perspective I believe that there needs to be clear indication of the modes of operation (Independent, Master/Slave) besides the active / standby status of the PW, otherwise there will be no way to understand the status and configuration in different network situations. This may lead to changes to RFC 5542, but I think that mentioning just the MIB changes is not sufficient, as implementing the MIB modules is not mandatory for all PW devices, so the need to expose the modes and forwarding states needs to operators needs to be made in a protocol-independent manner. Not sure what you have done to address this point. |
2012-09-25
|
08 | Benoît Claise | Ballot discuss text updated for Benoit Claise |
2012-09-25
|
08 | Benoît Claise | [Ballot discuss] . In the section 10, you wrote: This document makes the following update to the PwOperStatusTC textual convention in RFC 5542 … [Ballot discuss] . In the section 10, you wrote: This document makes the following update to the PwOperStatusTC textual convention in RFC 5542 [9]: You can't simply update a Textual Convention (TC) like this, but putting a new TC, out of context. A TC belongs to a MIB module. You need a new revision of that MIB module: RFC5542bis. Note: you could cut/paste the new revision of the MIB module in this document, and obsolete RFC5542, but that would be misleading from the document title. Also, having a new RFC5542bis will cause some problems: there are many TCs in there, so surely, many references to RFC5542... which in turn will need to be updated. Now, looking more closely at your proposed change. - dormant(4): The PW is not in a condition to pass packets but is in a 'pending' state, waiting for some external event. For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY". The only change that you require is the addition of "For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY" in dormant(4). IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't require the extra work to produce RFC5542bis. Indeed, you don't change the TC semantic. What I believe you should be doing is: - a sentence such as (I trust you on the exact wording): this document illustrates how the dormant value of the PwOperStatusTC TC can be used to ..." and you include the meaning of your initial extra sentence - you remove "update: RFC 5542" Your proposed solution is: 10. MIB Considerations New MIB objects for the support of PW redundancy will be defined in a separate document. I don't understand why you went that route. Dan and I gave you a solution in the text above. 2. - Section 5.1 "independent mode". What do you mean by "management indication" in: In steady state with consistent configuration, a PE will always find an active PW. However, it is possible that such a PW is not found due to a mis-configuration. In the event that an active PW is not found, a management indication SHOULD be generated. If a management indication for failure to find an active PW was generated and an active PW is subsequently found, a management indication SHOULD be generated, so clearing the previous failure indication. Additionally, a PE MAY use the optional request switchover procedures described in Section 6.3. to have both PE nodes switch to a common PW. A syslog message, a SNMP notification, something else, or this is left completely open... in other words: "please do a little bit of management to please the OPS people ;-)" Can you justify why you don't even mention "management indication" in the second mode, i.e. section 5.2 "master/slave mode" note: I never seen the term management "indication". Do you want to say "management notification"? You have not replied to: Can you justify why you don't even mention "management indication" in the second mode, i.e. section 5.2 "master/slave mode"? 3. Here is another point, reported by Dan Romascanu, which I cut/pasted here: I did not have the time for a full OPS-DIR review, but I had a look at draft-ietf-pwe3-redundancy-bit which is on the IESG agenda tomorrow. Benoit entered a DISCUSS on a specific issue related to a proposed modification of the PwOperStatusTC from RFC 5542, which I support, but I think that the manageability problems with this I-D are broader. From an operator perspective I believe that there needs to be clear indication of the modes of operation (Independent, Master/Slave) besides the active / standby status of the PW, otherwise there will be no way to understand the status and configuration in different network situations. This may lead to changes to RFC 5542, but I think that mentioning just the MIB changes is not sufficient, as implementing the MIB modules is not mandatory for all PW devices, so the need to expose the modes and forwarding states needs to operators needs to be made in a protocol-independent manner. Not sure what you have done to address this point. |
2012-09-25
|
08 | Benoît Claise | [Ballot comment] - Section 5.1 1. For FEC128 PW, the PW with the lowest pw-id value is selected. 2. For FEC129 PW, each … [Ballot comment] - Section 5.1 1. For FEC128 PW, the PW with the lowest pw-id value is selected. 2. For FEC129 PW, each PW in a redundant set is uniquely identified No idea what FEC128 and FEC129 were. I had to search and found http://tools.ietf.org/html/rfc4379#section-3.2.8, where by the way, they're spelled "FEC 128" and "FEC 129". So please add a reference. You solve the issue in section 5.1 by removing FEC128 and FEC129, but FEC 128 and FEC 129 still appear in different places of the document |
2012-09-25
|
08 | Benoît Claise | Ballot comment and discuss text updated for Benoit Claise |
2012-09-15
|
08 | Adrian Farrel | [Ballot discuss] [Thanks to the authors for there work on this draft. They have handled a lot of my Discuss and Comment and we have … [Ballot discuss] [Thanks to the authors for there work on this draft. They have handled a lot of my Discuss and Comment and we have made a lot of progress. I have made updates, deleted points thathave been addressed, and used # to indicate new text. --- Section 5.2. Note that the behavior described in this section assumes correct configuration of the Master and Slave endpoints. This document does not define a mechanism to detect errors in the configuration. I suggest this is broken. You should at least be able to detect the error (not necessary to be able to resolve it) and report it. Also to not get into an unresolvable protocol breakdown when there are two T-PEs that think they are Masters. Actually, requirements 2 and 3 of Section 4.2 of draft-ietf-pwe3- redundancy seem to speak against this text. # In your response via email you said: # > In this case, the management system can detect the mis-configuration # > and raise an alarm. # # Frankly, if the mamangement system could detect the misconfiguration # it would not have allowed it in the first place. You need to consider # CLI configuration of remote PEs by different operators at different # times, and clearly it is quite possible for both PEs to be given the # same role. # # You continue... # > I do not think a mis-configuration will resolve in a protocol # > breakdown. If say the slave PE-rs node in Figure 15-6 operates as a # > Master, then traffic will flow towards the MTU which will drop it. # # What you appear to be saying is that in some cases of misconfiguration # data will simply fail to flow. This would presumably be detected by # the user and would result in te operator running diagnostics and # looking at coniguration details. butit seems to me that in other cases # the initial state might coincdentally be fine even with two Masters # because they happen to agree. However, after a failure, the two # Masters might take different decisions resulting in no recovery even # though the consumer had been led to believe that there was adequate # protection in place. # # If you are determined to not detect and report such misconfiguration, # I think you should enhance the quoted text to read: # # Note that the behavior # described in this section assumes correct configuration of the Master # and Slave endpoints. This document does not define a mechanism to # detect errors in the configuration, and misconfiguration might lead # to protection switchover failing to work correctly. --- Section 7.1 When a PE enters the AC receive (or transmit) defect state for a PW, it MUST send a forward (reverse) defect indication to the remote peers over all PWs in the redundancy set when required by the PW type in [8] . I think this is subtly incorrect. It applies only to PWs in the redundancy set that terminate at the PE and that are connected to the AC. # I believe the case you are missing here is that there are PWs in the # redundant set that do not terminate at this PE. It is impossible for # the PE that enters the AC receive (or transmit) defect state for a PW # to send (or cause to be sent) a defect indication over PWs that are # not local. See Figure 15-2 for an example: When PE1 enters the AC # receive defect state for PW1, it cannot cause a defect indication to # be sent on PW2. Similarly PE2 (entering the receive or transmit defect # state for PW1) will not be able to send a defect indication on PW2. # Nevertheless, PW2 is in the redundant set. # # What is more, I don't think you want indications sent on PW2 in this # situation. # # Furthermore, consider when there are two ACs from CE1 to PE1. AC1 # connects to PW1, and AC2 connects to PW2. The AC/PW pairs provide # protection and so the PWs are in a redundant set. When PE1 detects # an error on AC1 and enters AC receive defect state for PW1, I don't # think you want it to transmit a defect indication on PW2. --- Section 8 A PE implementation compliant to RFC 4447 [2], and which does not support the generation or processing of the 'Preferential Forwarding' status bit or of the 'request switchover' status bit, will ignore these status bits if they are received from a peer PE. I struggled to find this behavior defined in RFC 4447. While I believe that many implementations might take this approach, I also think many might view the text in 4447 that indicates that the bits represent "faults" to mean that even unknown status code bits should be interpreted as PW failures. (Hence my burbling earlier about flipping the sense of the bits.) If you can point me at the text in 4447, I will back off this issue. # In discussion of this point via email you suggested: # 1. RFC 4447 never intended its rules to apply to future bit settings # 2. RFC 5036 has an overriding definintion of "status" # # But 5036 (which is only a cleaned up version of 3036) does not deal # with the PW status concept since it exists purely for MPLS signaling. # Furthermore, the status codes in 5036 represent LDP protocol events # and statuses and are encoded as one-shot integers. Indeed, it is only # when the LDP Status TLV status code is set to 0x00000028, "PW status" # (a status code not even listed in RFC 5036), that the PW status code # defined in RFC 4447 is used. So I think that 5036 is a side-track for # this discussion. # # That brings us back to RFC 4447 where we have in Section 5.4.2: # # Each bit in the status code field can be set individually to indicate # more than a single failure at once. Each fault can be cleared by # sending an appropriate Notification message in which the respective # bit is cleared. The presence of the lowest bit (PW Not Forwarding) # acts only as a generic failure indication when there is a link-down # event for which none of the other bits apply. # # It is obviously your contention that this text is not quite what was # intended because: # a. you think the field can be used to convey status as well as failure # conditions # b. you think the field can be used to carry instructions as well as # failure conditions and statuses # c. you think that the rules about carrying multiple bits can vary # depending on what bits are set # d. you think that a receiver that does not understand a set bit MUST # ignore that bit. # # I can live with all or any of these rules, but I insist they are new # rules. They must be stated clearly and they must be stated as an # update to RFC 4447. --- On re-reading Section 5.2 I cannot work out what happens if the Master node is the PE that fails. It looks like this is not covered and would provide a problem. # You responded via email that in the case the Master fails nothing can # work because the T-LDP session is down. # # Now let's try to clear this up... # # In Section 5.2 you have # One endpoint node of the redundant set of PWs is designated the # Master and is responsible for selecting which PW both endpoints must # use to forward user traffic. # So there is exactly one Master for a redundant set. # But in some scenarios, for example, that in Figure 15-2, there are # plenty of options. Are you saying that if, in this figure, PE1 is # designated the Master, and if PE1 fails, it will be impossible to # send data via PE2? I don't believe this is your intent. |
2012-09-15
|
08 | Adrian Farrel | [Ballot comment] I continue to be disappointed by the piecemeal invention of bolt-on signaling features for PW management. It really seems that the working group … [Ballot comment] I continue to be disappointed by the piecemeal invention of bolt-on signaling features for PW management. It really seems that the working group needs to work on a functional architecture for pseudowires to work out all of the bits and pieces that are needed for redundancy, bandwidth, multi-segment routing, etc., etc. I wish this would happen before we incrementally munge the protocol too much, but I understand that this is not directly actionable for the authors of this document. --- Section 5.2 One endpoint node of the redundant set of PWs is designated the Master and is responsible for selecting which PW both endpoints must use to forward user traffic. I think... s/must// # The word "MUST" is redundant. --- Section 10 # Does anyone really intend to produce a new MIB module? --- # The volume of change seems substantial. Is the WG OK with these # changes? --- # Need to run id-nits again and tidy up the document. --- # Section 2 bullet c # Stray additional period. |
2012-09-15
|
08 | Adrian Farrel | Ballot comment and discuss text updated for Adrian Farrel |
2012-09-14
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-09-14
|
08 | Mustapha Aissaoui | New version available: draft-ietf-pwe3-redundancy-bit-08.txt |
2012-05-24
|
07 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-05-24
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-05-23
|
07 | Benoît Claise | [Ballot discuss] 1. In the section 10, you wrote: This document makes the following update to the PwOperStatusTC textual convention in RFC 5542 … [Ballot discuss] 1. In the section 10, you wrote: This document makes the following update to the PwOperStatusTC textual convention in RFC 5542 [9]: You can't simply update a Textual Convention (TC) like this, but putting a new TC, out of context. A TC belongs to a MIB module. You need a new revision of that MIB module: RFC5542bis. Note: you could cut/paste the new revision of the MIB module in this document, and obsolete RFC5542, but that would be misleading from the document title. Also, having a new RFC5542bis will cause some problems: there are many TCs in there, so surely, many references to RFC5542... which in turn will need to be updated. Now, looking more closely at your proposed change. - dormant(4): The PW is not in a condition to pass packets but is in a 'pending' state, waiting for some external event. For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY". The only change that you require is the addition of "For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY" in dormant(4). IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't require the extra work to produce RFC5542bis. Indeed, you don't change the TC semantic. What I believe you should be doing is: - a sentence such as (I trust you on the exact wording): this document illustrates how the dormant value of the PwOperStatusTC TC can be used to ..." and you include the meaning of your initial extra sentence - you remove "update: RFC 5542" 2. - Section 5.1 "independent mode". What do you mean by "management indication" in: In steady state with consistent configuration, a PE will always find an active PW. However, it is possible that such a PW is not found due to a mis-configuration. In the event that an active PW is not found, a management indication SHOULD be generated. If a management indication for failure to find an active PW was generated and an active PW is subsequently found, a management indication SHOULD be generated, so clearing the previous failure indication. Additionally, a PE MAY use the optional request switchover procedures described in Section 6.3. to have both PE nodes switch to a common PW. A syslog message, a SNMP notification, something else, or this is left completely open... in other words: "please do a little bit of management to please the OPS people ;-)" Can you justify why you don't even mention "management indication" in the second mode, i.e. section 5.2 "master/slave mode" note: I never seen the term management "indication". Do you want to say "management notification"? 3. Here is another point, reported by Dan Romascanu, which I cut/pasted here: I did not have the time for a full OPS-DIR review, but I had a look at draft-ietf-pwe3-redundancy-bit which is on the IESG agenda tomorrow. Benoit entered a DISCUSS on a specific issue related to a proposed modification of the PwOperStatusTC from RFC 5542, which I support, but I think that the manageability problems with this I-D are broader. From an operator perspective I believe that there needs to be clear indication of the modes of operation (Independent, Master/Slave) besides the active / standby status of the PW, otherwise there will be no way to understand the status and configuration in different network situations. This may lead to changes to RFC 5542, but I think that mentioning just the MIB changes is not sufficient, as implementing the MIB modules is not mandatory for all PW devices, so the need to expose the modes and forwarding states needs to operators needs to be made in a protocol-independent manner. |
2012-05-23
|
07 | Benoît Claise | Ballot discuss text updated for Benoit Claise |
2012-05-23
|
07 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-05-23
|
07 | Miguel García | Request for Telechat review by GENART Completed. Reviewer: Miguel Garcia. |
2012-05-23
|
07 | Russ Housley | [Ballot comment] Please consider the issues raised in the Gen-ART Review by Miguel Garcia on 23-May-2012. I tend to agree with his points … [Ballot comment] Please consider the issues raised in the Gen-ART Review by Miguel Garcia on 23-May-2012. I tend to agree with his points on RFC 2119 language in Sections 5 and 15. Please find the review at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07447.html. |
2012-05-23
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-05-23
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-05-23
|
07 | Adrian Farrel | [Ballot discuss] [Discuss updated 5/23 to cross-reference the requirements document for non-reversion and detection of misconfiguration, and to make observations about the failure of a … [Ballot discuss] [Discuss updated 5/23 to cross-reference the requirements document for non-reversion and detection of misconfiguration, and to make observations about the failure of a Master in master/slave mode.] I have a long and rather rambling Discuss on this document. I think that it is important to address the requirements of management and control of end-to-end service protection as provided by PWs, so I am in no way rejecting the concept of this document. On the other hand, I found quite a number of issues that caused me concern. I have split these across this Discuss (where I hope changes to the text, or conversations in email, will resolve the issues) and Comments where I am less bothered by how or whether you address the issues. --- Section 1 In order to support AC or spoke PW redundancy, at least one of the PEs on which a PW terminates MUST be different from that on which the primary PW terminates, as described in [6]. This is not true, is it? Well, it may be true that the reference says this, but in that case the reference is wrong. AC redundancy can be provided using a pair of parallel ACs between the same CE and PE pair (although this seems to be explicitly excluded by figure 4-1). What you are describing is PE protection. I think some of the confusion here is because of the terminology inconsistency. RFC 3985 is quite clear that the AC does not form part of the PW. So, this document is all about protecting the emulated service. This does appear to be noticed earlier in the section where it says: Scenarios, such as those above, therefore rely on a set of two or more pseudowires to protect a given VPWS or VPLS. I believe that the document should be clear up front that two protection mechanisms are being described in this document. The first is end-to-end service protection (where AC and T-PE failure are protected) and end-to- end PW protection (where the working and protection PWs run between the same pair of T-PEs). The document also needs to note clearly that PW segment protection (i.e. working and protection [multi-] segment protection between a pair of S-PEs) is out of scope. >> Ah, I found this in the last paragraph of Section 2. A bit lost in the morass of other text. Note that an excellent way to handle this discuss will be the wholesale deletion of text and replacement with a simple reference to [6]. --- Looks to me that [6] is used normatively. --- It is not clear to me why you don't support 1+1 protection. But section 2 clearly rules it out. In the absence of faults, all PWs are UP both locally and remotely and a PE node needs to select a single PW to forward user packets to. This is referred to as the active PW. All other PWs will be in standby and MUST NOT be used to forward user packets. Perhaps this restriction should be stated. Or is there the possibility that a future protocol extension will be made to add 1+1 support? --- Section 2 In order for both ends of the service to select the same PW for forwarding user packets, this document defines a new status bit, the 'Preferential Forwarding' status bit, to allow a PE node to indicate the preferential forwarding state of a PW to its peer PE node. I may have missed something here, but in 1:1 end-to-end *service* protection, the choice of which PW to use has to be made at the CE not the T-PE. But the signaling (LDP) is between PEs. How does the CE learn the settings of the status code bits? --- I think there is some confusion about when bits are set and cleared in the status code. Some of this is textual. Section 11.1 has... 0x00000020 When the bit is set, it indicates "PW forwarding standby". When the bit is cleared, it indicates "PW forwarding active". Which is good and means that the text should probably refer to this as the "PW forwarding standby bit" rather than "PW Preferential Forwarding" as currently in section 6. (Note that IANA will need a name for the bit in the registry - they seem to have dug the names out of section 6, but this should be explicit in the IANA section of the document). Then the bit used for requesting switchover gives me a problem. While I understand the issues (selection from a pool that may be larger than 1, need to synchronize, etc.), the explanation of the status code field in RFC 4447 is clear that setting a bit represents a "fault". Thus, it would be reasonable to handle a set bit as "cannot send traffic on this PW" whereas you are asking for it to mean "please send traffic on this PW". (Again, IANA will need a name for this bit in the registry.) I do wonder whether, given the existence of OAM and fault status bits, and the definition of precedence, you need this bit. It even seems to allow conflict with the precedence. --- What happens when a T-PE that supports this I-D sends a switchover request to a T-PE that foes not support this I-D? Presumably it will register the request as a fault (as above) and will not send traffic. --- In section 2 a. A MANDATORY 1:1 PW protection with a single active PW and one standby PW. An active PW can forward data traffic and control plane traffic, such as Operations, Administration, and Maintenance (OAM) packets. A standby PW does not carry data traffic. This does not say whether OAM packets and be carried on a standby PW. Later, in section 3, I find: Standby PW: An UP PW that is not used for forwarding user traffic, but MAY forward OAM and specific control plane traffic. And so on (e.g. Section 6.1) When a PW is in Standby state, the PEs MUST NOT forward user packets over the PW but MAY forward PW OAM packets and specific control plane packets. Perhaps, rather than listing types of message, you should note that all ACH packets are allowed. --- Section 2 b. Multi-homing of a PE node to two or more PE nodes. What does this mean? A PE is multi-homed to multiple PEs? I suppose you are trying to talk about parallel PWs between two T-PEs, and a PE that is at the far end of a relationship with a CE that is multi-homed to more than one T-PE? --- Section 3 The designation of Primary is performed by local configuration for the PW at the PE and is only required when revertive behavior is used. But all of the text (for example, in 5.1 and 5.2) uses MUST for reversion, so there appears to be no option. Which is odd because the second requiremen of Section 4.1 of draft-ietf-pwe3-redundancy says that non-revertive behavior MUST be supported. --- Section 5 I think that you need to clarify which mode of operation would be used in the case of figure 15-2. I think that master/slave mode cannot be used, and that independent mode only works with configuration. There is a degenerate case of this topology where there is absolutely no LDP communication between the PEs on the active PW and those on the standby PW. --- Section 5.1 first point 2 "we propose" please restate this protocol specification in terms of absolute statements of required behavior. --- Section 5.2. Note that the behavior described in this section assumes correct configuration of the Master and Slave endpoints. This document does not define a mechanism to detect errors in the configuration. I suggest this is broken. You should at least be able to detect the error (not necessary to be able to resolve it) and report it. Also to not get into an unresolvable protocol breakdown when there are two T-PEs that think they are Masters. Actually, requirements 2 and 3 of Section 4.2 of draft-ietf-pwe3-redundancy seem to speak against this text. --- The timers need to have recommended defaults, and should be called out as configurable. --- Section 7 [5] is used normatively. [8] is used normatively. --- Section 7 The procedures for determining and mapping PW and AC states MUST follow the rules in [8] with the following modifications. Does that mean this document updates [8]? --- Section 7.1 When a PE enters the AC receive (or transmit) defect state for a PW, it MUST send a forward (reverse) defect indication to the remote peers over all PWs in the redundancy set when required by the PW type in [8] . I think this is subtly incorrect. It applies only to PWs in the redundancy set that terminate at the PE and that are connected to the AC. --- Section 8 A PE implementation compliant to RFC 4447 [2], and which does not support the generation or processing of the 'Preferential Forwarding' status bit or of the 'request switchover' status bit, will ignore these status bits if they are received from a peer PE. I struggled to find this behavior defined in RFC 4447. While I believe that many implementations might take this approach, I also think many might view the text in 4447 that indicates that the bits represent "faults" to mean that even unknown status code bits should be interpreted as PW failures. (Hence my burbling earlier about flipping the sense of the bits.) If you can point me at the text in 4447, I will back off this issue. --- Section 9 I don't think this section should be so banal. You are introducing a feature that allows the compromise of signaling for one PW between one pair of PEs, to change the behavior (disruptively) on a PW between another pair of PEs. That seems to be a new and interesting attack vector. Therefore, you should at least flag this point and note that security on a redundant set is only as good as the weakest security on any member of that group. --- On re-reading Section 5.2 I cannot work out what happens if the Master node is the PE that fails. It looks like this is not covered and would provide a problem. |
2012-05-23
|
07 | Adrian Farrel | Ballot discuss text updated for Adrian Farrel |
2012-05-22
|
07 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-05-22
|
07 | Adrian Farrel | [Ballot discuss] I have a long and rather rambling Discuss on this document. I think that it is important to address the requirements of management … [Ballot discuss] I have a long and rather rambling Discuss on this document. I think that it is important to address the requirements of management and control of end-to-end service protection as provided by PWs, so I am in no way rejecting the concept of this document. On the other hand, I found quite a number of issues that caused me concern. I have split these across this Discuss (where I hope changes to the text, or conversations in email, will resolve the issues) and Comments where I am less bothered by how or whether you address the issues. --- Section 1 In order to support AC or spoke PW redundancy, at least one of the PEs on which a PW terminates MUST be different from that on which the primary PW terminates, as described in [6]. This is not true, is it? Well, it may be true that the reference says this, but in that case the reference is wrong. AC redundancy can be provided using a pair of parallel ACs between the same CE and PE pair (although this seems to be explicitly excluded by figure 4-1). What you are describing is PE protection. I think some of the confusion here is because of the terminology inconsistency. RFC 3985 is quite clear that the AC does not form part of the PW. So, this document is all about protecting the emulated service. This does appear to be noticed earlier in the section where it says: Scenarios, such as those above, therefore rely on a set of two or more pseudowires to protect a given VPWS or VPLS. I believe that the document should be clear up front that two protection mechanisms are being described in this document. The first is end-to-end service protection (where AC and T-PE failure are protected) and end-to- end PW protection (where the working and protection PWs run between the same pair of T-PEs). The document also needs to note clearly that PW segment protection (i.e. working and protection [multi-] segment protection between a pair of S-PEs) is out of scope. >> Ah, I found this in the last paragraph of Section 2. A bit lost in the morass of other text. Note that an excellent way to handle this discuss will be the wholesale deletion of text and replacement with a simple reference to [6]. --- Looks to me that [6] is used normatively. --- It is not clear to me why you don't support 1+1 protection. But section 2 clearly rules it out. In the absence of faults, all PWs are UP both locally and remotely and a PE node needs to select a single PW to forward user packets to. This is referred to as the active PW. All other PWs will be in standby and MUST NOT be used to forward user packets. Perhaps this restriction should be stated. Or is there the possibility that a future protocol extension will be made to add 1+1 support? --- Section 2 In order for both ends of the service to select the same PW for forwarding user packets, this document defines a new status bit, the 'Preferential Forwarding' status bit, to allow a PE node to indicate the preferential forwarding state of a PW to its peer PE node. I may have missed something here, but in 1:1 end-to-end *service* protection, the choice of which PW to use has to be made at the CE not the T-PE. But the signaling (LDP) is between PEs. How does the CE learn the settings of the status code bits? --- I think there is some confusion about when bits are set and cleared in the status code. Some of this is textual. Section 11.1 has... 0x00000020 When the bit is set, it indicates "PW forwarding standby". When the bit is cleared, it indicates "PW forwarding active". Which is good and means that the text should probably refer to this as the "PW forwarding standby bit" rather than "PW Preferential Forwarding" as currently in section 6. (Note that IANA will need a name for the bit in the registry - they seem to have dug the names out of section 6, but this should be explicit in the IANA section of the document). Then the bit used for requesting switchover gives me a problem. While I understand the issues (selection from a pool that may be larger than 1, need to synchronize, etc.), the explanation of the status code field in RFC 4447 is clear that setting a bit represents a "fault". Thus, it would be reasonable to handle a set bit as "cannot send traffic on this PW" whereas you are asking for it to mean "please send traffic on this PW". (Again, IANA will need a name for this bit in the registry.) I do wonder whether, given the existence of OAM and fault status bits, and the definition of precedence, you need this bit. It even seems to allow conflict with the precedence. --- What happens when a T-PE that supports this I-D sends a switchover request to a T-PE that foes not support this I-D? Presumably it will register the request as a fault (as above) and will not send traffic. --- In section 2 a. A MANDATORY 1:1 PW protection with a single active PW and one standby PW. An active PW can forward data traffic and control plane traffic, such as Operations, Administration, and Maintenance (OAM) packets. A standby PW does not carry data traffic. This does not say whether OAM packets and be carried on a standby PW. Later, in section 3, I find: Standby PW: An UP PW that is not used for forwarding user traffic, but MAY forward OAM and specific control plane traffic. And so on (e.g. Section 6.1) When a PW is in Standby state, the PEs MUST NOT forward user packets over the PW but MAY forward PW OAM packets and specific control plane packets. Perhaps, rather than listing types of message, you should note that all ACH packets are allowed. --- Section 2 b. Multi-homing of a PE node to two or more PE nodes. What does this mean? A PE is multi-homed to multiple PEs? I suppose you are trying to talk about parallel PWs between two T-PEs, and a PE that is at the far end of a relationship with a CE that is multi-homed to more than one T-PE? --- Section 3 The designation of Primary is performed by local configuration for the PW at the PE and is only required when revertive behavior is used. But all of the text (for example, in 5.1 and 5.2) uses MUST for reversion, so there appears to be no option. --- Section 5 I think that you need to clarify which mode of operation would be used in the case of figure 15-2. I think that master/slave mode cannot be used, and that independent mode only works with configuration. There is a degenerate case of this topology where there is absolutely no LDP communication between the PEs on the active PW and those on the standby PW. --- Section 5.1 first point 2 "we propose" please restate this protocol specification in terms of absolute statements of required behavior. --- Section 5.2. Note that the behavior described in this section assumes correct configuration of the Master and Slave endpoints. This document does not define a mechanism to detect errors in the configuration. I suggest this is broken. You should at least be able to detect the error (not necessary to be able to resolve it) and report it. Also to not get into an unresolvable protocol breakdown when there are two T-PEs that think they are Masters. --- The timers need to have recommended defaults, and should be called out as configurable. --- Section 7 [5] is used normatively. [8] is used normatively. --- Section 7 The procedures for determining and mapping PW and AC states MUST follow the rules in [8] with the following modifications. Does that mean this document updates [8]? --- Section 7.1 When a PE enters the AC receive (or transmit) defect state for a PW, it MUST send a forward (reverse) defect indication to the remote peers over all PWs in the redundancy set when required by the PW type in [8] . I think this is subtly incorrect. It applies only to PWs in the redundancy set that terminate at the PE and that are connected to the AC. --- Section 8 A PE implementation compliant to RFC 4447 [2], and which does not support the generation or processing of the 'Preferential Forwarding' status bit or of the 'request switchover' status bit, will ignore these status bits if they are received from a peer PE. I struggled to find this behavior defined in RFC 4447. While I believe that many implementations might take this approach, I also think many might view the text in 4447 that indicates that the bits represent "faults" to mean that even unknown status code bits should be interpreted as PW failures. (Hence my burbling earlier about flipping the sense of the bits.) If you can point me at the text in 4447, I will back off this issue. --- Section 9 I don't think this section should be so banal. You are introducing a feature that allows the compromise of signaling for one PW between one pair of PEs, to change the behavior (disruptively) on a PW between another pair of PEs. That seems to be a new and interesting attack vector. Therefore, you should at least flag this point and note that security on a redundant set is only as good as the weakest security on any member of that group. |
2012-05-22
|
07 | Adrian Farrel | [Ballot comment] In case anyone is hunting, I can find just 4 out of the 12 authors confirming on the PWE3 list that they are … [Ballot comment] In case anyone is hunting, I can find just 4 out of the 12 authors confirming on the PWE3 list that they are not aware of any IPR disclosures that need to be made. --- I continue to be disappointed by the piecemeal invention of bolt-on signaling features for PW management. It really seems that the working group needs to work on a functional architecture for pseudowires to work out all of the bits and pieces that are needed for redundancy, bandwidth, multi-segment routing, etc., etc. I wish this would happen before we incrementally munge the protocol too much, but I understand that this is not directly actionable for the authors of this document. --- You need to remove the citation from the Abstract. --- The document was pretty hard to review because there are repetitions and overlap between sections. Do you need all the text? --- Please clean up "redundant set" or "redundancy set" --- There's a lot of terminology in the Introduction that need clarifying. I found... SS-PW PW MS-PW T-PE PE-rs PE PWE3 --- Section 1 Only one of these pseudowires is used by the PEs to forward user traffic on at any given time. delete "on" --- Figure 1-1 s/Pseudowire/Pseudowires/ --- Please decide "pseudowire" or "pseudo wire". Cf. RFC 3985 figure 2 and draft-ietf-pwe3-redundancy figure 2 --- Section 1 In this case, multiple MS-PWs are configured between a pair of T-PE nodes, as described in Figure 2 of [6]. Figure 2 of [6] would appear to be identical to figure 1-1. Why do you reference it? --- Section 1 This document specifies a new PW status bit to indicate the preferential forwarding status of the PW for the purpose of notifying the remote PE of the preferential forwarding state of each PW in the redundancy set i.e. Active or Standby. Please say "remote T-PE". --- Section 2 The PWE3 control protocol [2] defines the following status codes in the PW status TLV to indicate the state for an AC and a PW: 0x00000000 - Pseudowire forwarding (clear all failures) 0x00000001 - Pseudowire Not Forwarding 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 0x00000010 - Local PSN-facing PW (egress) Transmit Fault Firstly, I think these values are defined in RFC 4446 not RFC 4447. Then, I think there is actually no need to list the values here. You could, if you like, point to the registry. But reading this section, I am not sure that this quoted text is pertinent. --- Section 2 You have put some terms in upper case that are not from RFC 2119. Anyway, I am not convinced that RFC 2119 usage is helpful in this early and descriptive section. Lowercase would be just fine. --- Figure 4-1 caption s/Architecure/Architecture/ --- Section 2 point d. s/qualify/qualifies/ --- Section 3 I think you could prune this section quite heavily. For example, it is probably not necessary to define a pseudowire or a PE. --- Section 5.1 The PW which corresponds to the minimum of the compared values across all PWs in the redundant is selected. s/redundant/redundant set/ ? --- Section 5.2 One endpoint node of the redundant set of PWs is designated the Master and is responsible for selecting which PW both endpoints MUST use to forward user traffic. I think... s/MUST// --- Section 7.2 A PE enters the PW receive (or transmit) defect state for a PW service when one or more of the conditions specified in Section 8.2.1 (Section 8.2.2) in [8] are met for all PWs in the redundancy set. For the avoidance of doubt, I think you should s/for all/for each of the/ (It is not necessary that the same defect state should exist on each PW) --- Section 10 I completely support Benoit's Discuss on this section. You cannot revise a MIB module like this. However, it really looks like you don't want to make a revision at all. Changing one Description clause by adding "for example" is really not worth the effort. Why don't you just write an applicability note saying how the TC is used to support the function described in this I-D? --- Author's Addresses s/Author's/Authors'/ |
2012-05-22
|
07 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2012-05-22
|
07 | Sean Turner | [Ballot comment] Note these comments are the same for both draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit. Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit. Can't you … [Ballot comment] Note these comments are the same for both draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit. Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit. Can't you just point from on to the other? This uses the TCP MD5 "signature" option [RFC5036]. KARP's hopefully going to get this fixed sooner rather than later. So there's nothing for the authors to do about this otherwise recurring gripe. I'd like to suggest some tweaks to the security considerations section, assuming of course that I've not totally missed the mark: 1st - I think the "LDP extensions" are referred to as options in both RFC 4447 and 5036? 2nd - I think there's only one of them? 3rd - I think you mean control plane not control protocol? How about the following tweaks to the security considerations section: This document uses the TCP MD5 Signature option, as specified in [2], to protect pseudowires. This document has the same security considerations as in the PWE3 control-plane [2]. If you want to future proof the text more maybe: LDP extensions/options that protect pseudowires must be implemented because the security considerations for the bits defined in this document have the same security considerations as the PWE3 control-plane [2]. |
2012-05-22
|
07 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-05-22
|
07 | Benoît Claise | [Ballot discuss] 1. In the section 10, you wrote: This document makes the following update to the PwOperStatusTC textual convention in RFC 5542 … [Ballot discuss] 1. In the section 10, you wrote: This document makes the following update to the PwOperStatusTC textual convention in RFC 5542 [9]: You can't simply update a Textual Convention (TC) like this, but putting a new TC, out of context. A TC belongs to a MIB module. You need a new revision of that MIB module: RFC5542bis. Note: you could cut/paste the new revision of the MIB module in this document, and obsolete RFC5542, but that would be misleading from the document title. Also, having a new RFC5542bis will cause some problems: there are many TCs in there, so surely, many references to RFC5542... which in turn will need to be updated. Now, looking more closely at your proposed change. - dormant(4): The PW is not in a condition to pass packets but is in a 'pending' state, waiting for some external event. For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY". The only change that you require is the addition of "For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY" in dormant(4). IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't require the extra work to produce RFC5542bis. Indeed, you don't change the TC semantic. What I believe you should be doing is: - a sentence such as (I trust you on the exact wording): this document illustrates how the dormant value of the PwOperStatusTC TC can be used to ..." and you include the meaning of your initial extra sentence - you remove "update: RFC 5542" 2. - Section 5.1 "independent mode". What do you mean by "management indication" in: In steady state with consistent configuration, a PE will always find an active PW. However, it is possible that such a PW is not found due to a mis-configuration. In the event that an active PW is not found, a management indication SHOULD be generated. If a management indication for failure to find an active PW was generated and an active PW is subsequently found, a management indication SHOULD be generated, so clearing the previous failure indication. Additionally, a PE MAY use the optional request switchover procedures described in Section 6.3. to have both PE nodes switch to a common PW. A syslog message, a SNMP notification, something else, or this is left completely open... in other words: "please do a little bit of management to please the OPS people ;-)" Can you justify why you don't even mention "management indication" in the second mode, i.e. section 5.2 "master/slave mode" note: I never seen the term management "indication". Do you want to say "management notification"? |
2012-05-22
|
07 | Benoît Claise | [Ballot comment] - Section 12 "Major Contributing Authors" Not sure if it's a good idea to have this new section title. Knowing how sensitive this … [Ballot comment] - Section 12 "Major Contributing Authors" Not sure if it's a good idea to have this new section title. Knowing how sensitive this authors/contributors topic is, I wouldn't like to see a precedent with this future RFC ,i.e. "I see a Major Contributing Authors, so can we have Minor Contributing Authors section now?" So I would prefer "contributors" and "authors" sections. - Section 5.1 1. For FEC128 PW, the PW with the lowest pw-id value is selected. 2. For FEC129 PW, each PW in a redundant set is uniquely identified No idea what FEC128 and FEC129 were. I had to search and found http://tools.ietf.org/html/rfc4379#section-3.2.8, where by the way, they're spelled "FEC 128" and "FEC 129". So please add a reference. |
2012-05-22
|
07 | Benoît Claise | [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise |
2012-05-21
|
07 | Pete Resnick | [Ballot comment] Section 2: MANDATORY OPTIONAL OPTIONALLY Neither MANDATORY nor OPTIONALLY are 2119 terms. I suspect that the capitalized words in this section are a … [Ballot comment] Section 2: MANDATORY OPTIONAL OPTIONALLY Neither MANDATORY nor OPTIONALLY are 2119 terms. I suspect that the capitalized words in this section are a new magical usage of which I am unaware. Perhaps you might like to define terms? 5.1 The PW endpoints MAY also implement the following optional active PW selection mechanism. 1. If the PW endpoint is configured with the precedence parameter on each PW in the redundant set, it MUST select the PW with the lowest configured precedence value. So you MAY do something that you MUST do? I am confused. a management indication SHOULD be generated I may not understand what is meant by a "management indication" here, but it sounds like an implementation choice, not something that is required for interoperation. Did I get that wrong? |
2012-05-21
|
07 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-05-21
|
07 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-05-21
|
07 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-05-21
|
07 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-05-21
|
07 | Stephen Farrell | [Ballot comment] The security considerations say that this is the same as for 4447, which is arguably correct, but 4447 really defers to 3036, which … [Ballot comment] The security considerations say that this is the same as for 4447, which is arguably correct, but 4447 really defers to 3036, which a) doesn't consider switching over to a "less good" PW as a potential DoS (is it?) and b) only has TCP-MD5 based security which even in 2001 attracted an IESG note, repeated in 3036 from rfc 2385 (from 1998!). Any chance of getting some 21st century security stuff done in PW-land? (Sorry, but that's hard to resist:-) This is probably not the place to fix that, but it'd be good to know if there's a plan. Is there? Nits: - PE-rs is used without expansion (on p2) - FEC128 and FEC129 are used without definition on p11 (As as AGI::SAII:TAII) - What is the "system IP address"? (on p11) Could be fairly obvious, but then again if a node has many addresses, maybe not. |
2012-05-21
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-05-21
|
07 | Martin Stiemerling | [Ballot comment] Please check the idnits: Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines … [Ballot comment] Please check the idnits: Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC5542, but the abstract doesn't seem to directly say this. It does mention RFC5542 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) -- however, there's a paragraph with a matching beginning. Boilerplate error? IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii): "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." ... text found in draft: "Code Components extracted from this document must include Simplified BSD ......^ License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License." -- The document date (May 1, 2012) is 20 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) == Outdated reference: A later version (-08) exists of draft-ietf-pwe3-redundancy-07 |
2012-05-21
|
07 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-05-17
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Miguel Garcia |
2012-05-17
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Miguel Garcia |
2012-05-14
|
07 | Stewart Bryant | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2012-05-14
|
07 | Stewart Bryant | Placed on agenda for telechat - 2012-05-24 |
2012-05-14
|
07 | Stewart Bryant | Ballot has been issued |
2012-05-14
|
07 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2012-05-14
|
07 | Stewart Bryant | Ballot writeup was changed |
2012-05-14
|
07 | Stewart Bryant | Created "Approve" ballot |
2012-05-01
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-05-01
|
07 | Mustapha Aissaoui | New version available: draft-ietf-pwe3-redundancy-bit-07.txt |
2012-04-30
|
06 | Pearl Liang | IANA understands that, upon approval of this document, there is a single IANA action which must be completed. In the Pseudowire Status Codes Registry in … IANA understands that, upon approval of this document, there is a single IANA action which must be completed. In the Pseudowire Status Codes Registry in Pseudowire Name Spaces (PWE3) registry located at: www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml the following, new registrations will be added: Bitmask: 0x00000020 Description: PW Preferential Forwarding Reference: [ RFC-to-be ] Bitmask: 0x00000040 Description: PW Request Switchover Reference: [ RFC-to-be ] |
2012-04-05
|
06 | Stewart Bryant | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead |
2012-03-21
|
06 | Miguel García | Request for Last Call review by GENART Completed. Reviewer: Miguel Garcia. |
2012-03-21
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-03-19
|
06 | Matthew Bocci | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2012-03-19
|
06 | Matthew Bocci | IETF state changed to Submitted to IESG for Publication from WG Document |
2012-03-09
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Miguel Garcia |
2012-03-09
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Miguel Garcia |
2012-03-08
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tim Polk |
2012-03-08
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tim Polk |
2012-03-07
|
06 | Matthew Bocci | ... |
2012-03-07
|
06 | Matthew Bocci | ... |
2012-03-07
|
06 | Matthew Bocci | AD comments addressed. Waiting for GenART review. |
2012-03-07
|
06 | Cindy Morgan | Last call sent |
2012-03-07
|
06 | Cindy Morgan | State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-03-07
|
06 | Stewart Bryant | Last call was requested |
2012-03-07
|
06 | Stewart Bryant | Ballot approval text was generated |
2012-03-07
|
06 | Stewart Bryant | Ballot writeup was generated |
2012-03-07
|
06 | Stewart Bryant | State changed to Last Call Requested from AD Evaluation::AD Followup |
2012-03-07
|
06 | Stewart Bryant | Last call announcement was generated |
2012-02-27
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-02-27
|
06 | Mustapha Aissaoui | New version available: draft-ietf-pwe3-redundancy-bit-06.txt |
2011-11-25
|
05 | Stewart Bryant | State changed to AD Evaluation::Revised ID Needed from Publication Requested. |
2011-11-03
|
05 | Cindy Morgan | (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 … (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? Andy Malis Yes, I have reviewed this revision and believe it is ready for publication. (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? Yes, it has been well reviewed and received a lot of discussion through its iterations. There are no concerns regarding reviews. (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? No. (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. 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. No concerns or issues. No IPR has been filed. (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. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist 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? There were a couple of minor nits, such as eight lines that are too long. There's nothing that wouldn't be caught by the RFC Editor. (1.h) Has the document split its references into normative and informative? 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]. The references are split. All of the normative references have already been published. There are no downward references. There are two informative references that are still drafts. One of these has already been submitted to the IETF, and the other is an L2VPN WG draft that is well in progress (it was just updated to -05 on Oct. 31). (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? 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 [RFC5226]. 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? IANA is asked to allocate two new status codes in an existing registry, Pseudowire Status Codes Registry. (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? N/A (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 a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is used to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is used to allow peer PE nodes to coordinate a switchover operation of the PW. This document is a product of the PWE3 working group. This document is STANDARDS TRACK. Working Group Summary: This document represents the consensus of the working group. Document Quality: There are no concerns regarding the document's quality. Personnel: Who is the Document Shepherd for this document? Andy Malis Who is the Responsible Area Director? Stewart Bryant |
2011-11-03
|
05 | Cindy Morgan | Draft added in state Publication Requested |
2011-11-03
|
05 | Cindy Morgan | [Note]: 'Andy Malis (amalis@gmail.com) is the document shepherd.' added |
2011-10-01
|
05 | Andy Malis | IETF state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2011-10-01
|
05 | Andy Malis | Awaiting document shepherd writeup for IESG submission |
2011-10-01
|
05 | Andy Malis | Annotation tag Doc Shepherd Follow-Up Underway set. Annotation tag Waiting for Referenced Document cleared. |
2011-09-21
|
05 | (System) | New version available: draft-ietf-pwe3-redundancy-bit-05.txt |
2011-09-15
|
05 | (System) | Document has expired |
2011-06-10
|
05 | Andy Malis | Waiting for resolution of working group last call comments on draft-ietf-pwe3-redundancy |
2011-06-10
|
05 | Andy Malis | IETF state changed to Waiting for WG Chair Go-Ahead from WG Document |
2011-06-10
|
05 | Andy Malis | Waiting for resolution of working group last call comments on draft-ietf-pwe3-redundancy |
2011-06-10
|
05 | Andy Malis | Annotation tag Waiting for Referenced Document set. |
2011-03-14
|
04 | (System) | New version available: draft-ietf-pwe3-redundancy-bit-04.txt |
2010-05-14
|
03 | (System) | New version available: draft-ietf-pwe3-redundancy-bit-03.txt |
2009-10-26
|
02 | (System) | New version available: draft-ietf-pwe3-redundancy-bit-02.txt |
2008-09-30
|
01 | (System) | New version available: draft-ietf-pwe3-redundancy-bit-01.txt |
2008-02-29
|
00 | (System) | New version available: draft-ietf-pwe3-redundancy-bit-00.txt |