Re: [PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements

Hi Fred,

This is all good with me.
Looking forward to the new revision when it is posted.

Thanks,
Adrian

> -----Original Message-----
> From: Jounay Frédéric [mailto:Frederic.Jounay@orange.ch]
> Sent: 01 April 2014 13:45
> To: adrian@olddog.co.uk; draft-ietf-pwe3-p2mp-pw-
> requirements.all@tools.ietf.org
> Cc: pwe3@ietf.org; Andrew G. Malis (agmalis@gmail.com)
> Subject: RE: [PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements
> 
> Hi Adrian,
> 
> Sorry for this very late reply!
> Please find below [FJ] the way we intend to address your points in a new
version
> 
> BR,
> Fred
> 
> -----Original Message-----
> From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: Thursday, 13 March 2014 15:46
> To: draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org
> Cc: pwe3@ietf.org
> Subject: [PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements
> 
> Hi,
> 
> I have done my usual review as AD in support of the publication request for
this
> document. This is now a very solid document : all credit to the authors and to
> Stewart's guidance.
> 
> As I have only a few minor nits with the text (shown below) I will start the
IETF
> last call and raise the issues there. You can address them together with any
other
> points that are raised during the last call.
> 
> Thanks for the work,
> Adrian
> 
> ===
> 
> PSN needs to be expanded in the title, Abstract, and Introduction.
> [FJ] Ok, I understand, replace PSNs by Packet Switch Networks
> 
> Please check for other acronyms like OAM.
> [FJ] I'd suggest to replace "OAM" by "monitoring"
> ---
> 
> Since this is not a protocol specification, the RFC 2119 language does not
apply in
> the way described in RFC 2119. I suggest you replace Section 1.3 with
something
> like...
> 
>    Although this is a requirements specification not a protocol
>    specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
>    "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted to apply to
>    protocol solutions designed to meet these requirements as described
>    in [RFC2119] .
> [FJ] Ok thanks
> 
> ---
> 
> I have a question about the architecture and model shown in Figure 1.
> Can the P2MP PW branch at an egress PE by having multiple attached ACs leading
> to different CEs?
> 
> Perhaps this does not count as a branch in the PW, but it is a branch in the
> service.
> [FJ] Correct. Initially we mixed the network enabler (PW) and the service.
That's
> the reason why we split the service definition (VPMS) in a separate L2VPN
draft
> http://tools.ietf.org/id/draft-ietf-l2vpn-vpms-frmwk-requirements-05.txt
> In other words we could show 2 CEs behind a Leaf PE, but the replication will
be
> done statically if we talk about VPMS (PW to several ACs), or based on MAC
> forwarding for VPLS (PW-VSI-ACs)
> 
> ---
> 
> In Section 3.2
> 
> s/P-to-MP MPLS LSP/P2MP MPLS LSP/
> [FJ] Ok
> ---
> 
> Section 3.4.2 has...
> 
>    The Root PE and Leaf PEs of a P2MP PW MUST be configured with the
>    same PW type as defined in [RFC4446] for P2P PW.  In case of a
>    different type, a PE MUST abort attempts to establish the P2MP PW.
> 
> That seems a little drastic. Do you mean "MUST abort attempts to attach the
leaf
> PE to the PW"?
> [FJ] I'd suggest indeed to clarify
> "SHOULD abort attempts to attach the leaf PE to the P2MP PW"
> 
> Similarly in 3.4.3.
> MUST support mechanisms to reject attempts to
>    establish the P2MP SS-PW.
> ==>
> SHOULD support mechanisms to reject attempts to
>    attach the leaf PE to the P2MP PW
> 
> ---
> 
> Section 4 might usefully refer back to the discussion of OAM.
> [FJ] as proposed in my previous email, I suggest to remove the section4, since
> MS-PW is out of scope
> ---
> 
> Section 5 is fine, but it is interesting to consider
> 
>    A solution MUST NOT allow a P2MP PW to be established to PEs that do
>    not support P2MP PW functionality.  It MUST have a mechanism to
>    report an error for incompatible PEs.
> 
> Does an egress PE even need to know that it is attached to a P2MP PW rather
> than a P2P PW?
> [FJ] this is related to the fact that the P2MP PW gets a specific identifier
(e.g. new
> FW)
>  this requirement is referring to section 3.4.1
>    The P2MP PW MUST be uniquely identified.  This unique P2MP PW
>    identifier MUST be used for all signaling procedures related to this
>    PW (PW setup, monitoring, etc).
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3