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

From: "Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]>
Date: Mon, 6 Jul 2009 17:21:35 +0800

Hi Luca:
According to your description, FEC defined in
draft-martini-pwe3-p2mp-pw-00 is much like the P2MP-PWid FEC defined in
draft-jounay-niger-pwe3-source-initiated-p2mp-pw-01. P2MP Pwid FEC does
not have TAII and P2MP PW-id. We are not intend to define two kind of
FEC same as P2P PW, which makes some confusion for vendors, so we remove
P2MP Pwid in the second version of
draft-jounay-niger-pwe3-source-initiated-p2mp-pw for simplicity. P2MP
GID FEC is more scalable than P2MP Pwid, and TAII is necessary for
autodiscovery. Also we remove the P2MP MS-PW in this release, because we
want to implement P2MP SS-PW for the first step.

IMO, Leaf Attachment Notification is necessary, in order to make root
node know the leaf node status, then the root node can adjust P2MP PSN
tunnel topology.

Anyway, draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02 needs the WG
experts to give comments, and work together to achieve P2MP PW
standardization.

Best Regards
Lizhong Jin

-----Original Message-----
----------------------------------------------------------------------

Message: 1
Date: Fri, 03 Jul 2009 23:18:23 -0600
From: Luca Martini <[email-masked]>
Subject: Re: [PWE3] LDP P2MP PW drafts discussion
To: [email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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-p2m
p-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
>   

------------------------------

Message: 2
Date: Sat, 4 Jul 2009 16:25:57 +0800
From: [email-masked]
Subject: Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain; charset="gb2312"

stewart:
  thank you for your explaining, I have already understood your meaning
in 
 your draft

best regards
liu

Stewart Bryant <[email-masked]> 
2009-07-03 17:21
??? ?
[email-masked]

???
[email-masked]
??
"[email-masked]" <[email-masked]>
??
Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00

[email-masked] wrote:
>
> Stewart?
> according to your answer, I have a few comments:
> 1 how to ensure the same pw label in multiple LSPs ? it says, maybe
> this pw label used for AC service, have been assigned to another AC
> service in a LSP of the multiple LSPs.

You assign PW labels exactly as you do today.

You pick LB labels by any method you wish regardless of whether the same
label is used more than once.

The flow label is simply a hint to the ECMP code, and has no
significance to anyone.

>
> 2 for sink points. IMO , flow label and pw label can't be
> distinguished only by Label Stack Level. it says , there is a
> possibility to regards the flow
> label as another pw label ,so it processed this flow label by
mistakes.
Sure, but this is a problem in any MPLS system - push or pop one label
too many and the result is undetermined.

You should know (from the PW label) whether you expect to see a LB label
and if you are expecting one you simply toss the next label.

Stewart

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail
is solely property of the sender's organization. This mail communication
is confidential. Recipients named above are obligated to maintain
secrecy and are not permitted to disclose the contents of this
communication to others.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
originator of the message. Any views expressed in this message are those
of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/pwe3/attachments/20090704/a26b0d93
/attachment.htm>

------------------------------

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

End of pwe3 Digest, Vol 63, Issue 6
***********************************

---

From: Luca Martini <[email-masked]>
Date: Wed, 08 Jul 2009 11:20:50 -0600

> want to implement P2MP SS-PW for the first step.
Can you explain how you would use the TAI for autodiscovery ?
Multicast does not have a concept of "Target" so I'm unclear on what the 
TAI is for.

> node know the leaf node status, then the root node can adjust P2MP PSN
I think that we can agree that in the case of mLDP , this is not necessary.
As for the case where we use a root initiated P2MP RSVP-TE tunnel we do 
need a specific message if we want to automate the LSP setup process.
So we probably need an LDP message that requests a P2MP RSVP-TE LSP 
extension to the leaf sending the request message,

Thanks for your comments .
Luca

---

From: "Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]>
Date: Fri, 10 Jul 2009 16:25:27 +0800

Hi Luca:
Thank you for your reply. Please see my comments with [Lizhong Jin].

Best Regards
Lizhong Jin

-----Original Message-----
From: ext Luca Martini [mailto:[email-masked]] 
Sent: Thursday, July 09, 2009 1:21
To: Jin, Lizhong (NSN - CN/Shanghai)
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] LDP P2MP PW drafts discussion

TAI is for.

[Lizhong Jin]: For P2MP MS-PW, TAI is needed for autodiscovery. For P2MP
SS-PW, you are right, TAI is not necessary. We should define a FEC which
can suitable for both P2MP MS-PW and P2MP SS-PW.

> node know the leaf node status, then the root node can adjust P2MP PSN
I think that we can agree that in the case of mLDP , this is not
necessary.

[Lizhong Jin]: in case of mLDP, when P2MP PW is multiplexing to an
already existing mLDP P2MP LSP, the ingress PE also need the successful
leaf information to choose a suitable existing mLDP P2MP LSP for
multiplexing. The P2MP PW multiplexing is always root initiated for both
RSVP-TE or mLDP.