Subject: [mpls] PHP of draft-ietf-mpls-mldp-in-band-signaling-03

From: [email-masked]
Date: Sat, 12 Feb 2011 09:54:49 +0800

Hi Ice,
>From the technical point of view, the leaf node (will never be Bud node, 
if ensure) can enable PHP if LSP carries IP multicast traffic (application 
described in draft-ietf-mpls-mldp-in-band-signaling-03), right? The bud 
node should always disable the PHP. But the problem is that one leaf node 
may become a bud node in future. Then what is the PHP behavior for 
draft-ietf-mpls-mldp-in-band-signaling-03?
draft-ietf-mpls-ldp-p2mp does not describe the PHP behavior for node, does 
that mean the application binding P2MP/MP2MP LSP should address the PHP 
behavior?

Thanks
Lizhong

--------------------------------------------------------
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.

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 12 Feb 2011 01:28:05 -0800

Why do we want to bother about PHP with mLDP.

  inv(Nike): Just don't do it.

I've still not seen an mentioning of benefits, eg:
performance downside is IMHO a historical argument.

With inband signaling, i also have the most simple example of
why it can break things.
If the downstream PE wants to fail over for the same (S,G)
between two headend PE, then it is that last-hop label that
provides the ability to drop the currently unwanted version of the
(S,G) flow during switchover. The same would be true for any other
switchover cases on the tailend PE between different LSPs.

Or just the generic considerations:

I only want labelled multicast packet on my core, that way i can much better
distinguish them from my native multicast packets on the CE side.

I want mLDP to stay simple, and consistently doing label
binding all the way from headend LSR to tailend LSR makes the
last hop not a special case where i need to spend always level of
design considerations.

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
Network Agnostic: Applications that work best on cheap, stupid networks.
Suicide: Devaluating the intelligent network with network agnostic apps.

---

From: [email-masked]
Date: Sat, 12 Feb 2011 22:43:53 +0800

Hi Toerless,
It is not my intention to allow PHP for mLDP, and I agree with you to 
disable PHP for mLDP. Since PHP is the default function in many current 
MPLS implementations, it is necessary for the mLDP in-band signaling draft 
to explicitly describe whether PHP should be always disabled or enabled, 
so as to avoid misunderstanding.

Lizhong

Toerless Eckert <[email-masked]> wrote on 2011-02-12 17:28:05:

> >    node should always disable the PHP. But the problem is that oneleaf 
node
> >    draft-ietf-mpls-ldp-p2mp does not describe the PHP behavior 
fornode, does
> >  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.