Subject: [PWE3] [Fwd: draft-ietf-pwe3-vccv-11.txt]

From: Stewart Bryant <[email-masked]>
Date: Fri, 15 Dec 2006 12:22:12 +0000

-------- Original Message --------
Subject: draft-ietf-pwe3-vccv-11.txt
Date: Fri, 15 Dec 2006 12:21:11 +0000
From: Stewart Bryant <[email-masked]>
To: [email-masked],  [email-masked],  [email-masked]
CC: Danny McPherson <[email-masked]>

I just re-read VCCV line by line and have the following comments.

A few of these are typos, but most of them need design
consideration.

I then went through the WG archive since -11 was posted and
have included the references below so that we all have a complete
list of things that need to be addressed one way or the other in
-12

- Stewart

===================================

Please do not allow a line break in the middle of a figure (fig 1)
I know that the editor will fix it, but it makes it much harder
for reviewers.

==============

[OAM-MAP]     T. Nadeau, et. al, "Pseudo Wire (PW) OAM Message Map-
               ping", draft-ietf-pwe3-oam-msg-map-03.txt,
               September 2005

This draft seems to have stalled. When will it be ready for LC?

==============

Two things here firstly the following would be a lot easier to
read if you wrote in terms of the name of the identifier rather
than the value in hex.

Secondly I think that this the area where Peter B objected to
the side reference [OAM-MAP]. I tend to agree with him there.
VCCV should specify the message channel, and any message
applications RFC should specify the how choices are made.

    "It should be noted that two different pairs of CV Types have been
    defined when BFD is used. If a capability advertisement is received
    with both 0x04 and 0x08 types indicated, the PE MUST ignore the 0x08
    bit as if it were set to 0. If a capability advertisement is
    received with both 0x10 and 0x20 types indicated, the PE MUST ignore
    the 0x20 bit as if it were set to 0. In the case of type 0x08 or
    0x20, the AC and PW status SHOULD be conveyed via BFD status codes
    as specified in [OAM-MAP]. "

    "However, this type SHOULD NOT be used
    when a control protocol such as LDP or L2TPV3 is available that can
    signal the AC/PW status to the remote endpoint of the PW
    In the case of type 0x04 or 0x10, BFD is used exclusively to detect
    faults on the PW and the status of those faults should be conveyed
    using some means other than BFD, such as using LDP status messages
    when using MPLS as a transport, or the Circuit Status
    AVP in an L2TPv3 SLI message for L2TPv3 (see [RFC3931]).
    If none of the types above are supported, the entire CV Type
    Indicator field SHOULD be transmitted as 0x00 to indicate this
    to the peer."

    "If no capability is signaled, then the peer MUST assume that
    the peer has no VCCV capability and follow the procedures
    specified in this document for this case."

In fact I am not sure how much of this should be in VCCV and how much
in a usage draft.

=====================================================

    "Depending on the emulated services, PE2 may send a
    forward direction indication (FDI) on its attachment
    circuits and PE1 may send an RDI indication on its attachment
    circuits [OAM-MAP].""

Again does OAM-MAP belong in this draft here?

========================================================

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1| 0 0 0 0 0 0 0 0 0 0 0 |            0x21               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 4: PW Associated Channel Header for VCCV

Section needs an IPv6 reference or it will get jumped on by the IPv6 police.

====================================================

5.3. TTL Expiry VCCV (Type 3)

    "To use this type, the control word MUST be used."

You should explain why

====================================================

    "Changing control
    channel types after one has been established to be in use
    could potentially cause problems at the receiving end, and
    could also lead to interoperability issues, thus it is strongly
    discouraged. "

The formal IETF term is NOT RECOMMENDED

======================================================

    "The exception to the rules given in the last two paragraphs above
    is when one side of the PW indicates no support for VCCV while the
    other indicates support for at least one control channel type. In
    this case, it is possible for one side of the PW to send VCCV
    messages (either requests or replies to requests)."

I can see how one side might send a request, but the other side
not support VCCV and so ignores them, but I don't see replys get
sent when only one party supports VCCV.

=====================================================

    "The Control Channel (CC Types) type field defines a bitmask used to
    indicate the type of control channel(s) (i.e.: none, one or more)
    that a router is capable of receiving control channel traffic on.
    If more than one control channel is specified, the router agrees
    to accept control traffic over either control channel; however,
    see the rules specified in section 6 for more details.
    If none of the types are supported, a CC Type Indicator of 0x00 "

Shouldn't this have a name?

6. VCCV Control Channel for L2TPv3/IP PSN

    "Depending on the CV Type in use, the Channel Type can indicate IPv4,
    IPv6 (see [RFC4385]) or BFD (see Section 8.1.3) as VCCV payload
    directly following the L2SS. For CV Types of 0x01, 0x04 and 0x08,
    the Channel Type can indicate IPv4 or IPv6; for CV Types of 0x10
    and 0x20, the Channel Type indicates BFD Without IP/UDP Header."

Again names would make this a lot easier to read

================================================================

      "A CC Type of 0x01 may only be requested when there is an
       L2-Specific Sublayer that defines the V-bit present. If a CC Type
       of 0x01 is requested without requesting an L2-Specific Sublayer
       AVP with an L2SS type that defines the V-bit, the session MUST be
       disconnected with a CDN message."

       "If no CC Type is supported, a CC Type Indicator of 0x00 SHOULD be
       sent."

Again don't they have names?

====================================================================

7. Capability Advertisement Preference Order

    "CC Types:

        - PWE3 control word with 0001b as first nibble
        - MPLS Router Alert Label
        - MPLS PW Demultiplexor Label TTL = 1"

I am sure that each of these has a name (comment applies
multiple times

===================================

8. IANA Considerations

8.1. VCCV Parameter ID

    "The VCCC parameter ID codepoint is defined in [RFC4446]. IANA
    is requested to maintain a registry for the CC Types and CV
    Types, and bitmasks in the VCCV Parameter ID. "

We need to say where we want these registries to live. In a VCCV
registry, in the PWE3 registry similar comment below - do we want
a VCCV registry or a sub-component of the PWE3 registry.

    "The allocations
    must be done using the "First Come First Served" policy
    defined in RFC2434. IANA is requested to maintain the
    following registries."

I think that we may want this to be expert review.

8.1.1. Control Channel Types (CC Types)

    "IANA is requested to set up a registry of "VCCV Control Channel
    Types". These are 8-bit values. CV Type values 0x01, 0x02, and 0x04
    are specified in this document, PW Type values 0x08, 0x16
    and 0x24 are to be assigned by IANA using the "Expert Review"
    policy defined in [RFC2434]. "

I don't think that the above is a sufficiently clear IANA action
in terms of registry, value, allocation policy. Where does 24 come from?

====================================

8.1.2. Connectivity Verification Types (CV Types)

    ""IANA needs to set up a registry of "VCCV Control Channel Types".
    These are 8-bit values. CV Type values 0x00, 0x01, 0x02, and 0x04
    are specified in this document, CV Type values 0x16
    and 0x24 are to be assigned by IANA using the "Expert Review"
    policy defined in [RFC2434]. "

Where do 16 and 24 come from?

=============================================

    "In cases where raw BFD follows the pseudowire control word
    (i.e.: the IP/UDP encapsulation as specified in [BFD]
    will not be present), a new Pseudowire Associated Channel
    Types Registry [RFC4385] entry of 0x07 is used. IANA is
    requested to reserve a new Channel Types value as follows:

   Value (in hex)  Protocol Name                    Reference
   --------------  -------------------------------  ---------

   0007            BFD Without IP/UDP Header        [This document]"

Why 7?

==================================================
9. Security Considerations

    "Routers that implement the mechanism described herein are subject to
    to additional denial-of-service attacks as follows:

      An intruder could intercept or inject VCCV packets effectively
      providing false positives or false negatives."

This is not a control plane attack (as stated below) it is a data
plane attack. You need to say that it is as secure as the datachannel
that it is acting as OAM for, calling up the data plane specs.

      "An intruder could deliberately flood a peer router with VCCV
      messages to either obtain services without authorization or to
      deny services to others."

This is dataplane as well

Also you should call up the security analysis in the arch RFC

    "All of attacks above which concern the L2TPv3 or LDP control planes
    may be countered by use of a control message authentication scheme
    between LDP or L2TPv3 peers, such as the MD5-based scheme outlined in
    [RFC3036] or [RFC3931]. Implementation of IP address filters may
    also aid in deterring these types of attacks."

    "VCCV message throttling mechanisms should be employed, especially in
    distributed implementations which have a centralized control plane
    processor with various line cards attached by some data path. In
    these architectures VCCV messages may be processed on the central
    processor after being forwarded there by the receiving line card. In
    this case, the path between the line card and the control processor
    may become saturated if appropriate VCCV traffic throttling is not
    employed, which could lead to a denial of service.  Such filtering is
    also useful for preventing the processing of unwanted VCCV messages,
    such as those which are sent on unwanted (and perhaps unadvertised)
    control channel types or VCCV types."

Actually you can apply throttling in all case, not just the distributed
case.

============================================

    "VCCV spoofing requires MPLS PW label spoofing and spoofing the PSN
    tunnel header. As far as the PW label is concerned the same consider-
    ations as specified in [RFC3031] apply. If the PSN is a MPLS tunnel,
    PSN tunnel label spoofing is also required."

Also there is L2TPv3 security to make notes about.

=================================

    [RFC4448]  Martini, L., Rosen, E., El-Aawar, N., Heron, G.,
               "Encapsulation Methods for Transport of Ethernet
               over MPLS Networks", RFC4448, April 2006.

Why is this normative?

===================================

There are some comments from benjamin niven-jenkins 10/Oct that need
to be addressed

http://www1.ietf.org/mail-archive/web/pwe3/current/msg08573.html

which you agreed to fix in -12

====================================

There is a long thread about what should be in VCCV and what should
be in message mapping.

I support the argument that this draft should describe the channel
and msg-map should describe the oam-protocol actions.

I do not subscribe to the argument that this separation will delay
the VCCV draft. We will not get VCCV to the RFC editor until BFD
gets there, and in any case the chairs can get the OAM draft to
Mark within three weeks of authors producing a clean draft that the
WG agrees is complete.

======================================

Mustapha's comments need addressing

http://www1.ietf.org/mail-archive/web/pwe3/current/msg08604.html

======================================

We need a statement saying that multi-segment considerations are out
of scope for this version of VCCV.

We also need to get a MS VCCV draft that is viable for adoption
as a WG draft.

========================================

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3