AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy

["Adrian Farrel" <[e-mail]>]

As is my usual practice, I am doing a review of your document as AD to
support the publication request from the WG chairs.  Thanks to Lizhong
for answering my early questions. I understand the intention of the
document and have a number of updates that I think you need to make to
improve the quality and direction of the work.

FWIW I disagree with Lizhong that this is not a protocol specification.
This document specifically gives instructions of process that an 
implementation has to follow (look at Section 5.3) and those procedures
will change what messages the implementation sends. That means that the
text changes what happens on the wire. So, although there are no bits 
and bytes changes, this is a protocol specification.

I have put the document into "Revised I-D Needed" state. When I see a 
new revision, I'll move it forward. In the meantime, you should feel
free to debate any of these points with me if you disagree.

Thanks for the work,
Adrian

==========                               

It would be really nice to fix idnits

---

Please check the text for acronyms that have not been expanded.

---

Several places in the text (but not the boilerplate) please
s/draft/document/

---

I can't see how this is a BCP. I realise that RFC 2026 section 5 is not
really clearly written, but this is a technical spec that describes how
to build a particular function in the network. Standards Track would be
just fine (even though there are no bits and bytes defined) because you
are defining procedures (using 2119 language) that an implementation has
to perform to make this function work (i.e., interoperate).

---

Section 1

Please give a little more information about what the "solution" is. You
don't need to go into full detail, but you do need to give some 
overview. Things I'd like to see covered...
- motivation is to provide service protection mechanisms in the event of
  edge node failure
- basic mechanism is to provide edge node redundancy
- solution is dependent on the use of ICCP (with reference) to 
  coordinate between redundant edge nodes
- no changes to any protocol message formats are needed for this 
  solution and no new protocol options are defined
- this solution is a description of how existing protocol building 
  blocks may be deployed to achieve the desired function, but also
  defines implementation behavior necessary for the function to work.

---

Section 4

3/PE4/PE5/PE6 should read PE3/PE4/PE5/PE6

---

The figures in Section 4 use "RG" but this term is not introduced until
Section 5.

---

Figure 2 might usefully be redrawn to show how PW3 and PW4 attach to the
PEs.

---

Section 5 says

   For the inter-domain four-PW scenario,
   it is required for PEs to ensure that the same mode is supported on
   the two ICCP peers in the same redundancy group (RG).

But you don't say how this is achieved.

---

Section 5.2

   Before
   deploying this inter-domain VPLS, the operators MUST negotiate to
   configure same PW high/low priority at two PW end-points.

How do they do this?

---

Section 5.3

   In this use case, there are generally three options

So, sometimes two options and sometimes four options? :-)
Delete "generally", but also make clear what the three options are.

---

Section 5.3

   support of 'request switchover' bit is required

It would have helped me if this had used the same name as in RFC 6870
(Request Switchover status bit) and had included a reference to RFC
6870.

---

Section 6

There seem to be some independent actions needed (operator negotiation,
setting of mode). Are these security vulnerabilities?

ICCP is being run on the Internet and not in a chassis. Does that make a
difference to the security model?