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