Pseudowire Preferential Forwarding Status Bit
draft-ietf-pwe3-redundancy-bit-09

Thank you with your patient work to address my Discuss.

---

I continue to be disappointed by the piecemeal invention of bolt-on
signaling features for PW management. It really seems that the working
group needs to work on a functional architecture for pseudowires to
work out all of the bits and pieces that are needed for redundancy,
bandwidth, multi-segment routing, etc., etc. I wish this would happen
before we incrementally munge the protocol too much, but I
understand that this is not directly actionable for the authors of this
document.

- <MY INITIAL COMMENT>
Section 5.1

   1. For FEC128 PW, the PW with the lowest pw-id value is selected.

   2. For FEC129 PW, each PW in a redundant set is uniquely identified

No idea what FEC128 and FEC129 were.
I had to search and found http://tools.ietf.org/html/rfc4379#section-3.2.8,
where by the way, they're spelled "FEC 128" and "FEC 129". So please add a
reference.
</MY INITIAL COMMENT>

You solve the issue in section 5.1 by removing FEC128 and FEC129, but FEC 128 and FEC 129 still appear in different places of the document

Please check the idnits:

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 19 instances of too long lines in the document, the longest
     one being 4 characters in excess of 72.

  == The 'Updates: ' line in the draft header should list only the _numbers_
     of the RFCs which will be updated by this document (if approved); it
     should not include the word 'RFC' in the list.

  -- The draft header indicates that this document updates RFC5542, but the
     abstract doesn't seem to directly say this.  It does mention RFC5542
     though, so this could be OK.

 Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.) -- however,
     there's a paragraph with a matching beginning. Boilerplate error?

     IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.
      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."

     ... text found in draft:
     "Code Components extracted from this document must include Simplified BSD
......^
      License text as described in Section 4.e of the Trust Legal
      Provisions and are provided without warranty as described in the
      Simplified BSD License."


  -- The document date (May 1, 2012) is 20 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-08) exists of
     draft-ietf-pwe3-redundancy-07

Section 2:

MANDATORY
OPTIONAL
OPTIONALLY

Neither MANDATORY nor OPTIONALLY are 2119 terms. I suspect that the capitalized words in this section are a new magical usage of which I am unaware. Perhaps you might like to define terms?

5.1

   The PW endpoints MAY also implement the following optional active PW 
   selection mechanism.  

   1. If the PW endpoint is configured with the precedence parameter on 
      each PW in the redundant set, it MUST select the PW with the 
      lowest configured precedence value.  

So you MAY do something that you MUST do? I am confused.

   a management indication SHOULD be generated

I may not understand what is meant by a "management indication" here, but it sounds like an implementation choice, not something that is required for interoperation. Did I get that wrong?

  Please consider the issues raised in the Gen-ART Review by
  Miguel Garcia on 23-May-2012.  I tend to agree with his points on
  RFC 2119 language in Sections 5 and 15.  Please find the review at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07447.html.

Note these comments are the same for both draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit.

Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit.  Can't you just point from on to the other?

This uses the TCP MD5 "signature" option [RFC5036].  KARP's hopefully going to get this fixed sooner rather than later.  So there's nothing for the authors to do about this otherwise recurring gripe.

I'd like to suggest some tweaks to the security considerations section, assuming of course that I've not totally missed the mark:

1st - I think the "LDP extensions" are referred to as options in both RFC 4447 and 5036?
2nd - I think there's only one of them?
3rd - I think you mean control plane not control protocol?

How about the following tweaks to the security considerations section:

   This document uses the TCP MD5 Signature option, as specified
   in [2],  to protect pseudowires.  This document has the same
   security considerations as in the PWE3 control-plane [2].

If you want to future proof the text more maybe:

   LDP extensions/options that protect pseudowires must be
   implemented because the security considerations for the
   bits defined in this document have the same security
   considerations as the PWE3 control-plane [2].

The security considerations say that this is the same as for
4447, which is arguably correct, but 4447 really defers to
3036, which a) doesn't consider switching over to a "less good"
PW as a potential DoS (is it?) and b) only has TCP-MD5 based
security which even in 2001 attracted an IESG note, repeated in
3036 from rfc 2385 (from 1998!).  Any chance of getting some
21st century security stuff done in PW-land? (Sorry, but that's
hard to resist:-) This is probably not the place to fix that,
but it'd be good to know if there's a plan. Is there?

Nits:

- PE-rs is used without expansion (on p2)

- FEC128 and FEC129 are used without definition on p11
(As as AGI::SAII:TAII)

- What is the "system IP address"? (on p11) Could be fairly
obvious, but then again if a node has many addresses, 
maybe not.