Clarification regarding draft-lasserre-vkompella-ppvpn-vpls-04.txt
"Iswar..." <[email protected]> Wed, 16 Jul 2003 14:28:15 +0530
| Newsgroups | gmane.ietf.ppvpn |
|---|---|
| Organization | Lycos Mail (http://www.mail.lycos.com:80) |
| Message-ID | <[email protected]> |
Hi!!!
I have few queries regarding section
10.2. Redundant Spoke Connections in the draft-lasserre-vkompella-ppvpn-vpls-04.txt.
Kindly go through the inlined queries marked with ">>>>".
Thanks and Regards
Iswar...
10.2. Redundant Spoke Connections
An obvious weakness of the hub and spoke approach described thus far
is that the MTU device has a single connection to the PE-rs device.
In case of failure of the connection or the PE-rs device, the MTU
device suffers total loss of connectivity.
In this section we describe how the redundant connections can be
provided to avoid total loss of connectivity from the MTU device.
The mechanism described is identical for both, MTU-s and PE-r type
of devices
10.2.1. Dual-homed MTU device
To protect from connection failure of the pseudowire or the failure
of the PE-rs device, the MTU-s device or the PE-r is dual-homed into
two PE-rs devices, as shown in figure-3. The PE-rs devices must be
part of the same VPLS service instance.
An MTU-s device will setup two [PWE3-ETHERNET] pseudowires (one each
to PE-rs1 and PE-rs2) for each VPLS instance. One of the two
pseudowires is designated as primary and is the one that is actively
used under normal conditions, while the second pseudowire is
designated as secondary and is held in a standby state. The MTU
device negotiates the pseudowire labels for both the primary and
secondary pseudowires, but does not use the secondary pseudowire
unless the primary pseudowire fails. Since only one link is active
at a given time, a loop does not exist and hence 802.1D spanning
tree is not required.
PE2-rs
------
/ \
| -- |
| / \ |
CE-1 | \B / |
\ \ -- /
\ /------
\ MTU-s PE1-r / |
\------ ------ / |
/ \ / \ / |
| -- | Primary PW | |
| / \--|- - - - - - - - - - |--/ \ | |
| \B / | | \B / | |
\ -- \/ \ -- / \ |
------\ ------ \ |
/ \ \ |
/ \ \ ------
/ \ / \
CE-2 \ | -- |
\ Secondary PW | / \ |
- - - - - - - - - - - -- - - - |-\B / |
\ -- /
------
PE3-rs
10.2.2. Failure detection and recovery
The MTU-s device controls the usage of the pseudowires to the PE-rs
nodes. Since LDP signaling is used to negotiate the pseudowire
labels, the hello messages used for the LDP session can be used to
detect failure of the primary pseudowire.
Upon failure of the primary pseudowire, MTU-s device immediately
switches to the secondary pseudowire. At this point the PE3-rs
device that terminates the secondary pseudowire starts learning MAC
addresses on the spoke pseudowire. All other PE-rs nodes in the network
think that CE-1 and CE-2 are behind PE1-rs and may continue
to send traffic to PE1-rs until they learn that the devices are now
behind PE3-rs. The relearning process can take a long time and may
adversely affect the connectivity of higher level protocols from CE1
and CE2. To enable faster convergence, the PE3-rs device where the
secondary pseudowire got activated may send out a flush message,
****************************************************************
>>>> "To enable faster convergence, the PE3-rs device where the
secondary pseudowire got activated may send out a flush message".
Does the "may send out a flush message" gives the developer enough
liberty to send a more specific "Address Withdrawal Mesg", rather than
sending a flush message?
The "Address Withdrawal Mesg" would be sent from the MTU-s to PE3-rs,
when the standby spoke is activated. Here instead of sending a flush
message,
the MTU-s can choose to send the already learnt MAC mapppings and PE3-rs
can create this entries afresh as it wont be available in its database.
It also sends it to
the other PEs.
Here to avoid flooding of mulitple "MAC withdrawal mesg ", a check can be
made to
forward the "MAC withdrawal mesg " only when it is recieved on a SPOKE
from MTU-s.
For "MAC withdrawal mesg " received on HUB is used for
relearning/flushing only.
Here "relearn" is intrepreted in two ways
- create a new entry (in case of PE3-rs)
- relearn the association with the pseudowire on which it is rcvd (in case
of PE2-rs if it alive and any other network PE)
Is it safe to do like this or am I missing some thread?
***********************************************************
using the MAC TLV as defined in Section 6, to PE1-rs, who relays it
***********************************************************
>>>> Referring to section 7, which talks about MAC TLV
***********************************************************
to all other PE-rs devices participating in the VPLS service. Upon
receiving the message, all PE-rs nodes flush the MAC addresses
associated with that VPLS instance.
***********************************************************
>>>> Here according to the the "MAC withdrawal mesg" is first sent to PE3-rs
then PE3-rs subsequnetly sens tp PE1-rs which in turn sends to all other
network PEs.
In this case how is relearning done, as section 7.2.2 quotes
" Relearn the association between the MAC address and the
interface/pseudowire over which this message is received "
which is contradictory.
>>>> Section 7 inlined
***********************************************************
7.2. MAC Address Withdrawal
It MAY be desirable to remove or relearn MAC addresses that have
been dynamically learned for faster convergence.
We introduce an optional MAC TLV that is used to specify a list of
MAC addresses that can be removed or relearned using the Address
Withdraw Message.
The Address Withdraw message with MAC TLVs MAY be supported in order
to expedite learning of MAC addresses as the result of a topology
change (e.g., failure of the primary link for a dual-homed MTU-s).
If a notification message is sent on the backup link (blocked link),
which has transitioned into an active state (e.g., similar to
Topology Change Notification message of 802.1w RSTP), with a list of
MAC entries to be relearned, the PE will update the MAC entries in
its FIB for that VPLS instance and send the message to other PEs
over the corresponding directed LDP sessions.
If the notification message contains an empty list, this tells the
receiving PE to remove all the MAC addresses learned for the
specified VPLS instance except the ones it learned from the sending
PE (MAC address removal is required for all VPLS instances that are
affected). Note that the definition of such a notification message
is outside the scope of the document, unless it happens to come from
an MTU connected to the PE as a spoke. In such a scenario, the
message will be just an Address Withdraw message as noted above.
7.2.1. MAC TLV
MAC addresses to be relearned can be signaled using an LDP Address
Withdraw Message that contains a new TLV, the MAC TLV. Its format
is described below. The encoding of a MAC TLV address is the 6-byte
MAC address specified by IEEE 802 documents [g-ORIG] [802.1D-REV].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit
Unknown bit. This bit MUST be set to 0. If the MAC address
format is not understood, then the TLV is not understood, and MUST
be ignored.
F bit
Forward bit. This bit MUST be set to 0. Since the LDP
mechanism used here is Targeted, the TLV MUST NOT be forwarded.
Type
Type field. This field MUST be set to 0x0404 (subject to IANA
approval). This identifies the TLV type as MAC TLV.
Length
Length field. This field specifies the total length of the
TLV, including the Type and Length fields.
MAC Address
The MAC address being removed.
The LDP Address Withdraw Message contains a FEC TLV (to identify the
VPLS in consideration), a MAC Address TLV and optional parameters.
No optional parameters have been defined for the MAC Address
Withdraw signaling.
7.2.2. Address Withdraw Message Containing MAC TLV
When MAC addresses are being removed or relearned explicitly, e.g.,
the primary link of a dual-homed MTU-s has failed, an Address
Withdraw Message can be sent with the list of MAC addresses to be
relearned.
The processing for MAC TLVs received in an Address Withdraw Message
is:
For each MAC address in the TLV:
- Relearn the association between the MAC address and the
interface/pseudowire over which this message is received
- Send the same message to all other PEs over the corresponding
directed LDP sessions.
For an Address Withdraw message with empty list:
- Remove all the MAC addresses associated with the VPLS instance
(specified by the FEC TLV) except the MAC addresses learned
over this link (over the pseudowire associated with the
signaling link over which the message is received)
- Send the same message to all other PEs over the corresponding
directed LDP sessions.
The scope of a MAC TLV is the VPLS specified in the FEC TLV in the
Address Withdraw Message. The number of MAC addresses can be
deduced from the length field in the TLV.
Further descriptions of how to deal with failures expeditiously with
different configurations will be described in other documents, such
as [VPLS-BRIDGING].
____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005