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

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

Hi Lizhong,

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

[snip]

> > 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.

Good. I hope the WG is paying attention!

> > 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.

Works for me.

[snip]

> > 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.

Yeah. PW3 should connect to PE3 etc.

> > 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.

I'm OK with that, but it is a bit thin. Operators are famous for not configuring the same thing at two ends of a link.

> > 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.

Yup, "should" is better, and maybe add "The inter-domain VPLS relationship normally involves a contractual process between operators, and the configuration of PW roles forms part of this process."

> > 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.

OK

[snip]

> > 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.

That is good except that MD5 is pretty much regarded as useless as a security tool these days.

How about adding to the end of your text:

"The attention of implementers and deployers is drawn to [RFC6941]  and [RFC6952] with special attention to the recommendation to use TCP-AO [RFC5925] for enhanced security of LDP sessions."

Cheers,
Adrian