Subject: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 26 Oct 2011 10:36:26 +0200

Dear Emly and Quintin,

Quick comment/question on this draft.

From your draft, figure 3, if router R3 does not support mLDP and you want to tunnel the mLDP traffic through it using a P2P LSP, does it not need to be upgraded using code that supports this feature? If you need to upgrade, why not upgrade it with mLDP code?

The case where this would be useful is if there is a router that can't support mLDP due to platform dependencies, its in the middle of the network, but you are able to upgrade the router with new code platform independent code supporting this feature.

If the router not supporting mLDP is closer to the root node, it makes more sense to setup a Targeted LDP session immediately with the root skipping the non-mLDP router. That way you don't need to upgrade the non-mLDP router at all.

Thx,

Ice.

---

From: Quintin Zhao <[email-masked]>
Date: Wed, 26 Oct 2011 10:08:25 -0400

Dear Ice,

Thanks for your comments.

You are right that the R3 needs to upgraded using the code that supports
this feature, the code change should be limit to the control plane to
process the new type of LDP MP Status Value Element without any changes to
the forwarding plane. 

The case that this draft addresses is that when a mLDP router (router D)
needs to find out the first mLDP router ( router U) on the path to the root,
where router D is not directly connected to router U and also there is no
Target session setup yet between router U and router D. In this case, the
route D needs to use the non-mLDP router (router M) in the middle of the
path between router D and router U to process the new type of LDP MP Status
Value Element and pass it on until it reaches the router U. And after that,
the router U initiates the Target session with router D. 

It is true that if the router D can find the router U, no matter it is close
to the root or not, in the first place through offline tools or through
configurations, then we can skip the non-mLDP router and setup a Targeted
LDP session without upgrading the non-mLDP router at all. We will clarify
this more in the next revision of the draft.

Quintin

-----Original Message-----
From: IJsbrand Wijnands [mailto:[email-masked]] 
Sent: 2011年10月26日 4:36
To: Emily Chen(Ying); [email-masked]
Cc: [email-masked]
Subject: draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00

Dear Emly and Quintin,

>From your draft, figure 3, if router R3 does not support mLDP and you want
to tunnel the mLDP traffic through it using a P2P LSP, does it not need to
be upgraded using code that supports this feature? If you need to upgrade,
why not upgrade it with mLDP code?

The case where this would be useful is if there is a router that can't
support mLDP due to platform dependencies, its in the middle of the network,
but you are able to upgrade the router with new code platform independent
code supporting this feature.

If the router not supporting mLDP is closer to the root node, it makes more
sense to setup a Targeted LDP session immediately with the root skipping the
non-mLDP router. That way you don't need to upgrade the non-mLDP router at
all.

Thx,

Ice.

---

From: Boris Zhang <[email-masked]>
Date: Wed, 26 Oct 2011 16:26:01 -0400

Quintin

I am still wondering in what kind of situation we have control plane capable to support mLDP while forwarding plane doesn't. Does it implicate deploying mLDP requesting quite a lot upgrading on forwarding plane on current platform ( router & switch) ?

Thanks
Boris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Quintin Zhao
Sent: October 26, 2011 10:08 AM
To: 'IJsbrand Wijnands'; 'Emily Chen(Ying)'
Cc: [email-masked]
Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00

Dear Ice,

Quintin

-----Original Message-----
From: IJsbrand Wijnands [mailto:[email-masked]] 
Sent: 2011年10月26日 4:36
To: Emily Chen(Ying); [email-masked]
Cc: [email-masked]
Subject: draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00

Dear Emly and Quintin,

Thx,

Ice.

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

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 26 Oct 2011 17:22:04 -0400

+1

Quintin,
Even though FW part of mLDP is quite complex I'd be rather interested to
see a vendor implementing CP only, without FW support.
-- 
Regards,
Jeff

On 10/26/11 1:26 PM, "Boris Zhang" <[email-masked]> wrote:

>Quintin
>
>I am still wondering in what kind of situation we have control plane
>capable to support mLDP while forwarding plane doesn't. Does it implicate
>deploying mLDP requesting quite a lot upgrading on forwarding plane on
>current platform ( router & switch) ?
>
>Thanks
>Boris
>

---

From: Quintin Zhao <[email-masked]>
Date: Thu, 27 Oct 2011 10:57:19 -0400

Boris, Jeff,

Thanks for your comments!

Supporting the full mLDP feature requires at least forwarding plane changes
to support the MPLS multicast package forwarding. Depending on the
protection mechanisms for mLDP LSP implemented, it may also require the
forwarding changes to support mLDP LSP's link and/or node protections
features.

The changes for the control plane of the non-mLDP node in this proposal is
just to pass the new type of LDP MP Status Value Element in a notification
message to its upstream node. It doesn't require the implementing of the
whole mLDP control plane feature for the p2p node.  It is true that even
this is a small feature change, it still needs the upgrade of the control
plane. 

Quintin

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: 2011年10月26日 17:22
To: Boris Zhang; Quintin Zhao; 'IJsbrand Wijnands'; 'Emily Chen(Ying)'
Cc: [email-masked]
Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00

+1

Quintin,

---

From: Eric Rosen <[email-masked]>
Date: Thu, 27 Oct 2011 11:28:30 -0400

I share the already-expressed concern that there is no real use case of
this.  In theory, one can imagine deployments where all the routers support
the mLDP control plane, but some do not support an MPLS multicast data
plane.  In practice, I'm not so sure.

There may be deployments in which multicast forwarding capability is
supported only around the edges of the network, and the core is "multicast
free".  The use of mLDP in this kind of deployment is discussed in
draft-napierala-mpls-targeted-mldp.

I also have some technical questions about the draft.

I'm a little confused about the capability you're defining.  Presumably it
means "I don't support mLDP natively, but I support the mLDP tunnel mode".
So I guess it would be illegal to advertise this capability and also
advertise the ordinary "mLDP capability, though this isn't stated.  

In the topology: Root---R1---R2---R3---R4 suppose that R2 and R3 are
"mldp-tunnel-only" mode routers, but R1 and R4 are full mldp routers.  I
think the interaction being proposed is:

  * R4 selects R3 as the upstream node for <Root,X>

  * R4 knows (from the capability) that R3 is "mldp-tunnel-only"

  * Therefore R4 asks R3 "who is the closest 'full mLDP' node on your path
    to Root?"  R4 has to remember that it asked this question, and that it
    is waiting for an answer.
    
  * R3 asks R2 the same question, also telling it "R4 needs to know".

  * R2 selects R1 as the upstream node for <Root, X> and determines that R1
    is a "full mLDP" node.

  * So R2 tells R1 "set up a targeted mLDP session with R4".

    Of course, R4 will probably not accept this session until some more
    messages flow from R2 to R3 to R4.

  * R2 tells R3 "R1 is the closest full mLDP node on the path to Root".

  * R3 tells R4 "R1 is the closest full mLDP node on the path to Root".

  * Once R4 learns this fact from R3, R4 will now be willing to accept a
    T-mLDP session from R1, and will choose R1 as its upstream hop (over a
    P2P tunnel) to Root.  (Unless the unicast routing has changed in the
    meantime, of course.)

I think this raises a number of issues:

  * I don't think I could say from the draft exactly which messages are used
    for which purposes.

  * If R2's next hop to Root changes, it needs to tell R3 to that R1 is no
    longer on the path, and R3 needs to tell R4.  R4 may need to tear down
    the targeted session to R1.  Probably R2 has to tell R1 "R4 is no longer
    going to use you as the upstream hop for Root", in which case R1 may
    need to tear down the targeted session.  None of this is discussed in
    the draft.

  * If R2's next hop to Root changes, it also needs to find the closest full
    mLDP node on the new path to Root.  Then it needs to tell R3, R3 needs
    to tell R4, etc.  
    
  * To make this work, I think the intermediate nodes have to maintain state
    about which upstream node is the closest full mLDP node to Root, and
    which downstream nodes have asked about the path to Root.

  * If R4's next hop to Root changes, R4 has to tell R3 "never mind, I no
    longer care about the closest full mLDP node on your path to Root".  R3
    has to tell R2 "never mind", R2 has to tell R1 "tear down your T-mLDP
    session to R4" (if you have no other reason to keep it up).  R4 will
    also have to tear down its T-mLDP session to R1 (if it has no other
    reason to keep it up.)  This should all be discussed in the draft.

The draft needs a lot more detail, and I think it will turn out to be quite
complicated to handle all the race conditions and corner cases correctly.
It's just not worth it unless there is a real use case.

I'm also not sure that the notification messages and status tlv are the
right mechanisms, as the functionality that seems to be needed is more like
"request/respond/withdraw/release" than it is like "notify".

---

From: Kannan KV Sampath <[email-masked]>
Date: Fri, 28 Oct 2011 12:06:39 +0530

Hi Quintin,
I have the same opinion as of Eric.
The draft looks like a theoretical requirement.
If there is no practical real time use case, it is not worth it to make it so complicated.
If you add more details and address the concerns raised by Eric, and, if we start thinking about FRR, protection, etc., for both p2p tunnel and the multicast path, the draft will become too complicated.
May be you can explain more about the real time use case for this requirement.

Regards,
Kannan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rosen
Sent: Thursday, October 27, 2011 8:59 PM
To: Quintin Zhao
Cc: [email-masked]; 'Emily Chen(Ying)'; 'IJsbrand Wijnands'
Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00

===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

---

From: Quintin Zhao <[email-masked]>
Date: Fri, 28 Oct 2011 10:58:17 -0400

Eric, Kannan,

Thanks for your comments and suggestions!

The user's requirement for this scenario is this:  The first phase
deployment needs the limited number of nodes to be upgraded to support the
mLDP and leave the rest of the nodes in the network as it is.  Since the
mLDP bud node might be in any place of the network, it is a little more
complex than a "mLDP free core" network which Eric pointed out.

It depends on the size of the network and how long the transition period is
for the complete upgrade of the network to mLDP,  the non-direct upstream
mLDP node's finding might be needed in this deployment scenario to trigger
the T-LDP dynamically and in the failure cases, it needs to be tear down
automatically also.

For the signaling mechanism, we indeed missed a lot of details in the draft
as Eric pointed out including the capability advertisement and also we did
not describe clearly the goal for this solution is to make the mLDP LSP
setup info to be passed through the non-mLDP node without maintaining state.
Now based on Eric's comment, we need further investigate to see if we can
make the solution work without making it very complex.

Two more clarification question for Eric's analysis,

(1) Once R1 receives the notification message from R2, R1 can initiated the
T-LDP session directly to R4 by telling R4 that it has received the
notification message (protocol extension might be needed) . In this way,
there is no need to make the R2 and R3 to maintain the state and R4 doesn't
need to wait for the message coming back from R1 through R2 and R3. Will
this work?

(2) Why can't we tear down the T-LDP session between R1 and R4 only when the
R4's next hop to root, in the example it is R3,  is changed?
 
Quintin

-----Original Message-----
From: Kannan KV Sampath [mailto:[email-masked]] 
Sent: 2011年10月28日 2:37
To: Quintin Zhao
Cc: [email-masked]; 'Emily Chen(Ying)'; 'IJsbrand Wijnands'; Eric Rosen
Subject: RE: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00

Hi Quintin,
I have the same opinion as of Eric.
The draft looks like a theoretical requirement.
If there is no practical real time use case, it is not worth it to make it
so complicated.
If you add more details and address the concerns raised by Eric, and, if we
start thinking about FRR, protection, etc., for both p2p tunnel and the
multicast path, the draft will become too complicated.
May be you can explain more about the real time use case for this
requirement.

Regards,
Kannan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Rosen
Sent: Thursday, October 27, 2011 8:59 PM
To: Quintin Zhao
Cc: [email-masked]; 'Emily Chen(Ying)'; 'IJsbrand Wijnands'
Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00

============================================================================
===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
============================================================================
===