Subject: [Gen-art] Gen-ART Last Call Review of draft-ietf-pwe3-static-pw-status-08

From: Ben Campbell <[email-masked]>
Date: Tue, 4 Oct 2011 17:13:32 -0500

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-pwe3-static-pw-status-08
Reviewer: Ben Campbell
Review Date: 2011-10-04
IETF LC End Date: 2011-10-05

Summary: The draft is almost ready for publication as a proposed standard, but there are a few minor issues and editorial issues that need addressing first.

Major issues:

None

Minor issues:

-- 5.3:

Has the work group considered how the retransmit scheme and 30 second refresh default will scale to very large deployments? Seems like this could result in a lot of retransmissions.

-- 5.3, last paragraph: " This will cause the PE sending the all clear message to stop sending, and to continue normal operation."

Where is that specified? Can you offer a reference?

-- 5.3.1, 1st paragraph: "The receiving PE will then set its timeout timer according to the timer value that is in the packet received, regardless of what timer value it sent."

It's probably worth making a normative statement here, since it seems like this could easily result in an argument if the PEs disagree on the timer value.

-- 5.3.1, 2nd paragraph:

Please elaborate on "match exactly". What uniquely matches a message to an ack? How do you compare them?

"… the sender PE MUST use the new timer value received."

Doesn't this contradict the previous paragraph that lets the sender disagree? Is the subsequent treated different than the first attempt? (If so, is there a state machine that could be elaborated on?)

-- 5.3.2:

I don't understand the guidance here. Are you saying a PE should send status even when it can't?

-- 5.5, 1st paragraph: "… MUST be supported by both T-PEs to be enabled."

How does one T-PE know another supports this?

-- 5.5, last paragraph:

This could use some elaboration. What is the purpose of having to send both ways?

Nits/editorial comments:

-- general: 

IDNits returns some comments. I think something about the header format is confusing it.

-- abstract:

Please expand BFD on first mention

-- Section 2:

Please expand LDP and PE on first mention. (even though they are in the terminology section, since they are mentioned here before that section.)

-- section 2: "… without control plane."

Missing article ("a" or "the")

-- section 4:

Please expand PSN, MPLS-TP, and BFD on first mention.

-- section 5.1, 2nd to last paragraph: "...PW OAM Message code"

Missing "the"

-- section 5.1, last paragraph:

This seems redundant with the IANA considerations section.

-- 5.2, 1st paragraph: "PW Status messages are indicated…"

Indicated by what? (passive voice obscures responsible actor).

-- same paragraph: "PW Status TLV defined in [RFC4447].  The PW Status TLV format is as follows:"

I'm confused is defined in 4447 and just repeated here, or defined here? If the first, please be very clear about that, so there's no question about where the normative definition lives. For example: "PW Status TLV defined in [RFC4447], and is repeated here for the reader's convenience:"

-- 5.2, last paragraph: "PW OAM Status Messages MUST NOT be used as a connectivity verification method."

That sounds like it belongs in the "applicability" section.

-- 5.3, 2nd paragraph: "...will be transmitted immediately."

Transmitted by what? (passive voice obscures responsible actor).

-- 5.3.1, 1st paragraph: "The timer value set in the reply packet SHOULD then be used as the new transmit interval."

By what? (passive voice obscures responsible actor).

-- 5.3.1, last paragraph: "standard procedures"

Reference?

-- 5.5.1, last paragraph: "If Bit "B" is set , then the T-PE can receive S-PE bypass status messages in the G-ACH. If Bit "B" is not set the T-PE MUST NOT send S-PE bypass status messages in the G-ACH."

I think the sender and receiver are mixed up here. The text seems to say if the bit is set you may receive but if the bit is not set you must not send?

-- 8 : IANA Considerations

It would help to include the formal definition tables here, or reference them here. Also, can you include the URLs for each registry?

0x0022 appears to be already assigned to MPLS-TP CC message.

"Pseudowire Switching Point PE TLV Type""

I don't find that registry.  Did you mean sub-type?

0x16 appears to be already assigned to "Stack capability"

---

From: Luca Martini <[email-masked]>
Date: Fri, 07 Oct 2011 17:21:14 -0600

Ben,
Thank you for the review .
Some comments below.
Luca

> Has the work group considered how the retransmit scheme and 30 second refresh default will scale to very large deployments? Seems like this could result in a lot of retransmissions.
Yes. that is correct. This will most likely not scale for large deployments.
We have another document draft-ietf-pwe3-status-reduction-00.txt that
addresses this issue.
That extension is not necessary for most common small deployments in the
order of 100 PWs per access PE.

> Where is that specified? Can you offer a reference?
An "all clear message" is just a pw status message with status value =0
. I'll make this clear in the text.

> It's probably worth making a normative statement here, since it seems like this could easily result in an argument if the PEs disagree on the timer value.
An argument between who ?
I see a problem is the fact that we need to state a good practice
implementation policy.
Basically the PE should not insist on the value that was just refused.
I'll add some text to clarify this.
What that what you intended ?

> Doesn't this contradict the previous paragraph that lets the sender disagree? Is the subsequent treated different than the first attempt? (If so, is there a state machine that could be elaborated o…
no, this text is redundant, I'll remove it.

> I don't understand the guidance here. Are you saying a PE should send status even when it can't?
yes, this section is redundant, and adds no value. I'll remove it.
> How does one T-PE know another supports this?
Via a bit in the interface parameters as explained in sec 5.5.1.
> This could use some elaboration. What is the purpose of having to send both ways?
Keep the state of S-PEs in sync between LDP and the in-band bypass mode.
That is what is stated here.
S-PEs are PE that are in the middle of the path. They can also originate
PW status messages , but only using LDP.
There is fairly complicated state machine described in rfc6073 that
would break if the messages are not sent in LDP as well.

> IDNits returns some comments. I think something about the header format is confusing it.
Yes, I think that there is a bug in IDNits. I cannot figure out what is
causing this.
> Please expand BFD on first mention
fixed.
> Please expand LDP and PE on first mention. (even though they are in the terminology section, since they are mentioned here before that section.)
fixed.
> Missing article ("a" or "the")
fixed
> Please expand PSN, MPLS-TP, and BFD on first mention.
fixed.
> -- section 5.1, 2nd to last paragraph: "...PW OAM Message code"
fixed.
> This seems redundant with the IANA considerations section.
yes - removed.
> Indicated by what? (passive voice obscures responsible actor).
reworded this text.
> I'm confused is defined in 4447 and just repeated here, or defined here? If the first, please be very clear about that, so there's no question about where the normative definition lives. For exampl…
yes- fixed.
> That sounds like it belongs in the "applicability" section.
I think that it's missing an "also" here.

"PW OAM Status Messages MUST NOT be also used as a connectivity verification method."

> Transmitted by what? (passive voice obscures responsible actor).
fixed.
> By what? (passive voice obscures responsible actor).
fixed.
> -- 5.3.1, last paragraph: "standard procedures"
yes rfc4447.
> I think the sender and receiver are mixed up here. The text seems to say if the bit is set you may receive but if the bit is not set you must not send?
re-wrote the paragraph:
If the T-PE receives an LDP label mapping message containing a generic
protocol flags interface parameter TLV with the bit "B" set, then the
T-PE receiving the label mapping message MAY send S-PE bypass status
messages in the G-ACH. If Bit "B" of said TLV, is not set, or the TLV is
not present, then the T-PE receiving the label mapping message MUST NOT
send S-PE bypass status messages in the G-ACH.

> It would help to include the formal definition tables here, or reference them here. Also, can you include the URLs for each registry?
Tables have always been called out by name. What are "formal definition
tables" ?
I do not understand this comment. Iana section is quite clear.

> 0x0022 appears to be already assigned to MPLS-TP CC message.
Iana will have to sort that out then.
> I don't find that registry.  Did you mean sub-type?
It was missing the "sub-" in the TLV , fixed.
> 0x16 appears to be already assigned to "Stack capability"
I fixed the rest of the IANA
The PWE3 chairs and IANA will have to resolve the conflicts.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Oct 2011 13:08:15 -0500

Hi,

Thanks for the response. Some comments inline. I removed sections that seem to be resolved.

Thanks!

Ben.

> order of 100 PWs per access PE.

That's reasonable--a few words to that effect might be helpful.

[…]

> An argument between who ?

Between the sending and receiving PE.

> What that what you intended ?

Something along those lines, yes.

[…]

> would break if the messages are not sent in LDP as well.

That makes sense. A sentence to that effect might be helpful (but not absolutely required)

[…]

> I do not understand this comment. Iana section is quite clear.

I meant figures instead of tables. But on reflection, I should have said "sections".  For example, section 5.1 of this draft formally defines the PW OAM message. It would be helpful if the IANA consideration section for PW OAM referred back to that section. A reader who is tracing back to an RFC from an IANA definition will often start out looking in the IANA consideration section, and such a reference makes things a bit friendlier when the definition is in another section of the document.

[…]