Subject: RE: Truly Generalized VPLS (?)

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 28 Jul 2003 17:19:31 -0400

Eric> The two PW endpoints have to agree  on such things as the use 
Eric> of the control
Eric> word, the  use of  signaling, etc.  They  may also  need to 
Eric> send  each other
Eric> status info.   These things are  done using the  control 
Eric> plane.  If  the two
Eric> endpoints  are  not  peers  in   a  control  plane  
Eric> relationship,  then  the
Eric> intermediate  nodes must,  be forwarding  control plane  
Eric> signals from  one pw
Eric> endpoint  to  another, which  means  that  the  intermediate 
Eric> nodes  maintain
Eric> per-PW control state.

(For the rest of this email, I assume a three hop PW: SRC-U-PE - SRC-N-PE - DST-N-PE - DST-U-PE)

I would think that the most important information is exchanged between SRC-U-PE and DST-U-PE. Things like Requested VLAN id and Maximum number of ATM cells should apply to the end-to-end path. If not, intermediate nodes would have to modify the payload of the PW, which is highly undesirable.

In  the splicing approach, you have three separate control sessions. To enable information exchange between the two U-PEs, you need to forward  parameters from one control session to the other. How exactly do you do that? Draft-rosen-l2-signaling suggests that you set up all PW segments independently and then splice them together. Suppose that SRC-U-PE and SRC-N-PE agree to use a Control Word and DST-N-PE and DST-U-PE agree not to use a Control Word. Is it the idea that one of the N-PEs inserts and deletes Control Words?

My proposal is to use RSVP with additional objects for PW capability negotiation that are only interpreted by the two U-PEs. If anything, I would think that that would require less state information in the intermediate nodes (i.e. the N-PEs) than the splicing approach with three separate LDP sessions.

In the RSVP approach, the only information maintained in the intermediate nodes is related to PW labels. However, in any Decoupled VPLS approach you need to do the same thing. Whatever mechanism you choose, an intermediate node needs to be able to map incoming label to outgoing label.

Eric> When a PW packet is received by a  PW endpoint, the PW label 
Eric> must be a label
Eric> which was assigned by that endpoint.   If the two endpoints 
Eric> are not peers in
Eric> a  control plane  relationship, the  PW  labels need  to be  
Eric> swapped by  the
Eric> intermediate nodes, which means  that the intermediate nodes 
Eric> maintain per-PW
Eric> labels.  
Eric> Given that these intermediate nodes  must maintain per-PW 
Eric> state, I don't see
Eric> how  your  proposal is  any  different  than  the splicing  
Eric> proposals.   The
Eric> operations performed by the intermediate nodes seem to be the same. 
Eric> 

Indeed, the operations performed by the intermediate nodes are the same. That is exactly my point. The splicing approach is a non-standard way to do something that can be done with existing protocols.

Above, I raised the question of how you do end-to-end capability negotiation if you have three separate control sessions. In my email to Wei Luo I identified issues with TTL, OAM and Protection Switching. I have no doubt that all these things can be solved, but they need to be specified in standards. The fact that a single LDP session between two peers is based on a standard protocol doesn't mean that three sessions spliced together is an obvious extension of that protocol.

There are standard protocols for setting up an LSP across multiple intermediate nodes. Why don't we use an existing solution instead of inventing a new one?

Eric> I also don't see why RSVP-TE is any better than LDP here. 

I hope the above makes clear why I think that three independent LDP sessions to set up separate PWs that are then spliced together is not a good approach. The question is: what to use otherwise?

If by LDP you mean CR-LDP, then I don't see why RSVP-TE would be better, except for the fact that I thought we were moving away from CR-LDP.

If by LDP you mean the topology-based flooding of labels, then I think RSVP-TE would be better. Capability negotiation and path set up is essentially a point-to-point information exchange between two U-PEs. I don't see how you would do that with LDP, but perhaps that is just my lack of understanding of LDP.

Eric> In  theory  you could  pass  around pw  endpoint  identifiers 
Eric>  in a  routing
Eric> algorithm, with  the splice points  being the possible next  
Eric> hops.  However,
Eric> you'd need  to invent  a summarizable addressing  scheme for  
Eric> the endpoints,
Eric> make sure the routing is loop-free, etc.  Frankly, I haven't 
Eric> seen the demand for this. 

This is probably just my ignorance. In a previous email I asked how an N-PE discovers the "local list" and "remote list" that you mention in section 5.5.1 of draft-rosen-l2-signaling. From your answer I got the impression that you envisioned that those lists would be manually provisioned by the Service Provider. If so, that strikes me as a big problem. It would mean that for every VPLS a Service Provider has to figure out how to route PWs and then provision the relevant information in all N-PEs that are involved. Why bother with things like auto-discovery and capability negotiation if connection set up is to a large extent manual? But again, I am probably just missing something.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 31 Jul 2003 15:43:26 -0400

Given your sample topology: 

      U-SRC-PE---N-SRC-PE--------N-DST-PE---U-DST-PE

One proposal uses  directed LDP to set up three  LDP adjacencies between (a)
U-SRC-PE  and N-SRC-PE,  (b) N-SRC-PE  and  N-DST-PE, and  (c) N-DST-PE  and
U-DST-PE.  

The  other  proposal sets  up  RSVP  adjacencies  between (a)  U-SRC-PE  and
N-SRC-PE, (b) N-SRC-PE and N-DST-PE, and (c) N-DST-PE and U-DST-PE. 

So far,  the only difference is that  the PW setup TLVs  and procedures have
already been defined for  LDP, but for RSVP we'd have to  define them.  If I
may quote you, "why don't we use an existing solution instead of inventing a
new one?" ;-)

Either proposal needs  to be able to carry  information between U-SRC-PE and
U-DST-PE.  Not  a problem for either  protocol.  In LDP, when  you receive a
particular  TLV on one  session, you  forward the  corresponding TLV  on the
other.  That doesn't seem like much  of an issue, though the proper behavior
would need to be specified.  (Note  that in an "ordinary" MPLS LSP, there is
an  independent LDP  connection between  every adjacent  pair of  LSRs.  The
notion of  passing attributes  along the path,  by passing them  through the
sequence of LDP  connections, is well understood; see  the "path vector" and
the "MTU" attributes.)

Peter> Draft-rosen-l2-signaling  suggests that  you set  up all  PW segments
Peter> independently and  then splice  them together. Suppose  that SRC-U-PE
Peter> and SRC-N-PE  agree to use a  Control Word and  DST-N-PE and DST-U-PE
Peter> agree not to use a Control Word. 

In principle this is no different  than if SRC-U-PE and DST-U-PE don't agree
on  whether to  use  the  control word.   In  that case,  you  don't get  an
operational pseudowire.   In the  splicing case, this  would show up  as the
inability to get an operational pseudowire between SRC-N-PE and DST-N-PE.  

Peter> Is it  the idea  that one  of the N-PEs  inserts and  deletes Control
Peter> Words?  

That  isn't my  proposal, though  others have  suggested that  there  if the
"splice points"  are at SP boundaries,  there are some  advantages to having
the  splice points do  control word  processing.  Well,  I'm not  sure about
that, but I can certainly see  advantages to breaking out the OAM processing
at SP boundaries, for example.

Peter> In  the  RSVP  approach,  the  only  information  maintained  in  the
Peter> intermediate nodes is related to PW labels.  

I think you also have to maintain the new objects, so the amount of state to
be maintained seems to be the same. 

Peter> 1) TTL 
Peter> Does each element in the path set  the TTL to 2, or does the SRC-N-PE
Peter> set it to 4 and the subsequent nodes decrease the value?  

As I've said repeatedly, the TTL should not be set to 2. 

Peter> 2) OAM
Peter> If  the SRC-U-PE  sends  a VCCV  Ping  message, is  it terminated  by
Peter> SRC-N-PE?  And  is  the  PW  between  SRC-N-PE  and  DST-N-PE  tested
Peter> independently? Or  is the  VCCV Ping sent  by SRC-U-PE,  forwarded by
Peter> SRC-N-PE to DST-N-PE, which in turn sends it to DST-U-PE?  

I  think  that in  either  method,  the data  plane  is  transparent to  the
splicing, for any  OAM done in the data plane will  tend to be edge-to-edge.
This may not always be desired;  if a splice point is at a provider-provider
border, each provider might want to  test his piece separately.  I don't see
that these issues are any different for the two proposals.

Peter> 3) Protection switching
Peter> Suppose SRC-U-PE is  dual-homed but has set up  only a single spliced
Peter> PW to DST-U-PE.  Now suppose that the PW segment between SRC-N-PE and
Peter> DST-N-PE goes  down and can not  be restored. How  does SRC-U-PE find
Peter> out that it needs  to set up another PW through the  other N-PE it is
Peter> connected to? Does N-PE send an error message that reports a fault on
Peter> a segment of the spliced PW?

I don't see that these issues are any different for the two proposals. 

Peter> There are  standard protocols for  setting up an LSP  across multiple
Peter> intermediate nodes.  

Well, yes, that's the typical use of LDP. 

Peter> If by LDP you mean CR-LDP

Yuck. 

Peter> If by LDP you mean the topology-based flooding of labels

No, directed LDP of course. 

Peter> In a  previous email I asked  how an N-PE discovers  the "local list"
Peter> and   "remote  list"   that   you  mention   in   section  5.5.1   of
Peter> draft-rosen-l2-signaling.  From your answer I got the impression that
Peter> you envisioned that those lists  would be manually provisioned by the
Peter> Service Provider.

No, the information can  be distributed by whatever auto-discovery procedure
we are using.