Subject: Re: One issue and its solution in PWE3 draft draft-ietf-pwe3-segmented-pw-00.txt

From: Luca Martini <[email-masked]>
Date: Tue, 01 Nov 2005 02:08:30 -0700

Huke Hu Chun,

Please note that this is a WG draft in PWE3, not L2VPN.
Looping of multi segment PWs which are statically configured , is not a
realistic problem. If somebody wants to *configure* a PW in a loop, I do
not see any reason why they should be prevented from doing so. This is
allowed on ATM VCs , and can also be achieved with ethernet vlans by
disabling spanning tree protocol.

The specified mode for PWE3 LDP protocol is liberal label retention,
hence a label request should not be normally used.
However you should note that the LDP messages are not just "forwarded"
across segments. If an intermediate router received a label request for
a specific PWE3 label mapping, and the previous segment is not setup ( (
( which means that it does not yet have a label allocated to answer the
request ), it simply will not answer nor forward the label request.
I do not see any looping of messages in this situation.

Luca

Huke Hu Chun Zhe wrote:
> *_ Dear All:       Plz Check following issue found in 
> draft-ietf-pwe3-segmented-pw-00.txt and solutions   we give below , Plz 
> give your valable comments on it . _*
> 
> *_Looping of Switch VCs_*
> 
> *_ _*
> 
>  
> 
> /_Problem Description:_/
> 
>  
> 
> Consider the case as shown in the figure where a loop of SPE [switch VC] 
> is configured. In this case when a switch VCs are configured in a loop, 
> we may end up in a situation where our request message are infinitely 
> looped.
> 
>  
> 
> In implementation where we opt to not store the unmatched remote mapping 
> information, we use the request message to get the information again 
> from the peers. Implementation that requires this feature to be 
> enabled/disabled from a command require request to get the mapping 
> information again.
> 
>  
> 
> In the case thus described we end up in looping the request message 
> infinitely.
> 
>  
> 
> SPE1
> 
>                  /   \
> 
>                 /     \
> 
>                /       \                     
> 
>               /         \
> 
>              /           \ 
> 
>             /             \
> 
>           SPE2------------SPE3
> 
>  
> 
>  
> 
> Suppose S-PE1 send request to S-PE2 and S-PE3. On receiving this request 
> at S-PE2, we search and locate the corresponding Switch-VC configured; 
> the operation now would be to send the request message to the other 
> segment (PW) of this switch VC i.e. to S-PE3. When S-PE3 receives this 
> request, find the switch VC and would send the request to the other 
> segment (PW) i.e. to S-PE1. The S-PE1 would continue to send request 
> message as described above. Thus the request message would loop around 
> in this topology for ever.
> 
>  
> 
> /_Solutions:_/
> 
>  
> 
> 1)    PW Switching point TLV
> 
> 2)    Hop Count
> 
> 3)    Time To Live (TTL)
> 
>  
> 
>  
> 
> *PW Switching point TLV*
> 
> The draft /draft-ietf-pwe3-segmented-pw-xx/ [refer section 6.1.4] 
> mentions the use of PW Switching point TLV in the mapping/notification 
> message. This can be extended to the request message and the looping can 
> be avoided.
> 
>  
> 
>   0                   1                   2                   3
> 
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    |1|0|     PW sw TLV  (0x096B)   |     PW sw TLV  Length         |
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    |     Type      |    Length     |    Variable Length Value      |
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    |                         Variable Length Value                 |
> 
>    |                             "                                 |
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>  
> 
>  
> 
> The Type Values are assigned as follows:
> 
>       Type      Length    Description
> 
>  
> 
>       0x00         0       Reserved
> 
>       0x01         4       PW ID of last PW traversed
> 
>       0x02      variable   PW Switching Point description string
> 
>       0x03         4       IP address of PW Switching Point (Optional)
> 
>  
> 
> We can attach the LSR-ID of S-PE every time we generate / send the 
> request message, on receiving the request message a check is made to 
> make sure that the router LSR ID is not present in this TLV. In the 
> above case S-PE1 would receive the request message with the LSR-ID of 
> S-PE1, S-PE2 and S-PE3. We discard the request message as S-PE1 LSR ID 
> is present in the switching point TLV.
> 
>  
> 
> In case of request message loop detection we do not send label release 
> as done in the case of mapping/notification.
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> *Hop Count*
> 
> * *
> 
> Another solution to avoid the looping of request message would be to 
> append the Hop Count as done in draft /draft-ietf-mpls-rfc3036bis-xx/ 
> [refer section 3.4.4]. This would calculate the number of hops the 
> request message propagates.
> 
>  
> 
> Type      Length    Description
> 
>  
> 
> 0x04         4      Hop Count of PW Switching Point traversed
> 
>  
> 
> Follow the procedure to discard the request message once the Hop Count 
> reaches a specified maximum value.
> 
>  
> 
> *Time to Live [TTL]*
> 
> * *
> 
> Based on the above idea one can use a TTL field to avoid infinite 
> looping of request messages. As the message traverse through the hop, 
> the TTL value is thus decremented. The message is discarded when the 
> field value is zero.
> 
>  
> 
> Type      Length    Description
> 
>  
> 
> 0x04         4      TTL field value
> 
>  
> 
> The field can be initialized to specified value.
> 
> _ _
>

---

From: Huke Hu Chun Zhe <[email-masked]>
Date: Wed, 02 Nov 2005 18:11:41 +0800

Luca , 

Please see my in line comments

----- Original Message ----- 
From: "Luca Martini" <[email-masked]>
To: "Huke Hu Chun Zhe" <[email-masked]>
Cc: <[email-masked]>; "pwe3" <[email-masked]>
Sent: Tuesday, November 01, 2005 5:08 PM
Subject: Re: One issue and its solution in PWE3 draftdraft-ietf-pwe3-segmented-pw-00.txt

> disabling spanning tree protocol.

we can not aviod in the real network , by mistake 
or even old network enhancement can not avoid to have a loop among switch points 

> hence a label request should not be normally used.
It is correct in normal PtoP VLL case , but in multi-hop senario,
request message can avoid the senario that switch point has lots of 
mapping but actually there is no configure or less VLL inside switch point.
If request message import, there is no need for holding on all the mapping 
messase , instead, hold on all mapping which can match local configuration.
and when new VLL configure, just send request and get it, Since in the switch 
point, it is not the original point which PW connect AC .

> I do not see any looping of messages in this situation.

Consider this senarion 
CE1---PE1-----SPE1---SPE2---PE2--CE2
PE1 has multi-hop both with SPE1 and SPE2, if request is not forwarded
there is no way to let SPE2 know the PE1 exist and give reply .

And also we suggest to import " request message " which can give us:

Advantage of using Request Message

1) LDP provides us with a request message which can be useful in PWE3 to reduce the memory to store the remote LDP Mapping received. Also once we store less number of LDP Mappings (only the once you actually need right now) we end making the search and event handling much faster; No need to scan mappings that are not needed. 

2) In cases where VPLS is also supported, the LDP mapping format for PWE3 and VPLS are the same so when LDP receives such a mapping, it notify it to both PWE3 and VPLS. In such a case the same mapping which is actually used by VPLS maybe stored with PWE3 and would never be used by it. Two copies of same message would end up being stored in the system. In the case where we do not store the mapping which is not matched we reduce the memory and consequently increase our search and event handling speed.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 2 Nov 2005 08:26:49 -0500

> or even old network enhancement can not avoid to have a loop among  

	I think you are missing Luca's original point. Since
the segments are statically configured, the provisioning
system should be able to understand (and prevent)
loops.  This is the same as PVC provisioning in ATM/Frame
networks, which is well understood.  Certainly there
can be 'sticky fingers' cases, but they should be handled
by the provisioning system.

	--Tom

> 1) LDP provides us with a request message which can be useful in  
> PWE3 to reduce the memory to store the remote LDP Mapping received.  
> Also once we store less number of LDP Mappings (only the once you  
> actually need right now) we end making the search and event  
> handling much faster; No need to scan mappings that are not needed.
>
> 2) In cases where VPLS is also supported, the LDP mapping format  
> for PWE3 and VPLS are the same so when LDP receives such a mapping,  
> it notify it to both PWE3 and VPLS. In such a case the same mapping  
> which is actually used by VPLS maybe stored with PWE3 and would  
> never be used by it. Two copies of same message would end up being  
> stored in the system. In the case where we do not store the mapping  
> which is not matched we reduce the memory and consequently increase  
> our search and event handling speed.
>
>
>> Luca
>>
>>
>>
>> Huke Hu Chun Zhe wrote:

---

From: Huke Hu Chun Zhe <[email-masked]>
Date: Wed, 09 Nov 2005 09:11:15 +0800

To Mike's feedback:
In our implementation, signaling messages are routed to the next hop. 
But the SPEs are misconfigured as the next hop of another one by one, so forms the loop.

To Thomas's feedback:
The purpose of us is just to provide a way to handle the loop problem in 'sticky fingers' cases,
which is to append sw TLV to LDP label request message.

>> request ), it simply will not answer nor forward the label request.

It seems to be another way to resolve the loop problem. When an intermediate router receives
a request message and no label is allocated for it, the message is discarded, for the UPE on
the other side of this intermediate router must not be setup. It is useless to forward the 
request message.But in our description, SPE can forward request msg. And , we found 
to import REQUEST MSG can improve the performance , and keep the useless mapping GONE.