[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] Last call comments on draft-ietf-pwe3-vccv-bfd-03
Stewart,
Thank you for the review and comments !
Please see inline: we are incorporating the comments that are acked
below into the working copy of the document, but there's also some
follow-up questions and confirmation requests below.
On 3/12/2009 12:18 PM, Stewart Bryant wrote:
> Some last call comments on draft-ietf-pwe3-vccv-bfd-03
>
>
> - Stewart
>
>
>
> Carlos
>
> Are you going to get this reviewed in L2TPext?
>
>
Yes, I sent it to the L2tpext list.
>
> Bidirectional Forwarding Detection (BFD) for
> the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
> draft-ietf-pwe3-vccv-bfd-03
>
> <snip>
>
> The CV Type is defined as a bitmask field used to indicate the
> specific CV Type or Types (i.e., none, one or more) of VCCV packets
> that may be sent on the VCCV control channel. The values shown below
> augment those already defined in [RFC5085]. They represent the
> SB> Perhaps "also shown in paranthasis(sp) in the
> SB> table below is the numerical...." might be clearer
Ack.
> numerical value corresponding to the actual bit being set in the CV
> Type bitfield.
>
> BFD CV Types:
>
> The defined values for the different BFD CV Types for MPLS and
> L2TPv3 PWs are:
>
> Bit (Value) Description
> ============ ====================================================
> Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
> Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
> AC/PW Fault Status Signaling
> Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
> Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
> AC/PW Fault Status Signaling
>
> It should be noted that four BFD CV Types have been defined by
> permutation of their encapsulation and functionality, see
> Section 3.3.
> SB> The above is perfectly correct, but I had to think about it
> SB> I wonder if there is a simpler way to say it.
Yes, could you provide specific textual suggestions? Alternatively,
would this work? [changed not made yet in the working copy yet]
It should be noted that four BFD CV Types have been defined by
combining two types of encapsulation with two types of
functionality, ...
>
> <snip>
>
>
> When the downstream PE (D-PE) does not receive BFD control messages
> from its upstream peer PE (U-PE) during a certain number of
> transmission intervalS (a number provisioned by the operator as
> Detect Mult),
> SB> where is Detect Mult defined - Do you mean Detect Multiplier?
It's defined in S4.1 of draft-ietf-bfd-base, as "Detect Mult", expanded
as "detection time multiplier" in its description. Throughout the BFD
base spec, it's used as "The Detect Mult value ...", and that's why we
used it as-is.
Changed to "a number provisioned by the operator as "Detect Mult" or
detection time multiplier [bfd-base])". Is this better?
>
>
> D-PE declares that the PW in its receive direction is
> down. In other words, D-PE enters the "forward defect" state for
> this PW. After this calculated Detection Time, D-PE declares the
> SB> Perhaps clarify that Detection time is transmission interval times
> SB> Detection Multiplier plus a bit.
I think it's slightly more complex than that, as the Detect Mult is the
one received from the remote endpoint and transmission interval is
negotiated, plus jitter, and is explained at
http://tools.ietf.org/html/draft-ietf-bfd-base-09#section-6.8.4
I think that trying to explain it here would confuse, so instead we added:
After this calculated Detection Time (see S6.8.4 of [bfd-base]),
D-PE
We can also add "(derived from the negotiated transit interface and the
Detect Mult, see ...)" if you think that's more clear, please let us
know. [changed not made yet in the working copy yet]
>
> session Down, and signals this to the remote end via the State (Sta)
> with Diagnostic code 1 (Control Detection Time Expired). In turn,
> U-PE declares the PW is down in its transmit direction setting the
> State to Down, and it using Diagnostic code 3 (Neighbor signaled
> SB> and "if" using
Actually, the "it" is extraneous and should be (is now) removed.
> session down) in its control messages to D-PE. U-PE enters the
> "reverse defect" state for this PW. If needed, how it further
> SB> something wrong with the English "If needed, how.....
Ack. Removed the "If needed, ", resulting in "How it further processes
this error condition, and potentially conveys ..." (added "potentially").
> processes this error condition, and conveys this status to the
> attachment circuits is out of the scope of this specification, and is
> instead defined in [I-D.ietf-pwe3-oam-msg-map].
>
> SB> Next sentence comes out of the blue - does it belong here?
Ack. It's a separate (single-sentence) paragraph, moved it down to after
the next title.
> The VCCV message comprises a BFD Control packet [I-D.ietf-bfd-base]
> encapsulated as specified by the CV Type (see Section 3.2).
>
> 3.2. BFD Encapsulation
>
> There are two ways in which a BFD connectivity verification packet
> may be encapsulated over the VCCV control channel. This document
> defines four BFD CV Types (see Section 3), which can be grouped into
> two pairs of BFD CV Types from an encapsulation point of view.
> SB> In next do you mean "See table...."
Ack.
> Table 1 in Section 3.3 summarizes the BFD CV Types.
>
> <snip>
>
> The IP version (IPv4 or IPv6) matches the IP version used for
> SB> do you mean MUST match the IP version?
Ack.
> signaling for dynamically established pseudowires, or is
> SB> then this would be "or MUST be configued"
Ack.
>
> <snip>
>
> In this encapsulation, a "raw" BFD Control packet follows directly
> the PW-ACH, and the PW-ACH Channel Type identifies "raw" BFD.
> SB> The above does not quite read properly
Changed to:
In this encapsulation, a "raw" BFD Control packet follows
directly the PW-ACH. The PW-ACH Channel Type indicates that the
Associated Channel carries "raw" BFD.
Is this more clear?
Note that the sentence that follows reads (you did not comment on this one):
The PW Associated Channel (PWAC) is defined in Section 5
of <xref target="RFC4385"/>, and its Channel Type field
is used as a payload type identifier to discriminate the VCCV
payload types.
Should we remove it or reward the second part, based on an upcoming
comment regarding using "payload type identifier"?
>
> <snip>
> The usage of the PW-ACH on different VCCV CC Types is specified
> for CC Type 1, Type 2 and Type 3 respectively in Sections 5.1.1,
> 5.1.2 and 5.1.3 of [RFC5085], in all cases depending on the use of
> SB> Perhaps ", and in all cases requires the use of"
Ack. (thanks, that change clarifies a lot)
> a CW. When VCCV carries raw BFD, the PW-ACH (Pseudowire CW's or
> L2SS') Channel Type MUST be set to 0x0007 to indicate "BFD
> Control, PW-ACH-encapsulated" (i.e., BFD Without IP/UDP Headers,
> see Section 5.2), to allow the identification of the encased BFD
> payload when demultiplexing the VCCV control channel. In this
> case, the BFD CV Type employed in signaling (if used) is either
> 0x10 or 0x20.
> SB> The above is correct. but very cryptic.
I broke the long sentence into two at "...see Section 5.2). This is to
allow...". Also changed the "In this case, " to "In this encapsulation,"
to be more precise, and moved this last sentence to a separate para
since it's not directly related. Do you have other textual suggestions?
Is that change sufficient to be more clear?
>
>
> 3.3. CV Types for BFD
>
> Four CV Types are defined for BFD. Table 1 summarizes the BFD CV
> Types, grouping them by encapsulation (i.e., with and without IP/UDP
> headers) and by functionality (i.e., fault detection only, or fault
> detection and status signaling).
>
> +----------------------------+--------------+-----------------------+
> | | Fault | Fault Detection and |
> | | Detection | Status Signaling |
> | | Only | |
> +----------------------------+--------------+-----------------------+
> | BFD, IP/UDP encapsulation | 0x04 | 0x08 |
> | (with IP/UDP Headers) | | |
> | | | |
> | BFD, PW-ACH encapsulation | 0x10 | 0x20 |
> | (without IP/UDP Headers) | | |
> +----------------------------+--------------+-----------------------+
>
> Table 1: Bitmask Values for BFD CV Types
>
> SB> The earlier sections would be easier to read if this
> SB> table was earlier in the document.
The table is here both as a summary and also to be easily referenced by
the subsequent text that directly cites it. This section describes the
actual CV Types, and that's why it includes the table here. Note that,
although the table is in Section 3.3, it is referenced much earlier with:
"See Table 1 in Section 3.3 that summarizes the BFD CV Types."
Do you think that we should reference the table in other places? Or if
we move the table to earlier in the document, where specifically? At the
end of Section 3 and right before the title for Section 3.1? [no change
yet here]
>
> The following list enumerates rules, restrictions and clarifications
> on the usage of BFD CV Types:
>
> 1. BFD CV Types used for fault detection and status signaling (i.e.,
> CV Types 0x08 and 0x20) SHOULD NOT be used when a control
> protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available
> that can signal the AC/PW status to the remote endpoint of the
> PW. More details can be found in [I-D.ietf-pwe3-oam-msg-map].
>
> 2. BFD CV Types used for fault detection only (i.e., CV Types 0x04
> and 0x10) can be used whether a protocol that can signal AC/PW
> status is available or not. This includes both statically
> provisioned and dynamically signaled pseudowires.
>
> SB> Strange sublist symbol on next
Do you mean the "A.", "B." (<list style="letters">)? It's to
differentiate the hierarchical level of the list (and say 2.A). Would
you prefer numbers, symbols (bullets) or other? [no change made here yet]
> A. In this case, BFD is used exclusively to detect faults on the
> <snip>
>
> 3. Pseudowires that do not use a CW or L2SS using the PW Associated
> Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e.,
> PW-ACH encapsulation of BFD, without IP/UDP headers).
>
> A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and
> L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]),
> and MPLS CC Types 2 and 3 when using a Control Word (as
> specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This
> restriction stems from the fact that the PW-ACH contains a
> Protocol Identification (PID) field, the Channel Type.
> SB> Please do not call the channel type a PID - it's going
> SB> to get confusing.
>
OK, changed to:
This restriction stems from the fact that the encapsulation
uses the Channel Type in the PW-ACH.
Does that work?
>
> B. PWs that do not use a PW-ACH can use the VCCV BFD
> SB> MUST only? or can only? The the rest of the para is really
> SB> quite difficult to read
Not "MUST only". How's this?
B. PWs that do not use a PW-ACH can use the VCCV BFD encapsulation
with IP/UDP headers, as the only VCCV BFD encapsulation
supported. Using the IP/UDP encapsulated BFD CV Types allows for
the concurrent use of other VCCV CV Types that uses an
encapsulation with IP headers (e.g., ICMP Ping or LSP Ping
defined in [RFC5085]).
The rest of the para is removed. We made this change, let us know if you
have additional suggestions.
> encapsulation with IP/UDP headers, including its concurrent
> use along with another CV Type that uses an encapsulation
> with IP headers (e.g., ICMP Ping or LSP Ping). For example,
> as specified in Section 7 of [RFC4385], a Pseudowire
> operating without CW MUST NOT use the PW-ACH.
>
> 4. Only a single BFD CV Type can be selected and used. All BFD CV
> Types are mutually exclusive with the rest, after selecting a BFD
> SB? perhaps a "." after rest
Ack.
> CV Type, a node MUST NOT use any of the other three BFD CV Types.
>
>
> 4. Capability Selection
>
> The precedence rules for selection of various CC and CV Types is
> clearly outlined in Section 7 of [RFC5085]. This section augments
> these rules when the BFD CV Types defined herein are supported. The
> selection of a specific BFD CV Type to use out of the four available
> CV Types defined is tied to multiple factors, as hinted in
> SB> Hints are not good in a std track document :)
s/as hinted/as described/
> Section 3.3.
>
> <snip>
>
> There may be more than one CV Type available for selection after
> considering the intersection of advertised and received BFD CV Types,
> and applying the rules in Section 3.3. For these cases were multiple
> BFD CV Types are available for selection, the following precedence
> order applies when choosing the single BFD CV Type to use. The
> lowest numbered item (where both ends have set the indicated flag and
> such flag is allowed by the rules above) is used:
>
> SB> By lowest number do you mean the item nearest the top of the
> SB> list below? People will get confused between the list
> SB> point number and the cv type unless this it is very carefully
> SB> stated how to chose from the list below.
It says the "lowest numbered item" (not the "lowest number"). And items
in the list are numbered from 1 to 4. The lowest numbered refers to "1",
which is at the top. This text was worded like this to avoid any
ambiguity or confusion. It doesn't say lowest CV type either. However,
if you think there is still room for confusion, we can replace:
The lowest numbered item (where both ends have set the indicated
flag and such flag is allowed by the rules above) is used:
With: [changed not made in the working copy]
Only CV Types where both ends have set the indicated flag and
such flag is allowed by the rules above are considered. The
lowest numbered item from those considered (i.e., choosing from
top to bottom) is used:
Please let us know which one you think is more clear, or provide another
suggestion.
>
> 1. 0x20 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW
> Fault Detection and AC/PW Fault Status Signaling
>
> 2. 0x10 - BFD PW-ACH-encapsulated (without IP/UDP headers), for PW
> Fault Detection only
>
> 3. 0x08 - BFD IP/UDP-encapsulated, for PW Fault Detection and AC/PW
> Fault Status Signaling
>
> 4. 0x04 - BFD IP/UDP-encapsulated, for PW Fault Detection only
>
> This precedence order prioritizes superset of functionality and
> simplicity of encapsulation.
>
>
> 5. IANA Considerations
>
> 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV
>
> The VCCV Interface Parameters Sub-TLV codepoint is defined in
> [RFC4446], and the VCCV CV Types registry is defined in [RFC5085].
> This section lists the new BFD CV Types.
>
> IANA is requested to augment the "VCCV Connectivity Verification
> Types" registry in the Pseudo Wires Name Spaces, reachable from
> [IANA.pwe3-parameters]. These are bitfield values. CV Type values
> 0x04 0x08, 0x10 and 0x20 are specified in Section 3.
> SB> Section 3 of this document.
>
Ack.
>
> MPLS Connectivity Verification (CV) Types:
>
> Bit (Value) Description
> ============ ====================================================
> Bit 2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
> Bit 3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
> AC/PW Fault Status Signaling
> Bit 4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
> Bit 5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
> AC/PW Fault Status Signaling
>
> 5.2. PW Associated Channel Type
>
> SB> The next will confuse IANA.
> SB> All they want is an instruction and that instruction
> SB> is to allocate 0x0007
>
Agreed.
See below.
>
> The PW Associated Channel Types used by VCCV rely on previously
> allocated numbers from the Pseudowire Associated Channel Types
> Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from
> [IANA.pwe3-parameters].
Removed the text between the markers below.
--->8---
> In particular, 0x21 (Internet Protocol
> version 4) is used whenever an IPv4 payload follows the Pseudowire
> Associated Channel Header, or 0x57 is used when an IPv6 payload
> follows the Pseudowire Associated Channel Header.
>
> In cases where a raw BFD Control packet follows the Pseudowire
> Associated Channel as specified in Section 3.2 (i.e., when using the
> PW-ACH-encapsulated BFD without IP/UDP headers), a new "Pseudowire
> Associated Channel Types" Registry [RFC4385] entry of 0x07 is used.
--->8---
The rest remains as-is.
> IANA is requested to reserve a new Pseudowire Associated Channel Type
> value as follows:
>
>
> Value (in hex) Protocol Name Reference
> -------------- --------------------------------- ---------
>
> 0x0007 BFD Control, PW-ACH encapsulation [This document]
> (without IP/UDP Headers)
>
> <snip>
>
>
> 6. Congestion Considerations
>
> The congestion considerations that apply to [RFC5085] apply to this
> mode of operation as well.
>
> SB>... there are no additional congestion considerations
Ack.
Thanks again,
-- Carlos.
>
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>