Subject: [PWE3] draft-ietf-pwe3-vccv-bfd-00 - Last Call

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Jan 2008 12:45:39 +0000

This is the start of last call on draft-ietf-pwe3-vccv-bfd-00

The draft can be found at:

http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00

Last call will end Tues 22 Jan 2008

Please review this draft.

Thanks

Stewart

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

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 18 Jan 2008 23:42:15 -0500

Please find some comments, suggestions and open questions on this draft.

1. Same misuse of PSN (instead of PW) as in the vccv-base document:

    The new BFD CV Types are PSN-agnostic, and hence applicable for both
    MPLS and L2TPv3 PSNs.
    Should be:
    The new BFD CV Types are PW-Demultiplexer-agnostic, and hence
    applicable for both MPLS and L2TPv3 PWs.

---

2. I think that the capability selection rules and restrictions (Section
    3.3 and Section 4) are a bit over-specified and overly restrictive.
    E.g., Section 3.3 says "SHOULD NOT use BFD-for-fault-detection-only
    if there is no control protocol to signal status", but that assumes
    that performing AC status signaling is always desired (and that may
    not be the case). Or says "SHOULD not use BFD-fault-and-status if
    there is a control protocol that can signal status" but then points
    to [pwe3-oam-msg-map] that covers that case already in its Sections
    5.3 and 5.3.2:
      "If
      a combination of VCCV+BFD [VCCV] status and LDP status are
      used, LDP status MUST take precidence over VCCV-BFD status
      as as outlined below in Section 5.3.4."

    It seems to me that a simpler capability selection precedence would
    be better and would provide a more predictable selection. Given that
    fault+status is a functional superset of fault-only, and with IP/UDP
    is (in a way) a superset of without IP/UDP, how about:
      1. Take the BFD CVs matching from the advertised and received sets.
      2. From those, select with this precedence: 0x08, 0x04, 0x20, 0x10.
    And then make an explicit mention of pwe3-oam-msg-map

---

3. Although it is mentioned in RFC 5085, I think that it's worth adding
    in this draft an explicit mention of statically configured
    pseudowires, and how the manually configured CV Type would need to
    match in both endpoints in those cases.

---

4. Should BFD Echo Mode be explicitly excluded? Should the PW Associated
    Channel Type (Section 5.2) be called "BFD Control Packets Without
    IP/UDP Headers" instead of "BFD Without IP/UDP Headers"? Or should
    echo be allowed and a channel type assigned for it? Any reason why it
    shouldn't be allowed (given that BFD w/o IP/UDP requires a CW/ACH and
    has a PID)?

---

5. To provide some more ground/basis to the BFD w/o IP/UDP
    encapsulation, should we add a pointer to draft-ietf-bfd-generic when
    introducing these BFD modes (w/o IP/UDP), specifically to Section 8
    of ietf-bfd-generic?

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems