Subject: Re: Scaling hierarchical LDP/PW stitching

From: Mustapha Aissaoui <[email-masked]>
Date: Fri, 30 Jul 2004 18:02:44 -0400

Peter,
Let us decompose the problem to gain more insight into the issue.
Sorry for the lengthy message. Any comments are appreciated. 

I will be using the following diagram as an example to help walk
through the various functions required to set up a MH-PW. I
abstracted the network to only show the PEs and the Stitching Nodes
(SNs). These nodes are inter-connected over a set of Tunnel LSPs
(TLSPs). For now, assume these are FA-LSPs. Also, let us assume that
all these nodes are in a single domain.

|PE1|--(TLSP)--|SN1|--(TLSP)------|SN3|--(TLSP)---|PE2|
  |              |                  |               |
  |              |---------------|  |               |
  |                              |  |               |
  |              |---------------|--|               |
  |              |               |                  | 
  |---(TLSP)---|SN2|---(TLSP)---|SN4|--(TLSP)-------|

1. The first thing to do is to discover the nodes which are capable
of acting as "stitching nodes". This will allow a specific PE or
stitching node to know which nodes it can direct the PW signaling
messages to. There may be several ways to do that including the
possibility you mentioned in which any node can act as a stitching
node and therfore you can skip to (2) below.

2. When SN1 receives a PW signaling message, RSVP-TE or Targeted LDP
(TLDP), from PE1, it needs to figure out which is the next-hop SN.
Assume that either a Explicit Route object or a local reachability
lookup indicates SN2. An explicit route object can be received in a
RSVP-TE path message. A local reachability lookup is used in the
case of TLDP PW signaling and is based on the destination PE address
which needs to be included in the PW signaling message. The local
lookup selects SN2 as a result of a FA-LSP advertisement.
 
3. In the case of TLDP PW signaling, the TLDP session between PE1
and SN1 is separate from that between SN1 and SN2. However, for the
purpose of MH-PW signaling, they need to be coordinated. This means
that SN1, and other transit SNs, can continue to process the
signaling messages for the two directions independently but will
only perform the sticthing in the datapath when both directions have
been setup.

5. The above procedures are repeated at each node until the PW
signaling message reaches PE2. PE2 may trigger the reverse direction
either independently or in response to the received label mapping
message.

So far, it appears that we can have MH-PW without making the PW
labels routable and that both RSVP-TE or TLDP could be used for PW
signaling.

Though, we have the following open issues:
a. How do stitching nodes get identified? The mere fact that a
FA-LSP exists between SN1 and another node cannot be used as an
indication that the latter can be used as a stitching node.
b. FA-LSP are mandated to connect SNs. This is restrictive in my
view. It is not clear to me how non FA-LSPs could be used as tunnel
LSPs.

Regards,
Mustapha.
-----------
"Busschbach, Peter B (Peter)" wrote:
> 
> > In my view, we cannot start with the assumption that every node
> > could be a stichting node as this has the consequence of
> > degenerating into an all PW routable network.
> 
> Hi Mustapha,
> 
> Every LSR *can* be a PW stitching node. It is not an assumption. It is a simple observation based on the recognition that a MH-PW is really nothing more than an LSP.
> 
> That does not mean that every LSR *should* be used as a stitching node. That would eventually not result in a scaleable solution. Operators will use Transport LSPs to aggregate PWs. They will identify specific nodes that will function as stitching nodes and they will set policies that prompt those nodes to establish the segments of a MH-PW through the Transport LSPs.
> 
> I think that thus far we agree. We seem to disagree on how you actually determine the end-to-end route.
> 
> You write: "I need to use a policy to decide how a stitching node should move a PW from one tunnel LSP to another one. I do not need a routable PW label to perform a local forwarding operation in a few stiching nodes."
> 
> By saying that there are only a few nodes, you imply that there is no need for a true routing solution. I disagree. The question is: when the first stitching node receives a PW setup request from a PE, how does it know what the next hop on the path is? Or, in your words, the PW has to be moved to the next tunnel, but which tunnel? You say: there are policies. What kind of policies? Are you suggesting that the operator manually provisions a routing table? Something like: for AGI=X and AII=Y, the next hop is Z?
> 
> I thought that the email exchange between Richard Spencer and Du Ke illustrated this problem very well and after a few emails up and down, Du Ke acknowledged that there is a need for some topology discovery mechanism.
> 
> My contention is: we already have a topology discovery mechanism. If you identify a MH-PW with the IP addresses of its ingress and egress PE and you use the principles of draft-ietf-mpls-lsp-hierarchy-08.txt, you have a solution.
> 
> Peter
> 
> > -----Original Message-----
> > From: Mustapha Aissaoui [mailto:[email-masked]]
> > Sent: Tuesday, July 27, 2004 3:26 PM
> > To: Busschbach, Peter B (Peter)
> > Cc: [email-masked]'; [email-masked]; [email-masked];
> > [email-masked]'
> > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching
> >
> >
> > Peter,
> > I added a few comments below.
> >
> > Regards,
> > Mustapha.
> > ---------
> > "Busschbach, Peter B (Peter)" wrote:
> > >
> > > Hi Mustapha,
> > >
> > > I agree with your last point, i.e. that we need to
> > understand the requirements before we decide which solution
> > is best suited. However, IMO your email  obscures some
> > important issues.
> > >
> > > Peter
> > >
> > > > -----Original Message-----
> > > > From: Mustapha Aissaoui [mailto:[email-masked]]
> > > > Sent: Monday, July 26, 2004 5:20 PM
> > > > To: Busschbach, Peter B (Peter)
> > > > Cc: [email-masked]'; [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]'
> > > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching
> > > >
> > > >
> > > > Peter,
> > > > in networks where end-to-end traffic engineering of PWs
> > is required,
> > > > or where any intermediate LSR could act as a stitching
> > node, the use
> > > > of RSVP-TE for PW setup makes a lot sense.
> > >
> > > One of the things I was trying to get across in earlier
> > emails is that >every LSR _can_ function as a stitching node.
> > A MH-PW is nothing more >than a pt-to-pt LSP between two PEs
> > and the stitching points are nothing >more than LSRs that
> > switch PW labels.
> >
> > MA> If every LSR could function as a stitching node, which implies
> > that it would keep state for each PW and know how to forward it, why
> > bother carrying PWs over a tunnel LSP? The reachability information
> > required by the PW will be exactly the same as that of the tunnel
> > LSP.
> > In my view, we cannot start with the assumption that every node
> > could be a stichting node as this has the consequence of
> > degenerating into an all PW routable network.
> >
> > > RSVP-TE is the appropriate tool for the setup of such
> > pt-to-pt LSPs. CR-LDP is an alternative.
> > >
> > > I don't think it is correct to say that RSVP-TE only makes
> > sense if you >need to do traffic engineering. RSVP-TE makes
> > sense anyway. The fact that >it can be used for traffic
> > engineering is an added benefit.
> >
> > MA> I said RSVP-TE made sense in this case. I do not think it is the
> > only case. Have you thought of other cases?
> >
> > > > However, in many cases
> > > > this will not be a requirement. There will be a few stiching nodes
> > > > which are known a priori.
> > >
> > > I am not sure what your point is. You are saying that in
> > many cases there is no need for a scaleable solution. But in
> > other cases there is. Should we just ignore the latter?
> >
> > MA> My starting point is different from yours. I am looking into a
> > network where most of the label switching is performed at the tunnel
> > LSP level and where a few nodes act as stitching points. So the
> > forwarding information is mostly based on the tunnel LSP routing
> > information. I need to use a policy to decide how a stitching node
> > should move a PW from one tunnel LSP to another one. I do not need a
> > routable PW label to perform a local forwarding operation in a few
> > stiching nodes.
> >
> > > The other problem I have with this statement is your
> > suggestion that >stitching nodes are known a priori and that
> > (therefore?) we can get away >with simple solutions. As far
> > as I can see, every solution that uses a >hierarchy of LSPs
> > requires certain a-priori policies.  But that is not >the
> > point. The crux of the discussion between Du Ke and Richard
> > Spencer >was that you need to have mechanisms to find an
> > end-to-end path between >two PEs. Therefore, even if a PE
> > would have the choice between only two >stitching nodes, it
> > needs to select one of the two. And if the primary >selection
> > fails, it has to be able to switch over to the secondary node.
> >
> > MA> How is this different from a node dual-homed to a network? A
> > local policy in the node states which is the primary node and if
> > load-balancing is allowed over both links. This node does not need
> > to participate in the exchange of reachability information with the
> > rest of the network.
> >
> > > draft-martini-pwe3-pw-switching-00.txt assumes that the
> > stitching point >is manually configured. That could create
> > problems for protection >switching.
> > draft-yudong-pwe3-control-protocol-ext-00.txt adopts a
> > >solution that is at least capable of routing around
> > failures, but it >assumes that the operator assigns an
> > absolute priority to the stitching >nodes. That would nto
> > work well if the operator is interested in load >balancing.
> >
> > MA> I am not sure why this should not work for load balancing. How
> > is this different from a node which performs load-balancing over
> > dual-homed links?
> > Unless you are thinking of load balancing PWs end-to-end over a set
> > of tunnel LSPs. In this case you want to traffic engineer your PWs.
> >
> > > I am sure that LDP-based proposals can be enhanced to deal
> > with these >issues, but why not use an existing protocol for
> > which these issues have >already been investigated and
> > solved? And not only that. It already has >solutions for
> > traffic engineering, fast reroute and graceful restart as >well.
> >
> > MA> Again, you can take advantage of all this but you really did not
> > need the tunnel LSPs and just let the PWs be routable across the
> > network.
> >
> > > > For instance, one may want to stitch PWs over a set of
> > intra-domain
> > > > tunnel LSPs which may or may not have been separately traffic
> > > > engineered inside their own domain. The stitching nodes will be a
> > > > few ASBRs.
> > >
> > > I consider inter-AS scenarios (and especially,
> > inter-provider scenarios) as a special case and I can see
> > that we adopt a different solution for inter-AS cases than
> > for intra-AS cases.
> > >
> > > I agree that we need to uderstand the target applications.
> > I would just be careful in making general statement based on
> > an inter-AS example. It can easily lead you in the wrong direction.
> > >
> > > > Thus, having a solution based on Targeted LDP which
> > > > removes pre-configuration at the stitching node is desirable. One
> > > > possible solution is to use the "Self-Mode" described in
> > > > draft-yudong-pwe3-control-protocol-ext-00.txt where the boundary
> > > > routers act as the stitching nodes.
> > > >
> > > > So, the targetted application one wants to address should be
> > > > examined to understand which solution is best suited.
> > > >
> > > > Regards,
> > > > Mustapha.
> > > > -----------
> > > >
> > > [snipped]
> >
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 31 Jul 2004 01:24:00 +0200

mustapha, see in-line

Mustapha Aissaoui wrote:

> Peter, Let us decompose the problem to gain more insight into the
> issue. Sorry for the lengthy message. Any comments are appreciated.
> 
> |PE1|--(TLSP)--|SN1|--(TLSP)------|SN3|--(TLSP)---|PE2| |
> |                  |               | |              |---------------|
> |               | |                              |  |               |
>  |              |---------------|--|               | |              |
> |                  | 
> RSVP-TE path message. A local reachability lookup is used in the case
> of TLDP PW signaling and is based on the destination PE address which
> needs to be included in the PW signaling message. The local lookup
> selects SN2 as a result of a FA-LSP advertisement.
> 
> 3. In the case of TLDP PW signaling, the TLDP session between PE1 and
> SN1 is separate from that between SN1 and SN2. However, for the 
> signaling messages for the two directions independently but will only
> perform the sticthing in the datapath when both directions have been
> setup.
> 

PW labels are keeping a (FA link) local scope (using the figure PE1-SN1 
or SN1-SN3 for instance)

> Though, we have the following open issues: a. How do stitching nodes
> get identified? The mere fact that a FA-LSP exists between SN1 and
> another node cannot be used as an indication that the latter can be
> used as a stitching node.

one assigns a specific SC for the inherited FA link, this can be couple
to the discovery of this capability beforehand through advertisement of
the stitching node interface capability

> view. It is not clear to me how non FA-LSPs could be used as tunnel 

the questions turns out to be if i have a set of FA-LSPs and a set of
tunnels LSPs, the former being advertized as FA links but not the latter
how does the global mechanism work ?

the response is be setting up a routing adjacency on top of the tunnels 
LSPs that can not be advertized as FA LSPs

so, on one side, advertize these LSPs as simple IP/MPLS links so that 
the non-FA capable nodes see these links (also i assume here that a FA 
capable node is also "non-FA" capable)

and on the other side, for non-FA capable nodes to see established FA 
LSPs, mandate that FA link advertisement are beforehand translated into 
common IP/MPLS link advertisement

note: as we're at the bottom of the stack here there is also no level issue

> Regards, Mustapha. ----------- "Busschbach, Peter B (Peter)" wrote:
> 
>> Every LSR *can* be a PW stitching node. It is not an assumption. It
>> is a simple observation based on the recognition that a MH-PW is
>> really nothing more than an LSP.
>> 
>> That does not mean that every LSR *should* be used as a stitching
>> node. That would eventually not result in a scaleable solution.
>> Operators will use Transport LSPs to aggregate PWs. They will
>> identify specific nodes that will function as stitching nodes and
>> they will set policies that prompt those nodes to establish the
>> segments of a MH-PW through the Transport LSPs.
>> 
>> You write: "I need to use a policy to decide how a stitching node
>> should move a PW from one tunnel LSP to another one. I do not need
>> a routable PW label to perform a local forwarding operation in a
>> few stiching nodes."
>> 
>> By saying that there are only a few nodes, you imply that there is
>> no need for a true routing solution. I disagree. The question is:
>> when the first stitching node receives a PW setup request from a
>> PE, how does it know what the next hop on the path is? Or, in your
>> words, the PW has to be moved to the next tunnel, but which tunnel?
>> You say: there are policies. What kind of policies? Are you
>> suggesting that the operator manually provisions a routing table?
>> Something like: for AGI=X and AII=Y, the next hop is Z?
>> 
>> I thought that the email exchange between Richard Spencer and Du Ke
>> illustrated this problem very well and after a few emails up and
>> down, Du Ke acknowledged that there is a need for some topology
>> discovery mechanism.
>> 
>> My contention is: we already have a topology discovery mechanism.
>> If you identify a MH-PW with the IP addresses of its ingress and
>> egress PE and you use the principles of
>> draft-ietf-mpls-lsp-hierarchy-08.txt, you have a solution.
>> 
>> Peter
>> 
>> 
>>> -----Original Message----- From: Mustapha Aissaoui
>>> [mailto:[email-masked]] Sent: Tuesday, July 27,
>>> 2004 3:26 PM To: Busschbach, Peter B (Peter) Cc:
>>> [email-masked]'; [email-masked]; [email-masked]; 
>>> [email-masked]' Subject: Re: [PWE3] Scaling hierarchical
>>> LDP/PW stitching
>>> 
>>> 
>>> Peter, I added a few comments below.
>>> 
>>> Regards, Mustapha. --------- "Busschbach, Peter B (Peter)" wrote:
>>> 
>>> 
>>>> Hi Mustapha,
>>>> 
>>> understand the requirements before we decide which solution is
>>> best suited. However, IMO your email  obscures some important
>>> issues.
>>> 
>>>> Peter
>>>> 
>>>> 
>>>>> -----Original Message----- From: Mustapha Aissaoui
>>>>> [mailto:[email-masked]] Sent: Monday, July 26,
>>>>> 2004 5:20 PM To: Busschbach, Peter B (Peter) Cc:
>>>>> [email-masked]'; [email-masked]; [email-masked]; 
>>>>> [email-masked]; [email-masked]' Subject: Re: [PWE3]
>>>>> Scaling hierarchical LDP/PW stitching
>>>>> 
>>>>> 
>>>>> Peter, in networks where end-to-end traffic engineering of
>>>>> PWs
>>> 
>>> is required,
>>> 
>>> emails is that >every LSR _can_ function as a stitching node. A
>>> MH-PW is nothing more >than a pt-to-pt LSP between two PEs and
>>> the stitching points are nothing >more than LSRs that switch PW
>>> labels.
>>> 
>>> MA> If every LSR could function as a stitching node, which
>>> implies that it would keep state for each PW and know how to
>>> forward it, why bother carrying PWs over a tunnel LSP? The
>>> reachability information required by the PW will be exactly the
>>> same as that of the tunnel LSP. In my view, we cannot start with
>>> the assumption that every node could be a stichting node as this
>>> has the consequence of degenerating into an all PW routable
>>> network.
>>> 
>>> 
>>> sense if you >need to do traffic engineering. RSVP-TE makes sense
>>> anyway. The fact that >it can be used for traffic engineering is
>>> an added benefit.
>>> 
>>> MA> I said RSVP-TE made sense in this case. I do not think it is
>>> the only case. Have you thought of other cases?
>>> 
>>> 
>>>>> However, in many cases this will not be a requirement. There
>>>>> will be a few stiching nodes which are known a priori.
>>>> 
>>> MA> My starting point is different from yours. I am looking into
>>> a network where most of the label switching is performed at the
>>> tunnel LSP level and where a few nodes act as stitching points.
>>> So the forwarding information is mostly based on the tunnel LSP
>>> routing information. I need to use a policy to decide how a
>>> stitching node should move a PW from one tunnel LSP to another
>>> one. I do not need a routable PW label to perform a local
>>> forwarding operation in a few stiching nodes.
>>> 
>>> 
>>> (therefore?) we can get away >with simple solutions. As far as I
>>> can see, every solution that uses a >hierarchy of LSPs requires
>>> certain a-priori policies.  But that is not >the point. The crux
>>> of the discussion between Du Ke and Richard Spencer >was that you
>>> need to have mechanisms to find an end-to-end path between >two
>>> PEs. Therefore, even if a PE would have the choice between only
>>> two >stitching nodes, it needs to select one of the two. And if
>>> the primary >selection fails, it has to be able to switch over to
>>> the secondary node.
>>> 
>>> load-balancing is allowed over both links. This node does not
>>> need to participate in the exchange of reachability information
>>> with the rest of the network.
>>> 
>>> 
>>> failures, but it >assumes that the operator assigns an absolute
>>> priority to the stitching >nodes. That would nto work well if the
>>> operator is interested in load >balancing.
>>> 
>>> MA> I am not sure why this should not work for load balancing.
>>> How is this different from a node which performs load-balancing
>>> over dual-homed links? Unless you are thinking of load balancing
>>> PWs end-to-end over a set of tunnel LSPs. In this case you want
>>> to traffic engineer your PWs.
>>> 
>>> 
>>> which these issues have >already been investigated and solved?
>>> And not only that. It already has >solutions for traffic
>>> engineering, fast reroute and graceful restart as >well.
>>> 
>>> MA> Again, you can take advantage of all this but you really did
>>> not need the tunnel LSPs and just let the PWs be routable across
>>> the network.
>>> 
>>> 
>>>>>  engineered inside their own domain. The stitching nodes will
>>>>> be a few ASBRs.
>>>> 
>>> inter-provider scenarios) as a special case and I can see that we
>>> adopt a different solution for inter-AS cases than for intra-AS
>>> cases.
>>> 
>>> I would just be careful in making general statement based on an
>>> inter-AS example. It can easily lead you in the wrong direction.
>>> 
>>>>> Thus, having a solution based on Targeted LDP which removes
>>>>> pre-configuration at the stitching node is desirable. One 
>>>>> draft-yudong-pwe3-control-protocol-ext-00.txt where the
>>>>> boundary routers act as the stitching nodes.
>>>>> 
>>>>> Regards, Mustapha. -----------
>>>>> 
>>>> 
>>>> [snipped]
>>> 
>> _______________________________________________ pwe3 mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 
> 
> .
>