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

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

Hi Adrian,
Thank you for the quick reply. See my reply inline below.
We will post a new version accordingly soon to reflect these comments.

Regards
Lizhong

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: 2014年3月31日 3:41
> To: 'Lizhong Jin'; draft-ietf-l2vpn-vpls-inter-domain-
> [e-mail]
> Cc: [e-mail]
> Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy
> 
> 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!
[Lizhong] OK, we will post a new version accordingly.

> 
> > > 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.
[Lizhong] Thanks.
> 
> [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.
[Lizhong] 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.
> 
> 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.
[Lizhong] I understand. At current stage, let's keep it simple.

> 
> > > 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."
[Lizhong] OK, thanks.

> 
> > > 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."
[Lizhong] OK, thanks.

> 
> Cheers,
> Adrian
>