Subject: Fwd: I-D ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt

From: [email-masked]
Date: Thu, 15 Jul 2004 14:11:30 +0800

This draft leads reflector concept, which comes from BGP, into PWE3 control
protocol. We want to weaken the request of full mesh LDP session between
PEs.

We ask for advise.

Thanks.

Du Ke

Add:   No.68 Zijinghua Rd,Yuhuatai District,
       Nanjing. P.R.China.
Zip:   210012
Tel:   0086-25-52871809
Fax:   0086-25-52871000
E-Mail: [email-masked]

----- 转发人 都珂111059/user/zte_ltd 时间 2004-07-15 13:49 -----
                                                                                                            
                      Internet-Drafts@ie                                                                    
                      tf.org                    收件人：  [email-masked]                             
                      发件人：                  抄送：                                                      
                      i-d-announce-bounc        主题：    I-D                                               
                      [email-masked]                ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt       

                      2004-07-15 03:33                                                                      
                      请答复 给                                                                             
                      internet-drafts                                                                       

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

             Title                         : Scalable VPWS Network
             Author(s)         : C. Yudong, et al.
             Filename          :
draft-yudong-pwe3-control-protocol-ext-00.txt
             Pages                         : 15
             Date                    : 2004-7-14

In the pwe3 framework, PW is provided between the egree nodes. In
    this case, full-mesh PSN tunnel and signaling session connections
    must be established between pwe3 PEs, which leads to the issue of
    scalability, especially the difficulty of cross-AS PW services.
    This document provides a reflector-based VPWS network framework,
    and presents a solution that provides cross-AS pwe3.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yudong-pwe3-control-protocol-ext-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
             "get draft-yudong-pwe3-control-protocol-ext-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
             [email-masked].
In the body type:
             "FILE
/internet-drafts/draft-yudong-pwe3-control-protocol-ext-00.txt".

NOTE:        The mail server at ietf.org can return the document in
             MIME-encoded form by using the "mpack" utility.  To use this
             feature, insert the command "ENCODING mime" before the "FILE"
             command.  To decode the response(s), you will need "munpack"
or
             a MIME-compliant mail reader.  Different MIME-compliant mail
readers
             exhibit different behavior, especially when dealing with
             "multipart" MIME messages (i.e. documents which have been
split
             up into multiple messages), so check your local documentation
on
             how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[email-masked]/internet-drafts/draft-yudong-pwe3-control-protocol-ext-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: [email-masked]
Date: Fri, 16 Jul 2004 00:47:41 +0100

Du Ke,

As I understand it, your proposal addresses two different issues.

1) Reduce the number of LDP sessions in the core

Reading through the draft, at first glance the proposal for "Simple Trunk Mode" appears to offer a feasible method for reducing the number of LDP sessions in the core. In this approach PEs only need establish targeted LDP sessions with "LDP reflectors". The LDP reflectors act as relays and forward label messages received from source PEs onto remote/target PEs, similar to the way in which BGP route reflectors forward NLRIs onto clients. For this proposal to work the main change required is the adding of extra fields to the LDP label message to identify the source and destination PEs. Obviously for routers to be used as LDP reflectors they would need to be modified so that they can inspect the remote/target PE field in LDP messages and forward them on accordingly. LDP reflectors would also need to be able to generate and forward LDP error/notification messages onto effected PEs when targeted LDP sessions go down.

I think the concept of using LDP reflectors in the same way that BGP route reflectors are used to improve scalability is an attractive proposition to service providers. As well as reducing the number of targeted LDP sessions required in the core, it also means that the targeted LDP control traffic could be taken out-of-band, i.e. PW control packets do not need to follow the same path as PW data packets. One can envisage a converged IP/MPLS network with centralised LDP and BGP reflectors, where targeted LDP and BGP control traffic could be carried using a separate control/management overlay network with high availability/reliability. Of course forwarding in the data plane would still be dependent on inband LDP/RSVP-TE/IGP control.

2.) Extend LDP signalling to support PW stitching

The "next hop self" mode describes a method for setting up and stitching together multiple PWs end-to-end between two endpoints. At first pass, adding a next hop TLV to provide the ability to set up multiple PWs across intermediate routers between endpoints seems viable. However, I have some concerns regarding the priority/pref TLV. Section 6 states:

"When the target PE of the PW label mapping receives the PW label message from the reflector or the downstream PEs, it can select the best egress labels according to the priority or the default priority carried in the label mapping message, or can adopt a certain load equalization strategy to perform load sharing of the L2 PDU received from the L2 VPN on different PWs."

For VPWS there is a 1-to-1 mapping between an AI and a forwarder/PW. For stitched PWs there is a 1-to-1 mapping between an ingress PW and an egress PW. Therefore, only one label should be received from a remote PE (or intermediate router for stitched PWs) for any given VPWS. I cannot think of an application for which setting up multiple PWs between VPWS forwarders would be required/beneficial. Multihomed MTU-s devices for hierarchical VPLS use two PWs (one active, one backup), but they connect to different PE-rs devices and therefore PE-rs devices only receive one label from a MTU-s for any given forwarder (VSI in this case).

If it is agreed that PEs should not receive multiple labels from a PE for any given VPWS, then there is no need for the pref/priority TLV and loops that might have been caused by having multiple PWs will be avoided.

Looking at section 7, which describes the intra-AS operation of the proposed method for signalling stitched PWs, I think this section needs further clarification. I find it difficult to understand but from what I can make out it describes two intra-AS PW stitching methods from a data plane perspective. These two methods appear to be the same except one method uses a PSN tunnel between the ASBRs whereas the other one doesn't. Perhaps some diagrams would provide some clarification, although I think it would also be useful to describe what happens in the control plane.

As a general comment, the draft uses the term "LDP reflector" to describe routers that reflect/relay LDP messages (referred to as simple trunk mode), and to describe routers that act as intermediate nodes for stitched PWs (referred to as next hop self mode). A router that is only used for the latter is not performing LDP message reflecting/relaying and therefore I do not think it should be called a LDP reflector. One can imagine that LDP route reflectors could be dedicated devices (not necessarily routers) that are used just for reflecting/relaying LDP messages. One can also imagine that to support PW stitching it would be necessary to make PE-rs devices in a hierarchical VPWS/VPLS network "PW stitching & signalling" capable. The point being that a device may support PW stitching/signalling but may not support (or be used for) LDP message reflecting.

Regards,
Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of [email-masked]
> Sent: 15 July 2004 07:12
> To: [email-masked]
> Subject: [PWE3] Fwd: I-D 
> ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt
> 
> 
>                       [email-masked]                
> ACTION:draft-yudong-pwe3-control-protocol-ext-00.txt       
>                                                               
>                                               
>                                                               
>                                               
>                       2004-07-15 03:33                        
>                                               
>                       请答复 给                                   
>                                           
>                       internet-drafts                         
>                                               
>                                                               
>                                               
>                                                               
>                                               
> 
> 
> 
> 

Send a message to:
             [email-masked].
In the body type:
             "FILE

---

From: [email-masked]
Date: Fri, 16 Jul 2004 13:46:51 +0800

Thank Richard very much.

You are right,
1) The term "LDP reflector" isn't appropriate to describe routers that act
as intermediate nodes for stitched PWs. Perhaps we can call it "reflector"
or "PW reflector".

2) Section 7, which describes the intra-AS operation of the proposed method
for signalling stitched PWs, needs further clarification.

"These two methods appear to be the same except one method uses a PSN
tunnel between the ASBRs whereas the other one doesn't."

It's true. But when use MPLS tunnel as the PSN tunnel, the MPLS PSN tunnel
between the ASBRs may degrade, and the upstream ASBR can use PW label
transmit payload to the downstream ASBR without a "PSN tunnel label", It
seemed that no inter-AS PSN tunnel is needed.

I see, we'd better combine the "two methods",  and discribe "the tiny
difference" as special case.

3)I'm agree with you that an application for which setting up multiple PWs
between VPWS forwarders would be not required/beneficial.

Maybe, we should not mention "load-balance".

the purpose of "priority/pref TLV" is to solve the problem issued by
multiple reflectors.

When the network has multiple reflectors, PE may receive multiple PW label
mappings. If one or more reflectors adopt the "nexthop self" mode, the
nexthop values of the mapping messages received by the PE are different.

                  R2
                  /     \
              PE1         PE2
                  \     /
                     R1
for example, source PE2 send mapping to reflectors R1 and R2, It's assumed
that both R1 and R2 send mapping to target PE1 simultaneously, R1 says
nexthop itself, and so does R2, then PE1 will receive two differet mapping
of the PW in discussing, it can select a best out label according to the
priority, the PW(in one direction) will be PE1->R1->PE2 or PE1->R2->PE2.

We will study the feasibility of load-balance between PE1->R1->PE2 and
PE1->R2->PE2 more deeply. It make things more complex, and make the network
more difficultly to be controlled.

Regards,
Du Ke

> Behalf Of [email-masked]
> Sent: 16 July 2004 07:47
> To: [email-masked]
> Subject: RE: [PWE3] Fwd: I-D

Du Ke,

Reading through the draft, at first glance the proposal for "Simple Trunk
Mode" appears to offer a feasible method for reducing the number of LDP
sessions in the core. In this approach PEs only need establish targeted LDP
sessions with "LDP reflectors". The LDP reflectors act as relays and
forward label messages received from source PEs onto remote/target PEs,
similar to the way in which BGP route reflectors forward NLRIs onto
clients. For this proposal to work the main change required is the adding
of extra fields to the LDP label message to identify the source and
destination PEs. Obviously for routers to be used as LDP reflectors they
would need to be modified so that they can inspect the remote/target PE
field in LDP messages and forward them on accordingly. LDP reflectors would
also need to be able to generate and forward LDP error/notification
messages onto effected PEs when targeted LDP sessions go down.

I think the concept of using LDP reflectors in the same way that BGP route
reflectors are used to improve scalability is an attractive proposition to
service providers. As well as reducing the number of targeted LDP sessions
required in the core, it also means that the targeted LDP control traffic
could be taken out-of-band, i.e. PW control packets do not need to follow
the same path as PW data packets. One can envisage a converged IP/MPLS
network with centralised LDP and BGP reflectors, where targeted LDP and BGP
control traffic could be carried using a separate control/management
overlay network with high availability/reliability. Of course forwarding in
the data plane would still be dependent on inband LDP/RSVP-TE/IGP control.

The "next hop self" mode describes a method for setting up and stitching
together multiple PWs end-to-end between two endpoints. At first pass,
adding a next hop TLV to provide the ability to set up multiple PWs across
intermediate routers between endpoints seems viable. However, I have some
concerns regarding the priority/pref TLV. Section 6 states:

"When the target PE of the PW label mapping receives the PW label message
from the reflector or the downstream PEs, it can select the best egress
labels according to the priority or the default priority carried in the
label mapping message, or can adopt a certain load equalization strategy to
perform load sharing of the L2 PDU received from the L2 VPN on different
PWs."

For VPWS there is a 1-to-1 mapping between an AI and a forwarder/PW. For
stitched PWs there is a 1-to-1 mapping between an ingress PW and an egress
PW. Therefore, only one label should be received from a remote PE (or
intermediate router for stitched PWs) for any given VPWS. I cannot think of
an application for which setting up multiple PWs between VPWS forwarders
would be required/beneficial. Multihomed MTU-s devices for hierarchical
VPLS use two PWs (one active, one backup), but they connect to different
PE-rs devices and therefore PE-rs devices only receive one label from a
MTU-s for any given forwarder (VSI in this case).

If it is agreed that PEs should not receive multiple labels from a PE for
any given VPWS, then there is no need for the pref/priority TLV and loops
that might have been caused by having multiple PWs will be avoided.

Looking at section 7, which describes the intra-AS operation of the
proposed method for signalling stitched PWs, I think this section needs
further clarification. I find it difficult to understand but from what I
can make out it describes two intra-AS PW stitching methods from a data
plane perspective. These two methods appear to be the same except one
method uses a PSN tunnel between the ASBRs whereas the other one doesn't.
Perhaps some diagrams would provide some clarification, although I think it
would also be useful to describe what happens in the control plane.

As a general comment, the draft uses the term "LDP reflector" to describe
routers that reflect/relay LDP messages (referred to as simple trunk mode),
and to describe routers that act as intermediate nodes for stitched PWs
(referred to as next hop self mode). A router that is only used for the
latter is not performing LDP message reflecting/relaying and therefore I do
not think it should be called a LDP reflector. One can imagine that LDP
route reflectors could be dedicated devices (not necessarily routers) that
are used just for reflecting/relaying LDP messages. One can also imagine
that to support PW stitching it would be necessary to make PE-rs devices in
a hierarchical VPWS/VPLS network "PW stitching & signalling" capable. The
point being that a device may support PW stitching/signalling but may not
support (or be used for) LDP message reflecting.

Regards,
Richard

---

From: [email-masked]
Date: Fri, 16 Jul 2004 14:55:42 +0100

Du Ke,

> nexthop values of the mapping messages received by the PE are 

A practical example for using routers in next hop self mode would be for establishing a VPWS path between two LDP spoke sites across a core. Spoke sites do not have targeted LDP sessions with each other, they only have a targeted session with the PE that they attach to. The diagram below shows a network with three PE-rs devices connected in a full mesh, each with a single spoke MTUs device hanging off it. 

            |------PErs3-----MTUs3
            |         |
            |         |
MTUs1----PErs1-----PErs2-----MTUs2

To establish a VPWS from MTUs1 to MTUs2 three PWs must be stitched together to form the end-to-end VPWS, i.e. PW1 between MTU-s1 and PE-rs1, PW2 between PE-rs1 and PE-rs2, and PW3 between PE-rs2 and MTU-s1.

If standard LDP signalling is used, MTUs1 and PErs1 exchange targeted LDP label messages to establish PW1, PErs1 and PErs2 exchange targeted LDP label messages to establish PW2, and PErs2 and MTUs2 exchange targeted LDP label messages to establish PW3. In this approach PW1, PW2 and PW3 are set up independently using single or double sided provisioning for each. The three separate PWs must then be associated with each other and stitched together at midpoints (PErs1 and PErs2) either by manual configuration or by NMS.

The difference between this and your proposal is that your proposal defines a method for setting up PW1, PW2, and PW3 dynamically without having to configure the PW midpoints, and using single sided provisioning only one endpoint (MTUs1/MTUs2) needs to be configured.

However, having thought about your proposal further I don't think it offers a scalable solution. To set up the 3 PWs in the above example for a VPWS between MTUs1 and MTUs2 using your proposal would require the following:

1. First, all PErs devices must support PW stitching/signalling (i.e. next hop self mode).
2. MTUs1 is configured with or discovers the IP address of MTUs2.
3. MTUs1 sends a label message with MTUs2 as the target/remote IP address to PErs1 (as it only has a targeted LDP session with PErs1).
4. PErs1 receives the label message, and allocates a label to reach its own IP address.
5. PErs1 checks the remote/target IP address and determines that it doesn't have a targeted LDP session with MTUs2. As it does not know which (if any) PErs device does have a targeted LDP session with MTUs2, the only option is for PErs1 to forward the label message (modified with a PW label to reach its own IP address) onto PErs2 and PErs3. Note: split horizon should be enforced to ensure that PErs devices do not forward label messages received from PErs devices onto other PE-rs devices.
6. PErs3 does not have a targeted LDP session with MTUs2 and although the draft doesn't specify what happens in this case, I assume that PErs3 looks at the remote/target IP address, determines that it doesn't have a targeted session with MTUs2 and either i) sends a label release message back to PErs1, or ii) allocates a label to reach its own IP address and forwards the label message onto MTUs3, which in turn sends a label release message back to PErs3 as it is not the target/remote PE and does not have any other LDP peers to send the label message to.
7. PErs2 does have a targeted LDP session with MTUs2 and therefore allocates a label to reach its own IP address and forwards the label message onto MTUs2.
8. To establish bi-directional connectivity the same then needs to occur in the opposite direction

The problem with this approach is that every time a stitched PW path needs to be set up across the core, PErs devices need to forward label messages received from connected MTUs devices onto every PErs peer in the full mesh, and in turn, all receiving PErs and MTUs devices that do not form the switched PW path must send label release messages back to the originating PErs. So for a full mesh LDP core with say 500 PErs devices, a PErs needs to allocate and send out 499 labels, 498 of which are not needed and will result in receiving 498 label withdraw messages.

Regarding a PE receiving multiple labels, the only application I can think of for this is a dual homed MTUs device for a VPLS. Referring back to the previous example, if MTUs2 was dual homed to PErs2 and PErs3, then it would receive label messages from PErs2 and PErs3 for the same VPLS instance. Rather than perform load balancing across the two PWs, one PW would become active and the other would be used as a backup (which avoids looping problems). However, this scenario is not applicable to VPWS. For a PErs device providing a VPWS there is a 1-to-1 mapping between a MTUs facing PW and a PErs facing PW, but for a PErs device providing a VPLS service there is a one-to many relationship between a MTUs facing PW and PErs facing PWs. The point being that a PErs forwarder (VSI) for a VPLS service is capable of switching/forwarding traffic across multiple PWs, whereas as a VPWS forwarder is only capable of forwarding traffic across one PW, i.e. a VPWS forwarder does not have the capability to switch traffic from an active PW to a backup PW. 

> nexthop itself, and so does R2, then PE1 will receive two 
> different mapping

I cannot think of any practical examples where the above example makes sense. Why don't the PE routers have a targeted LDP session between them? What is the reason/benefit for establishing a stitched PW path between PE1 and PE2 via R1 or R2 rather than establishing a targeted LDP session between PE1 and PE2 using a single PW? Stitching PWs is only required where there isn't a full mesh of LDP sessions, i.e. for setting up VPWS/VPLS between spoke sites across the core. 

Regards,
Richard

---

From: [email-masked]
Date: Sat, 17 Jul 2004 15:01:48 +0800

Richard,

In this draft, there are two type of devices, one is PE, the other is
reflector.
The reflector have the capability to reflect/relay LDP messages and/or act
as intermediate nodes for stitched PWs.

While compared with standard PE, The PE in this draft should be able to
cooperate with reflector, i.e, PE should be able to send/receive PW label
message with extended GID FEC element described in this draft, and
recognise reflector from all target peers by "negotiation of capability",
and we ask PE should send mapping to target PE and all reflector-neighbor
initiatively.

Reflector can recognise reflector-neighbor by "negotiation of capability"
too. We ask reflector send mapping to target PE(only PE-neighbor that is
target of PW mapping) and all reflector-neighbor(include the one which send
mapping to it if the mapping is sent from a reflector) after it receive a
mapping.

that is, mapping flood among source PE, reflector(s), and target PE. In the
schedule, no mapping release intervene.

In network example followed:

            |------PErs3-----MTUs3
            |         |
            |         |

I think that MTUs1/MTUs2/MTUs3 are Provider Edges(PEs), and
PErs1/PErs2/PErs3 are intermediate nodes for stitched PWs, i.e, reflector.

Before all, by negotiation of capability, they all learn capability of each
other.

To set up the 3 PWs in the above example for a VPWS between MTUs1 and MTUs2
would require the following:
1. First, all PErs devices must support PW stitching/signalling (i.e. next
hop self mode).//Yes, they are reflector.

2. MTUs1(PE device) sends mapping to PErs1(reflector-neighbor).

3. While the target of PW mapping is not PErs1 itself, PErs1 send the
mapping message to PErs2 and PErs3(all reflector-neighbors) with PW label
modified and a nexthop tlv added.

4. PErs3 send mapping to PErs2 & PErs1(maybe, if path vector loop detection
is adopted, PErs3 can know not to send mapping to PErs1). Because MTUs3
isn't the target of mapping message, PErs3 doesn't send mapping to it.

5. PErs2 send mapping to MTUs2(PE), because it is the target of mapping
message on the beam.

6. PErs1 knows to use label from MTUs1 as out label of PW, but PEr2 must
choose a label from which are sent from PEr1 and PEr3, so we design an
priority machine. maybe path vector tlv or hop count tlv can solve the
problem too.

In the flooding process, MTUs1 and MTUs2 need maintain the status of PW,
but MTUs3 needn't, because MTUs3 have no business with the PW.

But all reflector must maintain the status of PW, i.e, adopt the Liberal
Label Retention Mode to keep the PW label. no release should be sent,
except any policy is configurated.

Of cause, it maybe a problem for reflector to maintain too many status of
PWs. Some policy must be inducted. for example, maybe PErs1 knows that
MTUs2 is behind of PErs2(similarly to MSDP, Peer-RPF Forwarding technology
is used, but the derection is reverse), it can send mapping whose target
peer is MTUs2 to PErs2 only.

Instead of "split horizon", we consider that the "Loop Detection
Mechine(see RFC 3036)" of LDP is much better. both "Hop Count" and "Path
Vector"  seem to do work, especially "Path Vector".

Regarding a PE receiving multiple labels, the application I think of for
this is following.

               reflector-1         reflector-2(backup)
               |      \    \       /  /       |
               |       \       \/   /         |
               |        \  /     /\           |
               |        /\     /     \        |
               |    /     \  /           \    |
               PE1         PE2     ......    PEn

PE1, PE2,..., and PEn (up to 20 or more PEs)all have target sessions with
reflection-1 and reflection-2, while reflector-2 is a backup. and PE1,
PE2,..., PEn need no target session with each other.

Regards,
Du Ke

> Sent: 2004-07-16 21:55

Du Ke,

> nexthop values of the mapping messages received by the PE are

A practical example for using routers in next hop self mode would be for
establishing a VPWS path between two LDP spoke sites across a core. Spoke
sites do not have targeted LDP sessions with each other, they only have a
targeted session with the PE that they attach to. The diagram below shows a
network with three PE-rs devices connected in a full mesh, each with a
single spoke MTUs device hanging off it.

            |------PErs3-----MTUs3
            |         |
            |         |

To establish a VPWS from MTUs1 to MTUs2 three PWs must be stitched together
to form the end-to-end VPWS, i.e. PW1 between MTU-s1 and PE-rs1, PW2
between PE-rs1 and PE-rs2, and PW3 between PE-rs2 and MTU-s1.

If standard LDP signalling is used, MTUs1 and PErs1 exchange targeted LDP
label messages to establish PW1, PErs1 and PErs2 exchange targeted LDP
label messages to establish PW2, and PErs2 and MTUs2 exchange targeted LDP
label messages to establish PW3. In this approach PW1, PW2 and PW3 are set
up independently using single or double sided provisioning for each. The
three separate PWs must then be associated with each other and stitched
together at midpoints (PErs1 and PErs2) either by manual configuration or
by NMS.

The difference between this and your proposal is that your proposal defines
a method for setting up PW1, PW2, and PW3 dynamically without having to
configure the PW midpoints, and using single sided provisioning only one
endpoint (MTUs1/MTUs2) needs to be configured.

However, having thought about your proposal further I don't think it offers
a scalable solution. To set up the 3 PWs in the above example for a VPWS
between MTUs1 and MTUs2 using your proposal would require the following:

1. First, all PErs devices must support PW stitching/signalling (i.e. next
hop self mode).
2. MTUs1 is configured with or discovers the IP address of MTUs2.
3. MTUs1 sends a label message with MTUs2 as the target/remote IP address
to PErs1 (as it only has a targeted LDP session with PErs1).
4. PErs1 receives the label message, and allocates a label to reach its own
IP address.
5. PErs1 checks the remote/target IP address and determines that it doesn't
have a targeted LDP session with MTUs2. As it does not know which (if any)
PErs device does have a targeted LDP session with MTUs2, the only option is
for PErs1 to forward the label message (modified with a PW label to reach
its own IP address) onto PErs2 and PErs3. Note: split horizon should be
enforced to ensure that PErs devices do not forward label messages received
from PErs devices onto other PE-rs devices.
6. PErs3 does not have a targeted LDP session with MTUs2 and although the
draft doesn't specify what happens in this case, I assume that PErs3 looks
at the remote/target IP address, determines that it doesn't have a targeted
session with MTUs2 and either i) sends a label release message back to
PErs1, or ii) allocates a label to reach its own IP address and forwards
the label message onto MTUs3, which in turn sends a label release message
back to PErs3 as it is not the target/remote PE and does not have any other
LDP peers to send the label message to.
7. PErs2 does have a targeted LDP session with MTUs2 and therefore
allocates a label to reach its own IP address and forwards the label
message onto MTUs2.
8. To establish bi-directional connectivity the same then needs to occur in
the opposite direction

The problem with this approach is that every time a stitched PW path needs
to be set up across the core, PErs devices need to forward label messages
received from connected MTUs devices onto every PErs peer in the full mesh,
and in turn, all receiving PErs and MTUs devices that do not form the
switched PW path must send label release messages back to the originating
PErs. So for a full mesh LDP core with say 500 PErs devices, a PErs needs
to allocate and send out 499 labels, 498 of which are not needed and will
result in receiving 498 label withdraw messages.

Regarding a PE receiving multiple labels, the only application I can think
of for this is a dual homed MTUs device for a VPLS. Referring back to the
previous example, if MTUs2 was dual homed to PErs2 and PErs3, then it would
receive label messages from PErs2 and PErs3 for the same VPLS instance.
Rather than perform load balancing across the two PWs, one PW would become
active and the other would be used as a backup (which avoids looping
problems). However, this scenario is not applicable to VPWS. For a PErs
device providing a VPWS there is a 1-to-1 mapping between a MTUs facing PW
and a PErs facing PW, but for a PErs device providing a VPLS service there
is a one-to many relationship between a MTUs facing PW and PErs facing PWs.
The point being that a PErs forwarder (VSI) for a VPLS service is capable
of switching/forwarding traffic across multiple PWs, whereas as a VPWS
forwarder is only capable of forwarding traffic across one PW, i.e. a VPWS
forwarder does not have the capability to switch traffic from an active PW
to a backup PW.

> priority, the PW(in one direction) will be PE1->R1->PE2 or

I cannot think of any practical examples where the above example makes
sense. Why don't the PE routers have a targeted LDP session between them?
What is the reason/benefit for establishing a stitched PW path between PE1
and PE2 via R1 or R2 rather than establishing a targeted LDP session
between PE1 and PE2 using a single PW? Stitching PWs is only required where
there isn't a full mesh of LDP sessions, i.e. for setting up VPWS/VPLS
between spoke sites across the core.

Regards,
Richard

---

From: [email-masked]
Date: Wed, 21 Jul 2004 00:13:24 +0100

Du Ke,

Scaling LDP signalling to potentially tens of thousands of PEs is a problem that as yet (as far as I am aware) there is no complete solution for. Using a hierarchical model improves scalability significantly but introduces the issue of how to signal and stitch together large numbers of PWs. The problem stems from the fact that stitching together multiple PWs is effectively creating a new layer network. LDP has been proposed for signalling the individual PWs that form a stitched PW path, but the fundamental routing element required to calculate and select the best path across multiple hops is missing. In practical terms this means that PWs can be signalled individually, but not end-to-end from one side of the stitched PW path.

If a provider has a full mesh of tunnels between PEs then PW stitching is not needed. Using LDP reflectors in 'simple trunk' mode could be used here to reduce the number of LDP sessions in the core. However, using 'next hop self' mode in an existing full mesh does not make sense as it will result in sub-optimal routing and uneven network loading, i.e. the optimal route for any given PE-PE path is the PE-PE tunnel, the path for which has been calculated via a dynamic routing protocol (e.g. OSPF) or via OSS.

I think it would only make sense to use 'next hop self' mode when a provider does not have a full mesh of tunnels between PEs. The problem with your proposed 'next hop self' mode solution is that it does not scale if large numbers of reflectors are required and is highly inefficient, even for relatively low numbers of reflectors. This is because it relies on a reflector sending a label to every other reflector it's connected to, for every label mapping message it receives from a PE. No learning takes place (as there is no routing) and therefore LDP messages are effectively always broadcast to all reflector peers and never unicast.

Increasing the number or reflectors in the previous example by 1, and connecting them together in a full mesh illustrates this best:

MTUs4----PErs4--PErs3-----MTUs3
           |  \ /  |
           |   X   |
           |  / \  |
MTUs1----PErs1--PErs2-----MTUs2

To establish a stitched PW path between MTUs1 and MTUs2 would involve the following (if vector loop detection is used as you suggest):

1. MTUs1(PE device) sends a label mapping to PErs1(reflector-neighbor). [1 label message sent]

2. PErs1 sends a mapping message to PErs2, PErs3, and PErs4 (all reflector-neighbors) with the PW label modified and a nexthop tlv added.
[4 label messages sent]

Now lets just follow the ordered label distribution that occurs after PErs3 receives a label mapping message from PErs1...

3. PErs3 sends a mapping message to PErs2 and PErs4 (not to PErs1 as vector loop detection is used).
[6 label messages sent]

4. PErs2 sends a label mapping message to MTUs2(PE) as it is the target. [7 label messages sent]

5. PErs4 sends a label mapping message to PErs2 (not to PErs1 or PE rs3 as vector loop detection is used). [8 label messages sent]

6. PErs2 sends a label mapping message to MTUs2(PE) as it is the target. [9 label messages sent]

At this point there are two stitched PW paths that have been signalled between MTUs1 and MTUs2:

PW path 1: MTUs1 -> PErs1 -> PErs3 -> PErs2 -> MTUs2
PW path 2: MTUs1 -> PErs1 -> PErs3 -> PErs4 -> PErs2 -> MTUs2

The above just followed the ordered label distribution that occurred after PErs3 received a label mapping message from PErs1. The label message from PErs1 to PErs2 will result in another label message being sent [10 in total] and another PW path being signalled:

PW path 3: MTUs1 -> PErs1 -> PErs2 -> MTUs2

The label message from PErs1 to PErs4 will result in another 5 label messages being sent [15 in total] and two more PW paths being signalled:

PW path 4: MTUs1 -> PErs1 -> PErs4 -> PErs2 -> MTUs2
PW path 5: MTUs1 -> PErs1 -> PErs4 -> PErs3 -> PErs2 -> MTUs2

MTUs2 receives 5 different label messages belonging to 5 different stitched PW paths. As there is a 1-to-1 mapping between a VPWS forwarder and an outbound PW, somehow MTUs2 must decide which path to accept and send label release messages for the other four paths. You suggest using a next hop pref/priority TLV. This mechanism will not work for this scenario. The next hop for all 5 labels that MTUs2 receives will be the same (i.e. PErs2) and therefore will have the same next hop pref/priority. In addition, for cases where labels are received with different next hops (e.g. PErs2 will receive 5 labels with 3 different next hops), how can a provider allocate next hop/pref values for a router when the values need to be destination/topology dependant, i.e. the best next hop for a particular destination is not necessarily the best next hop for another destination. This takes us back to the root of the problem, i.e. LDP is being used for signalling but there is no routing protocol/functionality. Routing selects the best path based on some metric(s) via advertisement of route information. One way to add an element of routing to select the best path would be to use the hop count. However, this in itself does not make the solution scale as routing state information is not maintained and therefore route selection would need to take place every time a PW path needs to be set up (as opposed to once when the routing protocol is activated and then only when the topology changes). 

Now consider the above example but with say 400 PErs routers (LDP reflectors) in a full mesh. This is a realistic scenario for a large service provider with a full mesh of PErs routers each with multiple MTUs devices hanging off them. If 5 paths are signalled using 15 label mapping messages in a network with just 4 PErs devices, obviously the number of paths signalled and number of label mapping messages in a network with 400 PErs devices will too large to make this a viable solution, especially if liberal label retention is used.

The LDP hop count could be set to 3 to reduce the number of PW paths set up to 1. However, in a network of 400 PErs devices this would still result in 398 LDP messages being sent to PErs devices that are not connected to the target MTUs, and then another 397 LDP messages being sent by those PErs devices, for which receiving PErs devices must drop the label mapping messages and signal loop detected status to the source of the label mapping message. Obviously sending ~800 Label mapping messages and signalled loop detected messages to set up just 1 PW path between two MTUs devices obviously doesn't scale and isn't viable.

The proposal could be improved further by using split horizon, but again this still results in 398 LDP messages being sent to reflectors that are not attached to the MTUs and corresponding label withdraw messages being received just to set up 1 PW path between two MTUs devices.

I think that the 'simple trunk' mode of operation has the potential for aiding LDP scaling for existing full meshes, but I do not think the 'next hop self' mode is a viable solution to solve PW stitching signalling (at least in its current state) due to its inefficiency and the lack of scalability of its broadcast based operation. The next hop self mode may not be intended to address PW stitching in hierarchical LDP topologies, however, if not then I would like to understand better exactly what practical problems the next hop self mode addresses (bearing in mind that using next hop self in an existing full mesh introduces sub-optimal routing and uneven network loading). 

Regards,
Richard

> From: [email-masked] [mailto:[email-masked]]
> Sent: 17 July 2004 08:02
> To: Spencer,R,Richard,XGH5 R; [email-masked]

---

From: [email-masked]
Date: Thu, 22 Jul 2004 16:10:24 +0800

Richard

Excuse me, This mail is delayed too many time.
I need time to study your advice, I think I have got very big inspire from
your suggestion.

I'm agree with you, if we can find a way, in which source PE and reflector
can send only one PW mapping toward the direction to target PE, i.e, PErs1
can know to send PW mapping to PErs2, but not send to PErs3 & PErs4, then
the solution in dicussing will be more nice.

we will improve our draft on this problem.

Of cause, we can rely on OSS to get the next-hop-peer on the path to
destination PE(MTUs2), but we want find a dynamic machine.

As far as I am aware, many other protocol need (and work out) the way to
know the nexthop NE to a special IP destination, such as DVMRP, PIM,
RSVP-TE, and MSDP.

I am willing to design a machine similar to MSDP(see
http://www.ietf.org/rfc/rfc3618.txt) to find out peer to PW target peer.
we can define the rule:
PE and reflector send PW mapping only to peer if:
1) the peer is the target of PW mapping;
2) the peer is the eBGP NEXT_HOP to the target of PW mapping. (e.g., the
peer is the e-BGP advertiser of the route for the target of PW mapping)
3) the peer is the is the IGP next hop for the target of PW mapping.
4) the peer resides in the closest AS in the best path towards the target
of PW mapping.  If multiple LDP peers reside in the closest AS, the peer
with the highest IP address is the one that PW mapping should be sent.
5) the peer is configured as the static next-hop peer for the target of PW
mapping.

and, if no peer satisfies the request mentioned, the PW mapping should be
sent to all reflector-neighbor.

Regards,
Du Ke

---

From: [email-masked]
Date: Fri, 23 Jul 2004 14:10:00 +0100

Du Ke,

I welcome any thoughts/solutions on stitched/switched PW provisioning, but think you going in the wrong direction by looking at MSDP.

To get to the root of the problem I think its best to look at things from a high-level functional perspective. Layer networks used as server layers to support VPNs require two fundamental functional components: routing and signalling, e.g. OSPF routing and LDP signalling for MPLS, PNNI routing/signalling for ATM.  In addition, they also need to support multiplexing/de-multiplexing or tunnelling to separate one customers traffic from another, and to bind a multiplexing field/tunnel to a VPN instance a signalling/tunnelling protocol must be used. For example, L2 MPLS VPNs use PWs for multiplexing with targeted LDP or BGP signalling, ATM uses VPI/VCIs for multiplexing with PNNI signalling, and IP can use IPsec tunnelling. The routing and signalling functions in the examples above are performed by dynamic protocols, but equally they could be performed using manual methods or OSS. 

To ease provisioning, an auto-discovery function can be used to learn remote VPN endpoints, e.g. BGP or RADIUS discovery for MPLS VPNs, and in addition to routing in the server layer network, routing information can also be distributed for the VPN client layer, e.g. MP-BGP is used to distribute IP routing information for RFC2547 IP VPNs, and could also be used to distribute ATM address information for ATM VPNs.

PWs are one hop point-to-point flows that only exist between two endpoints (PEs). They are supported by a server layer via what is effectively a point-to-point link between two PEs (e.g. an MPLS LDP/RSVP-TE tunnel LSP) and therefore can PWs in this case can be thought of as an adaptation function, where the PW label just provides VPN traffic separation across a point-to-point link. 

Stitched/switched or multi-hop PWs (MH-PWs), as described in draft-martini-pwe3-pw-switching-00.txt, on the other hand contain multiple hops and do not just exist between two PEs. Using MH-PWs is effectively creating a new 'PW' layer network containing multiple 'PW aware' nodes with point-to-point links between them. As MH-PW contain multiple hops, and a path/route must be calculated between the ingress and egress PEs or ultimate PEs (U-PEs). The current draft describes how the individual single-hop PWs (SH-PWs) are established and stitched together at PW switching points(S-PEs), but this requires S-PEs to be manually configured and route/path calculation between U-PEs must be performed manually (or via OSS). The capability to provision MH-PWs using single sided provisioning from one U-PE, in the same way that SH-PWs can be provisioned from one PE would be the ideal solution from a provisioning perspective. The reason being that OSS (or manual methods) would not have to be used to configure intermediate routers (PW stitching points), and calculate/keep track of MH-PW paths.

MSDP will not address this issue as its purpose is to *discover* RPs using a flooding mechanism. It relies on a routing protocol to populate a multicast routing information base (MRIB) in order to determine what RPF-peer is the next hop to reach the originating RP. Discovery is already covered (e.g. BGP/LDP/RADIUS), its the routing function that is missing.

Regards,
Richard

> Sent: 22 July 2004 09:10