draft-ietf-ospf-lls-interface-id-09.txt   rfc8510.txt 
Open Shortest Path First IGP P. Psenak, Ed. Internet Engineering Task Force (IETF) P. Psenak, Ed.
Internet-Draft K. Talaulikar Request for Comments: 8510 K. Talaulikar
Intended status: Standards Track Cisco Systems, Inc. Category: Standards Track Cisco Systems, Inc.
Expires: May 8, 2019 W. Henderickx ISSN: 2070-1721 W. Henderickx
Nokia Nokia
P. Pillay-Esnault P. Pillay-Esnault
Huawei Huawei USA
November 4, 2018 January 2019
OSPF LLS Extensions for Local Interface ID Advertisement OSPF Link-Local Signaling (LLS) Extensions for
draft-ietf-ospf-lls-interface-id-09 Local Interface ID Advertisement
Abstract Abstract
Every OSPF interface is assigned an identifier, Interface ID, which Every OSPF interface is assigned an Interface ID that uniquely
uniquely identifies the interface on the router. In some cases it is identifies the interface on the router. In some cases, it is useful
useful to know the assigned Interface ID on the remote side of the to know the assigned Interface ID on the remote side of the adjacency
adjacency (Remote Interface ID). (Remote Interface ID).
This draft describes the extensions to OSPF link-local signalling
(LLS) to advertise the Local Interface Identifier.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document describes the extensions to OSPF link-local signaling
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and (LLS) to advertise the Local Interface ID.
"OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on May 8, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8510.
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................3
1.1. Interface ID Exchange using TE Opaque LSA . . . . . . . . 3 1.1. Interface ID Exchange Using Link Local TE Opaque LSA .......4
2. Interface ID Exchange using OSPF LLS . . . . . . . . . . . . 3 1.2. Requirements Language ......................................4
2.1. Local Interface Identifier TLV . . . . . . . . . . . . . 4 2. Interface ID Exchange Using OSPF LLS ............................4
3. Backward Compatibility with RFC 4203 . . . . . . . . . . . . 4 2.1. Local Interface ID TLV .....................................5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 3. Backward Compatibility with RFC 4203 ............................5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations .............................................6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations .........................................6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. References ......................................................6
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.1. Normative References .......................................6
7.2. Informative References . . . . . . . . . . . . . . . . . 6 6.2. Informative References .....................................7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgments ....................................................8
Authors' Addresses .................................................8
1. Introduction 1. Introduction
Every OSPF interface is assigned an Interface ID, which uniquely Every OSPF interface is assigned an Interface ID that uniquely
identifies the interface on the router. [RFC2328] uses this identifies the interface on the router. [RFC2328] uses this
Interface ID in the Router-LSA Link Data for unnumbered links and Interface ID in the Router Link State Advertisement (Router-LSA) Link
uses the value of the MIB-II IfIndex [RFC2863]. [RFC4203] refers to Data for unnumbered links and uses the value of the MIB-II ifIndex
these Interface IDs as the Link Local/Remote Identifiers and defines [RFC2863]. [RFC4203] refers to these Interface IDs as the Link
a way to advertise and use them for Generalized Multi-Protocol Label Local/Remote Identifiers and defines a way to advertise and use them
Switching (GMPLS) purposes. [RFC7684] defines a way to advertise for GMPLS purposes. [RFC8379] defines a way to advertise Local/
Local/Remote Interface IDs in the OSPFv2 Extended Link LSA. Remote Interface IDs in the OSPFv2 Extended Link Opaque LSA.
There is a known OSPFv2 protocol problem in verifying the bi- There is a known OSPFv2 protocol problem in verifying the
directional connectivity with parallel unnumbered links. If there bidirectional connectivity with parallel unnumbered links. If there
are two parallel unnumbered links between a pair of routers and each are two parallel unnumbered links between a pair of routers and each
link is only advertised from single direction, such two link is only advertised from a single direction, such two
unidirectional parallel links could be considered as a valid single unidirectional parallel links could be considered as a valid single
bidirectional link during the OSPF route computation on some other bidirectional link during the OSPF route computation on some other
router. If each link is advertised with both its Local and Remote router. If each link is advertised with both its Local and Remote
Interface IDs, the advertisement of each link from both sides of Interface IDs, the advertisement of each link from both sides of
adjacency can be verified by cross-checking the Local and Remote adjacency can be verified by cross-checking the Local and Remote
Interface IDs of both advertisements. Interface IDs of both advertisements.
From the perspective of the advertising router, the Local Interface From the perspective of the advertising router, the Local Interface
Identifier is a known value, however the Remote Interface Identifier ID is a known value. However, the Remote Interface ID needs to be
needs to be learnt before it can be advertised. [RFC4203] suggests learned before it can be advertised. [RFC4203] suggests using the TE
to use TE Link Local LSA [RFC3630] to communicate the Local Interface Link Local LSA [RFC3630] to communicate the Local Interface ID to
Identifier to neighbors on the link. Though such mechanism works, it neighbors on the link. Though such a mechanism works, it has some
has some drawbacks. drawbacks.
This draft proposes an extension to OSPF link-local signalling (LLS) This document proposes an extension to OSPF link-local signaling
[RFC5613] to advertise the Local Interface Identifier. (LLS) [RFC5613] to advertise the Local Interface ID.
1.1. Interface ID Exchange using TE Opaque LSA 1.1. Interface ID Exchange Using Link Local TE Opaque LSA
Usage of the Link Local TE Opaque LSA to propagate the Local Usage of the Link Local TE Opaque LSA to propagate the Local
Interface Identifier to the neighbors on the link is described in Interface ID to the neighbors on the link is described in [RFC4203].
[RFC4203]. This mechanism has the following problems: This mechanism has the following problems:
LSAs can only be flooded over an existing adjacency that is in o LSAs can only be flooded over an existing adjacency that is in
Exchange state or greater. The adjacency state machine progresses Exchange state or greater. The adjacency state machine progresses
independently on each side of the adjacency and, as such, may independently on each side of the adjacency and, as such, may
reach the Full state on one side before the TE Link Opaque LSA reach the Full state on one side before the Link Local TE Opaque
arrives. The consequence is that link can be initially advertised LSA arrives. The consequence of this is that the link can be
without the Remote Interface Identifier. Later, when the TE Link initially advertised without the Remote Interface ID. Later, when
Opaque LSA arrives, the link must be advertised again, this time the Link Local TE Opaque LSA arrives, the link must be advertised
with the valid Remote Interface Identifier. Implementations may again but this time with the valid Remote Interface ID.
choose to wait before advertising the link, but there is no Implementations may choose to wait before advertising the link,
guarantee that the neighbor will ever advertise the TE Link Opaque but there is no guarantee that the neighbor will ever advertise
LSA with the Interface Identifier. In summary, the existing the Link Local TE Opaque LSA with the Interface ID. In summary,
mechanism does not guarantee that the Remote Interface Identifier the existing mechanism does not guarantee that the Remote
is known at the time the link is advertised. Interface ID is known at the time the link is advertised.
The TE Opaque LSA is defined for MPLS Traffic Engineering, but the o The Link Local TE Opaque LSA is defined for MPLS Traffic
knowledge of the Remote Interface Identifier is useful also for Engineering, but the knowledge of the Remote Interface ID is
cases where MPLS TE is not used. One example is the mentioned useful also for cases where MPLS TE is not used. One example is
lack of a valid 2-way connectivity check for parallel point-to- the mentioned lack of a valid 2-way connectivity check for
point links between OSPF routers. parallel point-to-point links between OSPF routers.
2. Interface ID Exchange using OSPF LLS 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Interface ID Exchange Using OSPF LLS
To address the problems described earlier and to allow the Interface To address the problems described earlier and to allow the Interface
Identifier exchange to be part of the neighbor discovery process, we ID exchange to be part of the neighbor discovery process, we propose
propose to extend OSPF link-local signalling to advertise the Local to extend OSPF link-local signaling to advertise the Local Interface
Interface Identifier in OSPF Hello and Database Description (DD) ID in OSPF Hello and Database Description (DD) packets.
packets.
2.1. Local Interface Identifier TLV 2.1. Local Interface ID TLV
The Local Interface Identifier TLV is a LLS TLV. It has following The Local Interface ID TLV is an LLS TLV. It has the following
format: format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Identifier | | Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Type: 18
Type: TBD
Length: 4 octets Length: 4 octets
Local Interface Identifier: The value of the local Interface Local Interface ID: The value of the Local Interface ID.
Identifier.
Local Interface Identifier TLV signalling using LLS is applicable to Local Interface ID TLV signaling using LLS is applicable to all OSPF
all OSPF interface types other than virtual links. interface types other than virtual links.
3. Backward Compatibility with RFC 4203 3. Backward Compatibility with RFC 4203
If the Local Interface ID signaling via Link Local TE Opaque LSA is If the Local Interface ID signaling via the Link Local TE Opaque LSA
supported in addition to the new LLS mechanism, implementations which is supported in addition to the new LLS mechanism, implementations
support Local Interface ID signalling using LLS MUST prefer the Local that support Local Interface ID signaling using LLS MUST prefer the
Interface ID value received through LLS over the value received Local Interface ID value received through LLS over the value received
through the Link Local TE Opaque LSA if both are received from the through the Link Local TE Opaque LSA if both are received from the
same OSPF router. same OSPF router.
Implementations which support Local Interface ID signalling via Link Implementations that support Local Interface ID signaling via the
Local TE Opaque LSA MAY continue to do so to ensure backward Link Local TE Opaque LSA MAY continue to do so to ensure backward
compatibility. If they also support Local Interface ID signalling compatibility. If they also support Local Interface ID signaling
using LLS as described herein, they MUST signal the same Local using LLS as described in the document, they MUST signal the same
Interface ID via both mechanisms. Local Interface ID via both mechanisms.
During the rare conditions, when the Local Interface ID changes, a During the rare conditions in which the Local Interface ID changes, a
timing interval may exist, where the received values of the Local timing interval may exist where the received values of the Local
Interface ID advertised through LLS and Link Local TE Opaque LSA may Interface ID advertised through LLS and the Link Local TE Opaque LSA
differ. Such situation is temporary and received values via both may differ. Such a situation is temporary, and received values via
mechanisms should become equal as soon as the next Hello and/or Link both mechanisms should become equal as soon as the next Hello and/or
Local TE Opaque LSA is re-generated by the originator. Link Local TE Opaque LSA is regenerated by the originator.
4. IANA Considerations 4. IANA Considerations
This specification allocates a single code point from the "Open IANA has allocated the following code point in the "Link Local
Signalling TLV Identifiers (LLS Types)" subregistry of the "Open
Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/ Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/
Value Identifiers (TLV)" registry. Value Identifiers (TLV)" registry.
Following value is allocated: 18 - Local Interface ID TLV
o TBD - Local Interface Identifier TLV
5. Security Considerations 5. Security Considerations
The security considerations for "OSPF Link-Local Signaling" [RFC5613] The security considerations for "OSPF Link-Local Signaling" [RFC5613]
also apply to the Local Interface Identifier TLV described herein. also apply to the Local Interface ID TLV described in this document.
The current usage of a neighbor's Local Interface Identifier is to The current usage of a neighbor's Local Interface ID is to
disambiguate parallel links between OSPF routers. Hence, disambiguate parallel links between OSPF routers. Hence,
modification of the advertised Local Interface Identifier TLV may modification of the advertised Local Interface ID TLV may result in
result in the wrong neighbor interface identifier being advertised in the wrong neighbor Interface ID being advertised in the OSPFv2
the OSPFv2 Extended Link LSA [RFC7684] and could prevent the link Extended Link Opaque LSA [RFC7684] and could prevent the link from
from being used. If authentication is being used in the OSPF routing being used. If authentication is being used in the OSPF routing
domain [RFC5709], then the Cryptographic Authentication TLV [RFC5613] domain [RFC5709][RFC7474], then the Cryptographic Authentication TLV
SHOULD also be used to protect that contents of the Link-Local [RFC5613] SHOULD also be used to protect the contents of the LLS
Signaling (LLS) block. block.
Receiving a malformed LLS Interface Identifier TLV MUST NOT result in Receiving a malformed LLS Local Interface ID TLV MUST NOT result in a
a hard router or OSPF process failure. The reception of malformed hard router or OSPF process failure. The reception of malformed LLS
LLS TLVs or Sub-TLVs SHOULD be logged but such logging MUST be rate- TLVs or sub-TLVs SHOULD be logged, but such logging MUST be rate-
limited to prevent Denial-of-Service (DoS) attacks. limited to prevent denial-of-service (DoS) attacks.
The interface ID is assigned by the advertising OSPF router as a The Interface ID is assigned by the advertising OSPF router as a
locally unique identifier and need not be unique in any broader locally unique identifier and need not be unique in any broader
context; it is not expected to contain any information about the context; it is not expected to contain any information about the
device owner or traffic transiting the device, so there are no device owner or traffic transiting the device, so there are no
privacy oncerns associated with its advertisement. privacy concerns associated with its advertisement.
6. Acknowledgments
Thanks to Tony Przygienda for his extensive review and useful
comments.
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>. <https://www.rfc-editor.org/info/rfc4203>.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and
Yeung, "OSPF Link-Local Signaling", RFC 5613, D. Yeung, "OSPF Link-Local Signaling", RFC 5613,
DOI 10.17487/RFC5613, August 2009, DOI 10.17487/RFC5613, August 2009,
<https://www.rfc-editor.org/info/rfc5613>. <https://www.rfc-editor.org/info/rfc5613>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>. 2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References [RFC8379] Hegde, S., Sarkar, P., Gredler, H., Nanduri, M., and
L. Jalil, "OSPF Graceful Link Shutdown", RFC 8379,
DOI 10.17487/RFC8379, May 2018,
<https://www.rfc-editor.org/info/rfc8379>.
6.2. Informative References
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<https://www.rfc-editor.org/info/rfc2863>. <https://www.rfc-editor.org/info/rfc2863>.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, DOI 10.17487/RFC5709, October Authentication", RFC 5709, DOI 10.17487/RFC5709, October
2009, <https://www.rfc-editor.org/info/rfc5709>. 2009, <https://www.rfc-editor.org/info/rfc5709>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<https://www.rfc-editor.org/info/rfc7474>.
Acknowledgments
Thanks to Tony Przygienda for his extensive review and useful
comments.
Authors' Addresses Authors' Addresses
Peter Psenak (editor) Peter Psenak (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Apollo Business Center Apollo Business Center
Mlynske nivy 43 Mlynske nivy 43
Bratislava 821 09 Bratislava 821 09
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
Ketan Jivan Talaulikar Ketan Talaulikar
Cisco Systems, Inc. Cisco Systems, Inc.
S.No. 154/6, Phase I, Hinjawadi S.No. 154/6, Phase I, Hinjawadi
PUNE, MAHARASHTRA 411 057 Pune, Maharashtra 411 057
India India
Email: ketant@cisco.com Email: ketant@cisco.com
Wim Henderickx Wim Henderickx
Nokia Nokia
Copernicuslaan 50 Copernicuslaan 50
Antwerp 2018 Antwerp 2018
Belgium Belgium
Email: wim.henderickx@nokia.com Email: wim.henderickx@nokia.com
Padma Pillay-Esnault Padma Pillay-Esnault
Huawei Huawei USA
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA United States of America
Email: padma@huawei.com Email: padma@huawei.com
 End of changes. 49 change blocks. 
146 lines changed or deleted 150 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/