I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments.
For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over Static Pseudowire" Reviewer: Ralph Droms Review Date: 2015-10-14 IETF LC End Date: 2015-10-19 IESG Telechat date: (if known) N/A Summary: This draft is on the right track but has open issues, described in the review. Major issues: While this document is describing a straightforward adaptation of previously defined standards to statically provisioned PWs, in my opinion an implementor would not necessarily be able to construct a fully interoperable implementation from this document. There are several sections of the document that are not clear in their description of how to use mechanisms from referenced documents in this standard. If it appears that some of my comments are overly finicky, I'll agree that the correct implementation could probably be deduced from the text in most cases. That is, I didn't find many outright errors or inconsistencies. Many of my comments took a lot of paging back and forth, reading of referenced documents and head-scratching, which, in my experience, can lead to implementations that don't interoperate. Section 1: When the number of MAC addresses to be removed is large, the empty MAC List TLV may be used. The empty MAC List TLV signifies wildcard MAC Address withdrawl. This text seems to be the only reference to the processing of an empty MAC List TLV. Specification of how the protocol works doesn't belong in the Introduction, and "wildcard MAC Address withdrawal" could certainly use some more explanation. Section 3: The PW OAM message header is exactly the same as what is defined in [RFC6478]. Is this statement really true? The MAC Address Withdraw header seems to replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" flag. The statement might be misleading to an implementor. a MAC address withdraw OAM message MUST contain a "Sequence Number TLV" otherwise the entire message is dropped. Is the "Sequence Number TLV" required to be the first TLV in the message? Are the TLVs required to appear in any particular order? A single bit (called A-bit) is set to indicate if a MAC withdraw message is for ACK. Also, ACK does not include MAC TLV(s). Does this mean that the message is an ACK if the A-bit is set? Can an ACK contain a "Sequence Number" TLV? Only half of the sequence number space is used. Modular arithmetic is used to detect wrapping of sequence number. When sequence number wraps, all MAC addresses are flushed and the sequence number is reset. The 16-bit sequence number handling is described in [RFC4385]. This document uses 32-bits sequence numbers and hence sequence number in half the number space (i.e. 31-bits or ~2billion) is considered in the valid receive range. This paragraph is not at all clear to me. Reading section 4 of RFC 4385 helped but left me unsure about how my understanding of how to extend the sequence number mechanism to 32 bits corresponds to the expectations of this document. Section 4.1: Each PW is associated with a counter to keep track of the sequence number of the transmitted MAC withdrawal messages. Whenever a node sends a new set of MAC TLVs, it increments the transmitted sequence number counter, and include the new sequence number in the message. The transmit sequence number is initialized to 1 at the onset. I'm pretty sure this is supposed to mean that the sequence number in the first message is 1. The text could be interpreted to mean that the counter is initialized to 1 and then incremented to 2 when sending the first message. The retransmission MUST be ceased anytime when ACK is received or after three retries. This avoids unended retransmissions in the absence of acknowledgements. Since retransmission time interval and the maximum number of retries is local configuration of the sender node, it is up to the implementers to pick a discipline. Is the maximum number of retransmissions 3 or is it locally configured? Is the default 3? The 'R' reset bit is set in the first MAC withdraw to notify the remote peer to reset the send and receive sequence numbers. The 'R' bit must be cleared in subsequent MAC withdraw messages after the acknowledgement is received "First" as in "first message after reset or restart or ??? Would it be better to say "The R-bit is set in a message when one peer needs to force the remote peer to reset its send and receive sequence numbers"? Does the device sending the message with the R-bit use a sequence number of 1 in that message, and expect the next message from the peer to have a sequence number of 1? It would be helpful to state explicitly that a receiver does not compare the contents Sequence Number TLV against the expected sequence number if the R-bit is set in a message. The exact processing on how to handle the sequence number overflow is described in [RFC4385] If this sentence refers to section 4 in RFC 4385, then it describes similar processing for a 16 bit sequence number, not "the exact processing". I know I'm being finicky again, but it's crucial that implementors get this sequence number processing right. Minor issues: (none) Nits/editorial issues: Is there a reason this document does not use RFC 2119 terminology? In the Introduction, I think it would be clearer to explain the general problem first, and then refer back to RFC 4762 and RFC 6478 as the standards on which this document draws. Section 2: s/Provide/Provider/ in the definition of PE? Section 3: In general, I think it's better to specify protocol behavior once and only onc. As an example, this text: the sender re-transmits the message for a configured number of times in the absence of an ACK response for the sequence numbered message. is somewhat redundant with the text describing retransmission in the following section. In fact, much of the entire first paragraph of section 3 describes protocol behavior rather than message format, and might better be combined with the corresponding text in section 4.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
