[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PWE3] Re: One issue and its solution in PWE3 draftdraft-ietf-pwe3-segmented-pw-00.txt
Luca ,
Please see my in line comments
----- Original Message -----
From: "Luca Martini" <lmartini at cisco.com>
To: "Huke Hu Chun Zhe" <huchunzhe at huawei.com>
Cc: <l2vpn at ietf.org>; "pwe3" <pwe3 at ietf.org>
Sent: Tuesday, November 01, 2005 5:08 PM
Subject: Re: One issue and its solution in PWE3 draftdraft-ietf-pwe3-segmented-pw-00.txt
> 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.
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
> The specified mode for PWE3 LDP protocol is liberal label retention,
> 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 .
> 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.
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.
> 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.
> >
> > _ _
> >
>
>
_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3