[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
Huke,
It appears you may be confusing the case of dynamic setup of MS-PW vs.
static setup of MS-PW.
Please see draft-balus-bocci-martini-dyn-ms-pwe3-00.txt for procedures
on dynamic setup. In this case the signaling messages are not flooded
by S-PE, but routed to the next hop. See section 6.2.
-----Original Message-----
From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On Behalf
Of Huke Hu Chun Zhe
Sent: Wednesday, November 02, 2005 5:12 AM
To: Luca Martini
Cc: l2vpn at ietf.org; pwe3
Subject: 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