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

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

Hi Adrian,
Thank you for the review. We will reply the comments soon.

Regards
Lizhong

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: 2014年3月26日 5:36
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy
> 
> Hi,
> 
> I just want to add to these comments that the Security AD's review of
draft-
> ietf-pwe3-iccp reads...
> 
> > The
> > security model relies upon physical security with some (not great)
> > provisions for authentication and access controls (address filtering,
> > anti-spoofing, MD5 authentication).  Monitoring provides the ability
> > to catch a problem if a security breach arises s was described in the
> > response to the SecDir review.  Our threat models and understanding of
> > them continues to evolve with service providers being a major target,
> > as well as administrators.  Stronger authentication options and
> > session encryption should be considered if a redesign as suggested in
> > other IESG reviews is done.
> 
> This suggests that your work should not simply lean on the security
> considerations of draft-ietf-pwe3-iccp because they will not be considered
to
> be sufficient for wider deployment in the Internet.
> 
> Thanks,
> Adrian
> 
> > -----Original Message-----
> > From: L2vpn [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > Sent: 22 March 2014 17:02
> > 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
> >
> > ---
> >
> > 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?