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

["Lizhong Jin" <[e-mail]>]

Hi Adrian,
Sorry for the late reply. Please see my reply inline below.
Please co-authors help to correct if I am wrong.

Regards
Lizhong


> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Sunday, March 23, 2014 1:02 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy
> 
> 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
[Lizhong] accepted

> 
> ---
> 
> Please check the text for acronyms that have not been expanded.
[Lizhong] accepted

> 
> ---
> 
> Several places in the text (but not the boilerplate) please
> s/draft/document/
[Lizhong] accepted

> 
> ---
> 
> 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).
[Lizhong] thank you for pointing out this. We will change to Standards Track.

> 
> ---
> 
> 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.
[Lizhong] accepted, and I try to rephrase as below:
In many existing Virtual Private LAN Service (VPLS) deployments based on [RFC4762], inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain.  This document is to provide a service protection mechanism for inter-domain VPLS based on [RFC4762]. The protection mechanism will provide edge node redundancy and link redundancy in both domains.  The domain in this document refers to autonomous system (AS), or other administrative domains.
The solution relies on the use of ICCP [ietf-pwe3-iccp] to coordinate between redundant edge nodes, and use of Pseudowire (PW) Preferential Forwarding Status Bit [RFC 6870] to negotiate the PW status. There is no change to any protocol message formats and no new protocol options introduced. This solution is a description of reusing existing protocol building blocks 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
[Lizhong] accepted
> 
> ---
> 
> The figures in Section 4 use "RG" but this term is not introduced until
> Section 5.
[Lizhong] accepted
> 
> ---
> 
> Figure 2 might usefully be redrawn to show how PW3 and PW4 attach to
> the
> PEs.
[Lizhong] do you mean the PW is broken to the PE in the figure? Will fix that. Thanks.
> 
> ---
> 
> 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.
[Lizhong] will add: One method to ensure mode consistency is by manual operation. Other methods are also possible and is out of the scope of this document.

> 
> ---
> 
> 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?
[Lizhong] we check this with the operator. When they do inter-AS connection, there will be some kind of contract to ensure the interconnection. The PW priority could be one part of the contract/negotiation. This is more of the operation method. Now I think we should not use RFC2119 word "MUST" here. "should" would be a better word here.

> 
> ---
> 
> 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.
[Lizhong] it would be clear to say: In this use case, there are two options to provide protection: 1:1 and 3:1 protection.

> 
> ---
> 
> 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.
[Lizhong] Accepted. Thanks.

> 
> ---
> 
> 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?
[Lizhong] yes, more consideration is required. I try to change:
Besides of the security properties of [I-D.ietf-pwe3-iccp] and [RFC4762], this draft will have additional security consideration. 
When deploying the inter-domain redundancy mechanism described in this document, some manual operation/negotiation is required to be done correctly and securely. E.g., each node within one RG should be configured with same redundancy mode; the two operators should negotiate to configure same PW priority at two nodes. If the configuration consistency is broken, the inter-domain redundancy mechanism may not work properly.
Since ICCP is now deployed between two PEs or ASBRs, the LDP session could be secured with TCP Authentication Option [RFC5925]. This provides integrity and authentication for the ICCP messages. The LDP MD5 authentication key option, as described in section 2.9 of [RFC5036] MAY also be used.