Subject: Discovery and full mesh failure

From: [email-masked]
Date: Fri, 19 Dec 2003 13:16:41 -0000

I have a couple of observations/queries regarding draft-rosen-l2vpn-mesh-failure-00.txt.
 
The draft lists "Failure of the auto-discovery process" as being one of the reasons a given LS instance may not be fully meshed. IMO this is dependant on the type of discovery mechanism used. If a centralised mechanism is used, all PEs will receive exactly the same membership information and therefore a full mesh will always be established (providing there are no signalling errors). The same could be said of a distributed discovery mechanism that maintains a common/global LS EE membership table/database, as opposed to a distributed mechanism in which PEs maintains their own independent/local tables. 
 
There is the possibility that discovery packets containing membership information sent to a particular PE could become corrupted in some way and only a subset of the full list of PE members for a given LS may be received. However, if this were to happen then establishment of some of the PWs to the PE that has only received a subset of the full list of PEs would fail. Following this, the PEs (including the PE with only a subset of the full list) would request a resend of the LS EE database and the problem would be rectified (unless packets continue to be corrupted of course, in which case an error would be flagged and subsequent actions would be required.)
 
The draft states "There must be a status message, which we call the "Mesh Status" message, which a PE sends to each of the other PEs in the same LS instance", which "lists the set of EE pairs for which the originating PE has operational PWs". If a common LS EE membership database is maintained then why is this list needed? Each PE receives a list of EEs in the same LS from the common LS EE database, and the PWs between those EEs should be considered to be operational (allowing adequate time for the provisioning process to complete) unless informed otherwise. 
 
In the event of a PW signalling/forwarding failure, the failure should be flagged to the discovery mechanism by the signalling/OAM mechanism that detects the failure. This allows the discovery mechanism to inform PEs belonging to the LS that they should stop forwarding packets to the EEs that are only partially connected (locally attached EEs should be disabled as per the draft). To allow PWs to partially connected EEs to remain established despite forwarding being disabled, all that would be required would be a field in the membership information database that indicates whether an EE is operational or not.
 
IMO the functionality described in this draft should be incorporated into existing centralised discovery mechanisms (e.g. the RADIUS discovery draft), I don't think a new mechanism needs to be defined. It should be the responsibility of the discovery mechanism to determine which EEs should be considered operational based on information it receives about failures from signalling/OAM mechanisms. Maintenance of information about which EEs are operational is important for all VPN technologies, not just VPLS/IPLS, so why not use the capabilities of existing mechanisms rather than define new ones specifically for VPLS/IPLS.
 
In the case of distributed mechanisms in which PEs maintain their own independent LS EE tables/databases (e.g. BGP discovery draft), then I can see why an additional mechanism such as the use of "Mesh Status" messages is required. To address this need I think this draft also needs to take accounting into consideration. If PEs are told to stop forwarding traffic to partially connected EEs (even though the PWs to those EEs are still established) then a management system also needs to be informed otherwise the customer will continue to be charged for EEs that are not forwarding any packets (unless they are being charged based on usage only). In the case of RADIUS, this issue can be solved by simply issuing a stop accounting request for the EEs that are no longer operational.
 
IMO, this draft highlights one of the reasons why a centralised discovery mechanism is more suitable (i.e. a separate mechanism isn't required to maintain information about which EEs are operational) than one in which each PE maintains its own independent EE membership information database.
 
Richard