draft-ietf-bess-vpls-multihoming-02.txt   draft-ietf-bess-vpls-multihoming-03.txt 
Network Working Group B. Kothari Network Working Group B. Kothari
Internet-Draft Augtera Networks Internet-Draft Augtera Networks
Updates: 4761 (if approved) K. Kompella Updates: 4761 (if approved) K. Kompella
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: March 16, 2019 W. Henderickx Expires: September 27, 2019 W. Henderickx
Nokia Nokia
F. Balus F. Balus
Cisco Cisco
J. Uttaro J. Uttaro
AT&T AT&T
Sep 12, 2018 Mar 26, 2019
BGP based Multi-homing in Virtual Private LAN Service BGP based Multi-homing in Virtual Private LAN Service
draft-ietf-bess-vpls-multihoming-02.txt draft-ietf-bess-vpls-multihoming-03.txt
Abstract Abstract
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often sites are connected via a Local Area Network (LAN). It is often
required for the Service Provider (SP) to give the customer redundant required for the Service Provider (SP) to give the customer redundant
connectivity to some sites, often called "multi-homing". This memo connectivity to some sites, often called "multi-homing". This memo
shows how BGP-based multi-homing can be offered in the context of LDP shows how BGP-based multi-homing can be offered in the context of LDP
and BGP VPLS solutions. and BGP VPLS solutions.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2019. This Internet-Draft will expire on September 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 48 skipping to change at page 2, line 48
4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of 4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of
VPLS Information between ASes . . . . . . . . . 16 VPLS Information between ASes . . . . . . . . . 16
5. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . 16 5. MAC Flush Operations . . . . . . . . . . . . . . . . . . . . 16
5.1. MAC Flush Indicators . . . . . . . . . . . . . . . . . . 16 5.1. MAC Flush Indicators . . . . . . . . . . . . . . . . . . 16
5.2. Minimizing the effects of fast link transitions . . . . . 17 5.2. Minimizing the effects of fast link transitions . . . . . 17
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17
6.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . 18 6.1. BGP based VPLS . . . . . . . . . . . . . . . . . . . . . 18
6.2. LDP VPLS with BGP Auto-discovery . . . . . . . . . . . . 18 6.2. LDP VPLS with BGP Auto-discovery . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN). It is often sites are connected via a Local Area Network (LAN). It is often
required for a Service Provider (SP) to give the customer redundant required for a Service Provider (SP) to give the customer redundant
connectivity to one or more sites, often called "multi-homing". connectivity to one or more sites, often called "multi-homing".
skipping to change at page 5, line 4 skipping to change at page 5, line 4
This section describes various scenarios where multi-homing may be This section describes various scenarios where multi-homing may be
required, and the implications thereof. It also describes some of required, and the implications thereof. It also describes some of
the singular properties of VPLS multi-homing, and what that means the singular properties of VPLS multi-homing, and what that means
from both an operational point of view and an implementation point of from both an operational point of view and an implementation point of
view. There are other approaches for providing multi-homing such as view. There are other approaches for providing multi-homing such as
Spanning Tree Protocol, and this document specifies use of BGP for Spanning Tree Protocol, and this document specifies use of BGP for
multi-homing. Comprehensive comparison among the approaches is multi-homing. Comprehensive comparison among the approaches is
outside the scope of this document. outside the scope of this document.
2.1. Scenarios 2.1. Scenarios
CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant In Figure 1, CE1 is a VPLS CE that is dual-homed to both PE1 and PE2
connectivity. for redundant connectivity.
............... ...............
. . ___ CE2 . . ___ CE2
___ PE1 . / ___ PE1 . /
/ : PE3 / : PE3
__/ : Service : __/ : Service :
CE1 __ : Provider PE4 CE1 __ : Provider PE4
\ : : \___ CE3 \ : : \___ CE3
\___ PE2 . \___ PE2 .
. . . .
............... ...............
Figure 1: Scenario 1 Figure 1: Scenario 1
CE1 is a VPLS CE that is dual-homed to both PE1 and PE2 for redundant In Figure 2, CE1 is a VPLS CE that is dual-homed to both PE1 and PE2
connectivity. However, CE4, which is also in the same VPLS domain, for redundant connectivity. However, CE4, which is also in the same
is single-homed to just PE1. VPLS domain, is single-homed to just PE1.
CE4 ------- ............... CE4 ------- ...............
\ . . ___ CE2 \ . . ___ CE2
___ PE1 . / ___ PE1 . /
/ : PE3 / : PE3
__/ : Service : __/ : Service :
CE1 __ : Provider PE4 CE1 __ : Provider PE4
\ : : \___ CE3 \ : : \___ CE3
\___ PE2 . \___ PE2 .
. . . .
skipping to change at page 6, line 36 skipping to change at page 6, line 36
+------------------------------------+ +------------------------------------+
| VE ID (2 octets) | | VE ID (2 octets) |
+------------------------------------+ +------------------------------------+
| VE Block Offset (2 octets) | | VE Block Offset (2 octets) |
+------------------------------------+ +------------------------------------+
| VE Block Size (2 octets) | | VE Block Size (2 octets) |
+------------------------------------+ +------------------------------------+
| Label Base (3 octets) | | Label Base (3 octets) |
+------------------------------------+ +------------------------------------+
BGP VPLS NLRI Figure 3: BGP VPLS NLRI
For multi-homing operation, a customer-edge NLRI (CE NLRI) is For multi-homing operation, a customer-edge NLRI (CE NLRI) is
proposed that uses BGP VPLS NLRI with the following fields set to proposed that uses BGP VPLS NLRI with the following fields set to
zero: VE Block Offset, VE Block Size and Label Base. In addition, zero: VE Block Offset, VE Block Size and Label Base. In addition,
the VE-ID field of the NLRI is set to CE-ID. Thus, the CE NLRI the VE-ID field of the NLRI is set to CE-ID. Thus, the CE NLRI
contains 2 octets indicating the length, 8 octets for Route contains 2 octets indicating the length, 8 octets for Route
Distinguisher, 2 octets for CE-ID and 7 octets with value zero. Distinguisher, 2 octets for CE-ID and 7 octets with value zero.
It is valid to have non-zero VE block offset, VE block size and label It is valid to have non-zero VE block offset, VE block size and label
base in the VPLS NLRI for a multi-homed site. VPLS operations, base in the VPLS NLRI for a multi-homed site. VPLS operations,
skipping to change at page 9, line 8 skipping to change at page 9, line 8
The procedures below refer to two attributes: the Route Origin The procedures below refer to two attributes: the Route Origin
community (see Section 4.1) and the L2-info community (see community (see Section 4.1) and the L2-info community (see
Section 4.2). These attributes are required for inter-AS operation; Section 4.2). These attributes are required for inter-AS operation;
for generality, the procedures below show how they are to be used. for generality, the procedures below show how they are to be used.
The procedures also outline how to handle the case that either or The procedures also outline how to handle the case that either or
both are not present. both are not present.
For BGP-based Multi-homing, ADV MUST contain an L2-info extended For BGP-based Multi-homing, ADV MUST contain an L2-info extended
community as specified in [RFC4761]. Within this community are community as specified in [RFC4761]. Within this community are
various control flags. Two new control flags are proposed in this various control flags. Two new control flags are proposed in this
document. Figure 3 shows the position of the new 'D' and 'F' flags. document. Figure 4 shows the position of the new 'D' and 'F' flags.
Control Flags Bit Vector Control Flags Bit Vector
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|D|Z|F|Z|Z|Z|C|S| (Z = MUST Be Zero) |D|Z|F|Z|Z|Z|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3 Figure 4
1. 'D' (Down): Indicates connectivity status. In case of CE NLRI, 1. 'D' (Down): Indicates connectivity status. In case of CE NLRI,
the connectivity status is between a CE site and a VPLS PE. In the connectivity status is between a CE site and a VPLS PE. In
case of VE NLRI, the connectivity status is for the VPLS case of VE NLRI, the connectivity status is for the VPLS
instance. In case of CE NLRI, the bit MUST be set to one if all instance. In case of CE NLRI, the bit MUST be set to one if all
the attachment circuits connecting a CE site to a VPLS PE are the attachment circuits connecting a CE site to a VPLS PE are
down. In case of VE NLRI, the bit must be set to one if the VPLS down. In case of VE NLRI, the bit must be set to one if the VPLS
instance is operationally down. Note that a VPLS instance that instance is operationally down. Note that a VPLS instance that
has no connectivity to any of its sites must be considered as has no connectivity to any of its sites must be considered as
operationally down. operationally down.
skipping to change at page 14, line 11 skipping to change at page 14, line 11
Preference is not carried across AS boundary. A new field, VPLS Preference is not carried across AS boundary. A new field, VPLS
preference (VP), is introduced in this document that can be used to preference (VP), is introduced in this document that can be used to
accomplish this. VPLS preference indicates a degree of preference accomplish this. VPLS preference indicates a degree of preference
for a particular customer site. VPLS preference is not mandatory for for a particular customer site. VPLS preference is not mandatory for
intra-AS operation; the algorithm explained in Section 3.3 will work intra-AS operation; the algorithm explained in Section 3.3 will work
with or without the presence of VPLS preference. with or without the presence of VPLS preference.
Section 3.2.4 in [RFC4761] describes the Layer2 Info Extended Section 3.2.4 in [RFC4761] describes the Layer2 Info Extended
Community that carries control information about the pseudowires. Community that carries control information about the pseudowires.
The last two octets that were reserved now carries VPLS preference as The last two octets that were reserved now carries VPLS preference as
shown in Figure 4. shown in Figure 5.
+------------------------------------+ +------------------------------------+
| Extended community type (2 octets) | | Extended community type (2 octets) |
+------------------------------------+ +------------------------------------+
| Encaps Type (1 octet) | | Encaps Type (1 octet) |
+------------------------------------+ +------------------------------------+
| Control Flags (1 octet) | | Control Flags (1 octet) |
+------------------------------------+ +------------------------------------+
| Layer-2 MTU (2 octet) | | Layer-2 MTU (2 octet) |
+------------------------------------+ +------------------------------------+
| VPLS Preference (2 octets) | | VPLS Preference (2 octets) |
+------------------------------------+ +------------------------------------+
Figure 4: Layer2 Info Extended Community Figure 5: Layer2 Info Extended Community
A VPLS preference is a 2-octets unsigned integer. A value of zero A VPLS preference is a 2-octets unsigned integer. A value of zero
indicates absence of a VP and is not a valid preference value. This indicates absence of a VP and is not a valid preference value. This
interpretation is required for backwards compatibility. interpretation is required for backwards compatibility.
Implementations using Layer2 Info Extended Community as described in Implementations using Layer2 Info Extended Community as described in
(Section 3.2.4) [RFC4761] MUST set the last two octets as zero since (Section 3.2.4) [RFC4761] MUST set the last two octets as zero since
it was a reserved field. it was a reserved field.
For backwards compatibility, if VPLS preference is used, then BGP For backwards compatibility, if VPLS preference is used, then BGP
Local Preference MUST be set to the value of VPLS preference. Note Local Preference MUST be set to the value of VPLS preference. Note
skipping to change at page 14, line 51 skipping to change at page 14, line 51
4.3. Use of BGP attributes in Inter-AS Methods 4.3. Use of BGP attributes in Inter-AS Methods
Section 3.4 in [RFC4761] and section 4 in [RFC6074] describe three Section 3.4 in [RFC4761] and section 4 in [RFC6074] describe three
methods (a, b and c) to connect sites in a VPLS to PEs that are methods (a, b and c) to connect sites in a VPLS to PEs that are
across multiple AS. Since VPLS advertisements in method (a) do not across multiple AS. Since VPLS advertisements in method (a) do not
cross AS boundaries, multi-homing operations for method (a) remain cross AS boundaries, multi-homing operations for method (a) remain
exactly the same as they are within as AS. However, for method (b) exactly the same as they are within as AS. However, for method (b)
and (c), VPLS advertisements do cross AS boundary. This section and (c), VPLS advertisements do cross AS boundary. This section
describes the VPLS operations for method (b) and method (c). describes the VPLS operations for method (b) and method (c).
Consider Figure 5 for inter-AS VPLS with multi-homed customer sites. Consider Figure 6 for inter-AS VPLS with multi-homed customer sites.
4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS Information 4.3.1. Inter-AS Method (b): EBGP Redistribution of VPLS Information
between ASBRs between ASBRs
AS1 AS2 AS1 AS2
........ ........ ........ ........
CE2 _______ . . . . CE2 _______ . . . .
___ PE1 . . PE3 --- CE3 ___ PE1 . . PE3 --- CE3
/ : . . : / : . . :
__/ : : : : __/ : : : :
CE1 __ : ASBR1 --- ASBR2 : CE1 __ : ASBR1 --- ASBR2 :
\ : : : : \ : : : :
\___ PE2 . . PE4 ---- CE4 \___ PE2 . . PE4 ---- CE4
. . . . . . . .
........ ........ ........ ........
Figure 5: Inter-AS VPLS Figure 6: Inter-AS VPLS
A customer has four sites, CE1, CE2, CE3 and CE4. CE1 is multi-homed A customer has four sites, CE1, CE2, CE3 and CE4. CE1 is multi-homed
to PE1 and PE2 in AS1. CE2 is single-homed to PE1. CE3 and CE4 are to PE1 and PE2 in AS1. CE2 is single-homed to PE1. CE3 and CE4 are
also single homed to PE3 and PE4 respectively in AS2. Assume that in also single homed to PE3 and PE4 respectively in AS2. Assume that in
addition to the base LDP/BGP VPLS addressing (VSI-IDs/VE-IDs), CE-ID addition to the base LDP/BGP VPLS addressing (VSI-IDs/VE-IDs), CE-ID
1 is assigned for CE1. After running DF election algorithm, all four 1 is assigned for CE1. After running DF election algorithm, all four
VPLS PEs must elect the same designated forwarder for CE1 site. VPLS PEs must elect the same designated forwarder for CE1 site.
Since BGP Local Preference is not carried across AS boundary, VPLS Since BGP Local Preference is not carried across AS boundary, VPLS
preference as described in Section 4.2 MUST be used for carrying site preference as described in Section 4.2 MUST be used for carrying site
preference in inter-AS VPLS operations. preference in inter-AS VPLS operations.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
ASBR1. ASBR1 MUST do the same for the NLRIs it sends to PE1 and PE2. ASBR1. ASBR1 MUST do the same for the NLRIs it sends to PE1 and PE2.
If ASBR1 receives a VPLS advertisement without a valid VPLS If ASBR1 receives a VPLS advertisement without a valid VPLS
preference from a PE within its AS, then ASBR1 MUST set the VPLS preference from a PE within its AS, then ASBR1 MUST set the VPLS
preference in the advertisements to the Local Preference value before preference in the advertisements to the Local Preference value before
sending it to ASBR2. Similarly, ASBR2 must do the same for sending it to ASBR2. Similarly, ASBR2 must do the same for
advertisements without VPLS Preference it receives from PEs within advertisements without VPLS Preference it receives from PEs within
its AS. Thus, in method (b), ASBRs MUST update the VPLS and Local its AS. Thus, in method (b), ASBRs MUST update the VPLS and Local
Preference based on the advertisements they receive either from an Preference based on the advertisements they receive either from an
ASBR or a PE within their AS. ASBR or a PE within their AS.
In Figure 5, PE1 will send the VPLS advertisements with Route Origin In Figure 6, PE1 will send the VPLS advertisements with Route Origin
Extended Community containing its loopback address. PE2 will do the Extended Community containing its loopback address. PE2 will do the
same. Even though PE3 receives the VPLS advertisements for VE-ID 1 same. Even though PE3 receives the VPLS advertisements for VE-ID 1
and 2 from the same BGP nexthop, ASBR2, the source PE address and 2 from the same BGP nexthop, ASBR2, the source PE address
contained in the Route Origin Extended Community is different for the contained in the Route Origin Extended Community is different for the
CE1 and CE2 advertisements, and thus, PE3 creates two PWs, one for CE1 and CE2 advertisements, and thus, PE3 creates two PWs, one for
CE1 (for VE-ID 1) and another one for CE2 (for VE-ID 2). CE1 (for VE-ID 1) and another one for CE2 (for VE-ID 2).
4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of VPLS 4.3.2. Inter-AS Method (c): Multi-Hop EBGP Redistribution of VPLS
Information between ASes Information between ASes
skipping to change at page 17, line 10 skipping to change at page 17, line 10
advertising the failure. advertising the failure.
Anytime a designated forwarder change occurs, a remote PE SHOULD Anytime a designated forwarder change occurs, a remote PE SHOULD
flush all the MAC addresses it learned from the PE that lost the DF flush all the MAC addresses it learned from the PE that lost the DF
election (old designated forwarder). If multiple customer sites are election (old designated forwarder). If multiple customer sites are
connected to the same PE, PE1 as shown in Figure 2, and redundancy connected to the same PE, PE1 as shown in Figure 2, and redundancy
per site is desired when multi-homing procedures described in this per site is desired when multi-homing procedures described in this
document are in effect, then it is desirable to flush just the document are in effect, then it is desirable to flush just the
relevant MAC addresses from a particular site when the site relevant MAC addresses from a particular site when the site
connectivity is lost. However, procedures for flushing a limited set connectivity is lost. However, procedures for flushing a limited set
of MAC addresses is beyond the scope of this document. Use of either of MAC addresses are beyond the scope of this document. Use of
'D' or 'F' bit in control flags only allows to flush all MAC either 'D' or 'F' bit in control flags only allows to flush all MAC
addresses associated with a PE. addresses associated with a PE.
Designated forwarder change can occur in absence of failures, such as Designated forwarder change can occur in absence of failures, such as
when an attachment circuit comes up. Consider the case in Figure 2 when an attachment circuit comes up. Consider the case in Figure 2
where PE1-CE1 link is non-operational and PE2 is the designated where PE1-CE1 link is non-operational and PE2 is the designated
forwarder for CE1. Also assume that Local Preference of PE1 is forwarder for CE1. Also assume that Local Preference of PE1 is
higher than PE2. When PE1-CE1 link becomes operational, PE1 will higher than PE2. When PE1-CE1 link becomes operational, PE1 will
send a BGP CE advertisement for CE1 to all it's peers. If PE3 send a BGP CE advertisement for CE1 to all it's peers. If PE3
performs the DF election before PE2, there is a chance that PE3 might performs the DF election before PE2, there is a chance that PE3 might
learn MAC addresses from PE2 after it was done electing PE1. This learn MAC addresses from PE2 after it was done electing PE1. This
skipping to change at page 18, line 44 skipping to change at page 18, line 44
LDP VPLS PEs or may use the MAC Flush procedures as described in LDP VPLS PEs or may use the MAC Flush procedures as described in
Section 5 Section 5
7. Security Considerations 7. Security Considerations
No new security issues are introduced beyond those that are described No new security issues are introduced beyond those that are described
in [RFC4761] and [RFC4762]. in [RFC4761] and [RFC4762].
8. IANA Considerations 8. IANA Considerations
At this time, this memo includes no request to IANA. IANA already has a registry for "Layer2 Info Extended Community
Control Flags Bit Vector" <https://www.iana.org/assignments/bgp-
extended-communities>
This document requires two new bit flags to be assigned as follows:
Value Name Reference
----- -------------------------------- --------------
D Down connectivity status This document
F MAC flush indicator This document
9. Contributing Authors 9. Contributing Authors
The authos would also like to thank Senad Palislamovic and Wen Lin The authors would also like to thank Senad Palislamovic and Wen Lin
for their contribution to the development of this document. for their contribution to the development of this document.
Senad Palislamovic Senad Palislamovic
Nokia Nokia
Email: senad.palislamovic@nokia.com Email: senad.palislamovic@nokia.com
Wen Lin Wen Lin
Juniper Networks Juniper Networks
Email: wlin@juniper.net Email: wlin@juniper.net
 End of changes. 20 change blocks. 
24 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/