Subject: Re: [PWE3] LDP P2MP PW drafts discussion

From: Luca Martini <[email-masked]>
Date: Fri, 03 Jul 2009 23:18:23 -0600

Fred,

Comments below.

[email-masked] wrote:
>
> Luca,
>
> Please find some comments on the new draft 
> _http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-00_.
>
> From a general point of view it seems that your proposal relies on 
> almost the same basic principles as the  draft 
> _http://tools.ietf.org/html/draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02_ 
> (posted 2 years ago and presented during the last IETF meeting), with 
> the main difference that it is restricted to the SS-PW case.
>
I disagree. In general 
draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02 is a general sketch 
of a possible solution. There are  many TBDs , and text that states:

" The    P2MP PW Downstream Label Assignment and detailed procedures for
   setting up a P2MP PW over a P2P LSP will be described in a future
   version."

Since we have waited a long time , and your draft does not describe an 
implementable solution.
You define many unnecessary parameters as follows:

- TAII ( does not convey any useful information. The NMS will handle 
this functionality, not the protocol )
- P2MP Id ( this can be incorporated into the SAII , or AGI , it just 
more bits for those values )
- There is no need to send a status code in the FEC. ( this was done in 
rfc4447 only for negotiation/backward compatibility reason )
- There is no need for a pw status negotiation procedure mentioned in 
4.5.2, but not defined.
- Leaf Attachment Notification Message. ( This is an NMS function , 
there is no action to be taken by the PE, this message not necessary)

> The solution defined for P2MP SS-PW must be designed with the capacity 
> to support also P2MP MS-PW. This is the case in the draft jounay-niger.
>
The draft jounay-niger does not describe this capability either.

> The v00 presented the procedure for MS-PW. We removed the MS-PW part 
> from the last version for sake of simplification in order to focus on 
> the basic protocol elements, but the capacity to support P2MP MS-PW 
> remains unchanged.
>
> As indicated in the introduction your draft is focused on the SS-PW 
> case and in its current state does not allow the support of MS-PW for 
> the following reasons :
>
> - The Group ID does not carry information about leaves identification 
> (e.g. @ AII) and the signalling messages initiated by the root could 
> not be routed to the leaves. In our proposal the S-PE forwards the 
> signaling based on the TAII (leaf node @) transported in the TAII Leaf 
> sub-TLV,
>
Again the TAII is redundant. The leaf PE is identified by the LDP 
router-ID and  the LDP session on which the message came in. This is the 
normal operation of LDP , even for IP FECs.

> -The downstream assigned label proposed for upstream traffic (from 
> leaf to root) can be used in SS-PW to identify the leaf node itself. 
> However this can not be the case for MS-PW due to the merging point 
> (S-PE) for upstream traffic.
>
S-PE are part of MS-PW architecture. So I am not clear of what you are 
talking about here. The downstream-assigned label ( L-PE to R-PE traffic 
direction ) is assigned by the root PE. How it is assigned , is a matter 
of local policy. It may be the same for all L-PEs or maybe not. This is 
not something relevant to the protocol specification.

> I think that's worth coming back to the last point since it appears to 
> be the main difference with the jounay-niger draft. This requirement 
> has not yet been defined in the P2MP PW REQ draft. The leaf can report 
> some OAM/PW status based on LDP Notification messages, but  so far it 
> has not been identified as necessary to allow leaves to send traffic 
> to the root. Is it a strong requirement? for which applications?  If 
> yes, we need to address it first in the P2MP PW REQ draft.
>
For a simple P2MP PW, a return path toward the root is sometimes 
necessary, especially if there is no VPLS associated with this tree.

> In the "incompatibilty issues" section (4.1), you propose to follow 
> the same procedure as defined for P2P (bidirectionnal), i.e. the Leaf 
> node initiates a LDP status with "PW not forwarding" when the PW type, 
> CW or int/ parameters does not match with local configuration. We 
> don't think it appropriate for a P2MP connectivity, because a pb on a 
> given Leaf node shoud not impact other leaves belonging to the PW 
> tree. We propose in the draft the definition of new status codes which 
> allow the Ingress PE to determine exactly the issue (PW type non 
> compliant code, i/f. Parameters incompatibility code, 
> Unassigned/unrecognized AGI/P2MP ID).
>
There is no effect from one leaf to another. The action that the R-PE 
takes upon receiving a pw status message has not yet been defined in our 
document. We are still discussing how to map the status messages to the 
ACs. ( similar to the oam-message-mapping draft ). Remember that we do 
not transmit NMS related messages in the LDP protocol.
>
> For the i/f parameters, there is some difference with P2P PW 
> procedure, please refer the jounay-niger draft (section 4.5.6) or the 
> draft P2MP PW REQ (section 3.4.2).
>
I disagree with the procedures in sec 4.5.6. Signaling of interface 
parameters must be mandatory. Also there is no need to mention every 
interface parameter in the document , or it will become obsolete very 
quickly as soon as a new PW type is defined.

> Since the beginning of the P2MP PW work our proposal has been closely 
> designed with the L2VPN WG, and in particular with the VPMS draft. 
> From this joint work a definition of an optimized P2MP PW FEC has 
> emerged with the definition of a P2MP ID. The P2MP ID is proposed to 
> overcome some future operational contrainsts. Indeed in the case we 
> want to provide similar protection scheme as PW redundancy, we need to 
> differentiate the primary P2MP PW from the backup P2MP PW in terms of 
> PW identifier. Such a piece is missing in your proposal  Please refer 
> to section 4.7. or slides presented during the last IETF PWE3 meeting.
>
> Eventually You define a new Transport LSP TLV, used to indicate to the 
> leaf node the PSN tunnel the P2MP PW is supported over. This is 
> required due to the P2MP PW upstream label assignment.  There is 
> already a draft which introduces such an Interface ID (Please refer to 
> _http://tools.ietf.org/html/draft-ietf-mpls-ldp-upstream-03_). In 
> order to avoid refining a new TLV for a common purpose it seems 
> preferable to extend it to include MLDP P2MP LSP TLV as new Interface 
> ID, as proposed in our draft.   
>
That document is expired, and I believe that RFC5331, RFC5332, and 
draft-ietf-mpls-ldp-p2mp-06 describe the proposed standard to be followed.
>
> Considering all these points we invite you to read the jounay-niger 
> draft, and since this draft proposes a more general solution, 
> extensible to MS-PW, we propose to work together to integrate in this 
> proposal already on the table the new feature described in your draft 
> (i.e. the P2P return connectivity from leaf to root).
>
Luca

> Best Regards,
> Fred
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>