Subject: Clarification regarding draft-lasserre-vkompella-ppvpn-vpls-04.txt

From: "Iswar..." <[email-masked]>
Date: Wed, 16 Jul 2003 14:28:15 +0530

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