Extended DNS Errors
draft-ietf-dnsop-extended-error-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8914.
|
|
|---|---|---|---|
| Authors | Warren "Ace" Kumari , Evan Hunt , Roy Arends , Wes Hardaker , David C Lawrence | ||
| Last updated | 2018-12-20 | ||
| Replaces | draft-wkumari-dnsop-extended-error | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8914 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dnsop-extended-error-03
TEAS Working Group Fabio Peruzzini
Internet Draft TIM
Intended status: Informational Jean-Francois Bouquier
Vodafone
Italo Busi
Huawei
Daniel King
Old Dog Consulting
Daniele Ceccarelli
Ericsson
Expires: December 2020 June 17, 2020
Applicability of Abstraction and Control of Traffic Engineered
Networks (ACTN) to Packet Optical Integration (POI)
draft-peru-teas-actn-poi-applicability-04
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 17, 2020.
Peruzzini et al. Expires December 17, 2020 [Page 1]
Internet-Draft ACTN POI June 2020
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This document considers the applicability of the IETF Abstraction
and Control of Traffic Engineered Networks (ACTN) to Packet Optical
Integration (POI), and IP and Optical DWDM domain internetworking.
In this document, we highlight the IETF protocols and YANG data
models that may be used for the ACTN and control of POI networks,
with particular focus on the interfaces between the MDSC (Multi-
Domain Service Coordinator) and the underlying Packet and Optical
Domain Controllers (P-PNC and O-PNC) to support POI use cases.
Table of Contents
1. Introduction...................................................3
2. Reference Scenario.............................................4
2.1. Generic Assumptions.......................................6
3. Multi-Layer Topology Coordination..............................7
3.1. Discovery of existing Och, ODU, IP links, IP tunnels and IP
services.......................................................7
3.1.1. Common YANG Models used at the MPI...................8
3.1.1.1. YANG models used at the Optical MPIs............8
3.1.1.2. Required YANG models at the Packet MPIs.........8
3.1.2. Inter-domain link Discovery..........................9
3.2. Provisioning of an IP Link/LAG over DWDM.................10
3.2.1. YANG models used at the MPIs........................10
3.2.1.1. YANG models used at the Optical MPIs...........10
3.2.1.2. Required YANG models at the Packet MPIs........11
3.2.2. IP Link Setup Procedure.............................11
Peruzzini et al. Expires December 17, 2020 [Page 2]
Internet-Draft ACTN POI June 2020
3.3. Provisioning of an IP link/LAG over DWDM with path
constraints...................................................12
3.3.1. YANG models used at the MPIs........................13
3.4. Provisioning Link Members to an existing LAG.............13
3.4.1. YANG Models used at the MPIs........................13
4. Multi-Layer Recovery Coordination.............................13
4.1. Ensuring Network Resiliency during Maintenance Events....13
4.2. Router Port Failure......................................13
5. Service Coordination for Multi-Layer network..................14
5.1. L2/L3VPN/VN Service Request by the Customer..............17
5.2. Service and Network Orchestration........................19
5.3. IP/MPLS Domain Controller and NE Functions...............23
5.3.1. Scenario A: Shared Tunnel Selection.................23
5.3.1.1. Domain Tunnel Selection........................24
5.3.1.2. VPN/VRF Provisioning for L3VPN.................25
5.3.1.3. VSI Provisioning for L2VPN.....................26
5.3.1.4. Inter-domain Links Update......................26
5.3.1.5. End-to-end Tunnel Management...................26
5.3.2. Scenario B: Isolated VN/Tunnel Establishment........27
5.4. Optical Domain Controller and NE Functions...............27
5.5. Orchestrator-Controllers-NEs Communication Protocol Flows29
6. Security Considerations.......................................31
7. Operational Considerations....................................31
8. IANA Considerations...........................................31
9. References....................................................31
9.1. Normative References.....................................31
9.2. Informative References...................................32
10. Acknowledgments..............................................34
11. Authors' Addresses...........................................34
1. Introduction
Packet Optical Integration (POI) is an advanced use case of traffic
engineering. In wide-area networks, a packet network based on the
Internet Protocol (IP) and possibly Multiprotocol Label Switching
(MPLS) is typically deployed on top of an optical transport network
that uses Dense Wavelength Division Multiplexing (DWDM). In many
existing network deployments, the packet and the optical networks
are engineered and operated independently of each other. There are
technical differences between the technologies (e.g., routers versus
optical switches) and the corresponding network engineering and
planning methods (e.g., inter-domain peering optimization in IP vs.
dealing with physical impairments in DWDM, or very different time
scales). In addition, customers and customer needs vary between a
packet and an optical network, and it is not uncommon to use
different vendors in both domains. Last but not least, state-of-the-
Peruzzini et al. Expires December 17, 2020 [Page 3]
Internet-Draft ACTN POI June 2020
art packet and optical networks use sophisticated but complex
technologies, and for a network engineer, it may not be trivial to
be a full expert in both areas. As a result, packet and optical
networks are often managed by different technical and organizational
silos.
This separation is inefficient for many reasons. Both capital
expenditure (CAPEX) and operational expenditure (OPEX) could be
significantly reduced by better integrating the packet and the
optical network. Multi-layer online topology insight can speed up
troubleshooting (e.g., alarm correlation) and network operation
(e.g., coordination of maintenance events), multi-layer offline
topology inventory can improve service quality (e.g., detection of
diversity constraint violations) and multi-layer traffic engineering
can use the available network capacity more efficiently (e.g.,
coordination of restoration). In addition, provisioning workflows
can be simplified or automated as needed across layers (e.g, to
achieve bandwidth on demand, or to perform maintenance events).
Fully leveraging these benefits requires integration between the
management and control of the packet and the optical network. The
Abstraction and Control of TE Networks (ACTN) framework outlines the
functional components and interfaces between a Multi-Domain Service
Coordinator (MDSC) and Provisioning Network Controllers (PNCs) that
can be used for coordinating the packet and optical layers.
In this document, critical use cases for Packet Optical Integration
(POI) are described. We outline how and what is required for the
packet and the optical layer to interact to set up and operate
services. The IP networks are operated as a client of optical
networks. The use cases are ordered by increasing the level of
integration and complexity. For each multi-layer use case, the
document analyzes how to use the interfaces and data models of the
ACTN architecture.
The document also captures the current issues with ACTN and POI
deployment. By understanding the level of standardization and
potential gaps, it will help to better assess the feasibility of
integration between IP and optical DWDM domain, in an end-to-end
multi-vendor network.
2. Reference Scenario
This document uses "Reference Scenario 1" with multiple Optical
domains and multiple Packet domains. The following Figure 1 shows
this scenario in case of two Optical domains and two Packet domains:
Peruzzini et al. Expires December 17, 2020 [Page 4]
Internet-Draft ACTN POI June 2020
+----------+
| MDSC |
+-----+----+
|
+-----------+-----+------+-----------+
| | | |
+----+----+ +----+----+ +----+----+ +----+----+
| P-PNC 1 | | O-PNC 1 | | O-PNC 2 | | P-PNC 2 |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
| \ / |
+-------------------+ \ / +-------------------+
CE / PE ASBR \ | / / ASBR PE \ CE
o--/---o o---\-|-------|--/---o o---\--o
\ : : / | | \ : : /
\ : AS Domain 1 : / | | \ : AS Domain 2 : /
+-:---------------:-+ | | +-:---------------:--+
: : | | : :
: : | | : :
+-:---------------:------+ +-------:---------------:--+
/ : : \ / : : \
/ o...............o \ / o...............o \
\ Optical Domain 1 / \ Optical Domain 2 /
\ / \ /
+------------------------+ +--------------------------+
Figure 1 - Reference Scenario 1
The ACTN architecture, defined in [RFC8453], is used to control this
multi-domain network where each Packet PNC (P-PNC) is responsible
for controlling its IP domain (AS), and each Optical PNC (O-PNC) is
responsible for controlling its Optical Domain.
The MDSC is responsible for coordinating the whole multi-domain
multi-layer (Packet and Optical) network. A specific standard
interface (MPI) permits MDSC to interact with the different
Provisioning Network Controller (O/P-PNCs).
The MPI interface presents an abstracted topology to MDSC hiding
technology-specific aspects of the network and hiding topology
details depending on the policy chosen regarding the level of
abstraction supported. The level of abstraction can be obtained
based on P-PNC and O-PNC configuration parameters (e.g. provide the
potential connectivity between any PE and any ABSR in an MPLS-TE
network).
Peruzzini et al. Expires December 17, 2020 [Page 5]
Internet-Draft ACTN POI June 2020
The MDSC in Figure 1 is responsible for multi-domain and multi-layer
coordination across multiple Packet and Optical domains, as well as
to provide IP services to different CNCs at its CMIs using YANG-
based service models (e.g., using L2SM [RFC8466], L3SM [RFC8299]).
The multi-domain coordination mechanisms for the IP tunnels
supporting these IP services are described in section 5. In some
cases, the MDSC could also rely on the multi-layer POI mechanisms,
described in this draft, to support multi-layer optimizations for
these IP services and tunnels.
In the network scenario of Figure 1, it is assumed that:
o The domain boundaries between the IP and Optical domains are
congruent. In other words, one Optical domain supports
connectivity between Routers in one and only one Packet Domain;
o Inter-domain links exist only between Packet domains (i.e.,
between ASBR routers) and between Packet and Optical domains
(i.e., between routers and ROADMs). In other words, there are no
inter-domain links between Optical domains;
o The interfaces between the routers and the ROADM's are "Ethernet"
physical interfaces;
o The interfaces between the ASBR routers are "Ethernet" physical
interfaces.
2.1. Generic Assumptions
This section describes general assumptions which are applicable at
all the MPI interfaces, between each PNC (optical or packet) and the
MDSC, and also to all the scenarios discussed in this document.
The data models used on these interfaces are assumed to use the YANG
1.1 Data Modeling Language, as defined in [RFC7950].
The RESTCONF protocol, as defined in [RFC8040], using the JSON
representation, defined in [RFC7951], is assumed to be used at these
interfaces.
As required in [RFC8040], the "ietf-yang-library" YANG module
defined in [RFC8525] is used to allow the MDSC to discover the set
of YANG modules supported by each PNC at its MPI.
Peruzzini et al. Expires December 17, 2020 [Page 6]
Internet-Draft ACTN POI June 2020
3. Multi-Layer Topology Coordination
In this scenario, the MSDC needs to discover the network topology,
at both WDM and IP layers, in terms of nodes (NEs) and links,
including inter-AS domain links as well as cross-layer links.
Each PNC provides to the MDSC an abstract topology view of the WDM
or of the IP topology of the domain it controls. This topology is
abstracted in the sense that some detailed NE information is hidden
at the MPI, and all or some of the NEs and related physical links
are exposed as abstract nodes and logical (virtual) links, depending
on the level of abstraction the user requires. This detailed
information is vital to understand both the inter-AS domain links
(seen by each controller as UNI interfaces but as I-NNI interfaces
by the MDSC) as well as the cross-layer mapping between IP and WDM
layer.
The MDSC also maintains an up-to-date network inventory of both IP
and WDM layers through the use of IETF notifications through MPI
with the PNCs.
For the cross-layer links, the MDSC needs to be capable of
automatically correlating physical ports information from the
routers (single link or bundle links for link aggregation groups -
LAG) to client ports in the ROADM.
3.1. Discovery of existing Och, ODU, IP links, IP tunnels and IP
services
Typically, an MDSC must be able to automatically discover network
topology of both WDM and IP layers (links and NE, links between two
domains), this assumes the following:
o An abstract view of the WDM and IP topology must be available;
o MDSC must keep an up-to-date network inventory of both IP and WDM
layers, and it should be possible to correlate such information
(e.g., which port, lambda/OTSi, the direction it is used by a
specific IP service on the WDM equipment);
o It should be possible at MDSC level to easily correlate WDM and
IP layers alarms to speed-up troubleshooting.
Peruzzini et al. Expires December 17, 2020 [Page 7]
Internet-Draft ACTN POI June 2020
3.1.1. Common YANG Models used at the MPI
Both optical and packet PNCs use the following common topology YANG
models at the MPI to report their abstract topologies:
o The Base Network Model, defined in the "ietf-network" YANG module
of [RFC8345];
o The Base Network Topology Model, defined in the "ietf-network-
topology" YANG module of [RFC8345], which augments the Base
Network Model;
o The TE Topology Model, defined in the "ietf-te-topology" YANG
module of [TE-TOPO], which augments the Base Network Topology
Model.
These IETF YANG models are generic and augmented by technology-
specific YANG modules as described in the following sections.
3.1.1.1. YANG models used at the Optical MPIs
The optical PNC also uses at least the following technology-specific
topology YANG models, providing WDM and Ethernet technology-specific
augmentations of the generic TE Topology Model:
o The WSON Topology Model, defined in the "ietf-wson-topology" YANG
modules of [WSON-TOPO], or the Flexi-grid Topology Model, defined
in the "ietf-flexi-grid-topology" YANG module of [Flexi-TOPO].
o The Ethernet Topology Model, defined in the "ietf-eth-te-
topology" YANG module of [CLIENT-TOPO]
The WSON Topology Model or, alternatively, the Flexi-grid Topology
model is used to report the fixed-grid or, respectively, the
flexible-grid DWDM network topology (e.g., ROADMs and OMS links).
The Ethernet Topology Model is used to report the Ethernet access
links on the edge ROADMs.
3.1.1.2. Required YANG models at the Packet MPIs
The Packet PNC also uses at least the following technology-specific
topology YANG models, providing IP and Ethernet technology-specific
augmentations of the generic Topology Models:
Peruzzini et al. Expires December 17, 2020 [Page 8]quot; IANA
registry, the initial values for which are defined in the following
sub-sections.
4.1. INFO-CODEs for use with RESPONSE-CODE: SERVFAIL(2)
4.1.1. SERVFAIL Extended DNS Error Code 1 - DNSSEC Bogus
The resolver attempted to perform DNSSEC validation, but validation
ended in the Bogus state. The R flag should not be set.
4.1.2. SERVFAIL Extended DNS Error Code 2 - DNSSEC Indeterminate
The resolver attempted to perform DNSSEC validation, but validation
ended in the Indeterminate state. The R flag should not be set.
4.1.3. SERVFAIL Extended DNS Error Code 3 - Signature Expired
The resolver attempted to perform DNSSEC validation, but the
signature was expired. The R flag should not be set.
4.1.4. SERVFAIL Extended DNS Error Code 4 - Signature Not Yet Valid
The resolver attempted to perform DNSSEC validation, but the
signatures received were not yet valid. The R flag should not be
set.
4.1.5. SERVFAIL Extended DNS Error Code 5 - Unsupported DNSKEY
Algorithm
The resolver attempted to perform DNSSEC validation, but a DNSKEY
RRSET contained only unknown algorithms. The R flag should be set.
4.1.6. SERVFAIL Extended DNS Error Code 6 - Unsupported DS Algorithm
The resolver attempted to perform DNSSEC validation, but a DS RRSET
contained only unknown algorithms. The R flag should be set.
4.1.7. SERVFAIL Extended DNS Error Code 7 - DNSKEY missing
A DS record existed at a parent, but no DNSKEY record could be found
for the child. The R flag should not be set.
Kumari, et al. Expires June 23, 2019 [Page 6]
Internet-Draft draft-ietf-dnsop-extended-error December 2018
4.1.8. SERVFAIL Extended DNS Error Code 8 - RRSIGs missing
The resolver attempted to perform DNSSEC validation, but no RRSIGs
could be found for at least one RRset where RRSIGs were expected.
4.1.9. SERVFAIL Extended DNS Error Code 9 - No Zone Key Bit Set
The resolver attempted to perform DNSSEC validation, but no Zone Key
Bit was set in a DNSKEY.
4.2. INFO-CODEs for use with RESPONSE-CODE: REFUSED(5)
4.2.1. REFUSED Extended DNS Error Code 1 - Lame
An authoritative resolver that receives a query (with the RD bit
clear) for a domain for which it is not authoritative SHOULD include
this EDE code in the REFUSED response. Implementations should set
the R flag in this case (another nameserver might not be lame).
4.2.2. REFUSED Extended DNS Error Code 2 - Prohibited
An authoritative or recursive resolver that receives a query from an
"unauthorized" client can annotate its REFUSED message with this
code. Examples of "unauthorized" clients are recursive queries from
IP addresses outside the network, blacklisted IP addresses, local
policy, etc.
Implementations SHOULD allow operators to define what to set the R
flag to in this case.
4.3. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3)
4.3.1. NXDOMAIN Extended DNS Error Code 1 - Blocked
The resolver attempted to perfom a DNS query but the domain is
blacklisted due to a security policy. The R flag should not be set.
5. IANA Considerations
5.1. new Extended Error Code EDNS Option
This document defines a new EDNS(0) option, entitled "Extended DNS
Error", assigned a value of TBD1 from the "DNS EDNS0 Option Codes
(OPT)" registry [to be removed upon publication:
[http://www.iana.org/assignments/dns-parameters/dns-
parameters.xhtml#dns-parameters-11]
Kumari, et al. Expires June 23, 2019 [Page 7]
Internet-Draft draft-ietf-dnsop-extended-error December 2018
Value Name Status Reference
----- ---------------- ------ ------------------
TBD Extended DNS Error TBD [ This document ]
5.2. New Extended Error Code EDNS Option
This document defines a new double-index IANA registry table, where
the first index value is the RCODE value and the second index value
is the INFO-CODE from the Extended DNS Error EDNS option defined in
this document. The IANA is requested to create and maintain this
"Extended DNS Error codes" registry. The codepoint space for each
INFO-CODE index is to be broken into 3 ranges:
o 0 - 3583: Specification required.
o 3584 - 3839: First Come First Served.
o 3840 - 4095: Experimental / Private use
A starting set of entries, based on the contents of this document, is
as follows:
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 1
Purpose: DNSSEC Bogus
Reference: Section 4.1.1
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 2
Purpose: DNSSEC Indeterminate
Reference: Section 4.1.2
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 3
Purpose: Signature Expired
Reference: Section 4.1.3
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 4
Purpose: Signature Not Yet Valid
Reference: Section 4.1.4
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 5
Purpose: Unsupported DNSKEY
Reference: Section 4.1.5
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 6
Purpose: Unsupported DS Algorithm
Kumari, et al. Expires June 23, 2019 [Page 8]
Internet-Draft draft-ietf-dnsop-extended-error December 2018
Reference: Section 4.1.6
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 7
Purpose: DNSKEY missing
Reference: Section 4.1.7
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 8
Purpose: RRSIGs missing
Reference: Section 4.1.8
RESPONSE-CODE: 2 (SERVFAIL)
INFO-CODE: 9
Purpose: No Zone Key Bit Set
Reference: Section 4.1.9
RESPONSE-CODE: 3 (NXDOMAIN)
INFO-CODE: 1
Purpose: Blocked
Reference: Section 4.3.1
RESPONSE-CODE: 5 (REFUSED)
INFO-CODE: 1
Purpose: Lame
Reference: Section 4.2.1
RESPONSE-CODE: 5 (REFUSED)
INFO-CODE: 2
Purpose: Prohibited
Reference: Section 4.2.2
6. Security Considerations
Though DNSSEC continues to be deployed, unfortunately a significant
number of clients (~11% according to [GeoffValidation]) that receive
a SERVFAIL from a validating resolver because of a DNSSEC validaion
issue will simply ask the next (potentially non-validating) resolver
in their list, and thus don't get any of the protections which DNSSEC
should provide. This is very similar to a kid asking his mother if
he can have another cookie. When the mother says "No, it will ruin
your dinner!", going off and asking his (more permissive) father and
getting a "Yes, sure, have a cookie!".
This information is unauthenticated information, and an attacker (e.g
MITM or malicious recursive server) could insert an extended error
response into already untrusted data -- ideally clients and resolvers
would not trust any unauthenticated information, but until we live in
Kumari, et al. Expires June 23, 2019 [Page 9]
Internet-Draft draft-ietf-dnsop-extended-error December 2018
an era where all DNS answers are authenticated via DNSSEC or other
mechanisms, there are some tradeoffs. As an example, an attacker who
is able to insert the DNSSEC Bogus Extended Error into a packet could
instead simply reply with a fictitious address (A or AAAA) record.
The R bit hint and extended error information are informational -
implementations can choose how much to trust this information and
validating resolvers / stubs may choose to put a different weight on
it.
7. Acknowledgements
The authors wish to thank Joe Abley, Mark Andrews, Peter DeVries,
Peter van Dijk, Donald Eastlake, Bob Harold, Evan Hunt, Geoff Huston,
Shane Kerr, Edward Lewis, Carlos M. Martinez, George Michelson, Petr
Spacek, Ondrej Sury, Loganaden Velvindron, and Paul Vixie. They also
vaguely remember discussing this with a number of people over the
years, but have forgotten who all they were -- if you were one of
them, and are not listed, please let us know and we'll acknowledge
you.
I also want to thank the band "Infected Mushroom" for providing a
good background soundtrack (and to see if I can get away with this!)
Another author would like to thank the band "Mushroom Infectors".
This was funny at the time we wrote it, but I cannot remember why...
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
8.2. Informative References
[GeoffValidation]
IANA, "A quick review of DNSSEC Validation in today's
Internet", June 2016, <http://www.potaroo.net/
presentations/2016-06-27-dnssec.pdf>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.
Internet-Draft ACTN POI June 2020
o The L3 Topology Model, defined in the "ietf-l3-unicast-topology"
YANG modules of [RFC8346], which augments the Base Network
Topology Model
o The Ethernet Topology Model, defined in the "ietf-eth-te-
topology" YANG module of [CLIENT-TOPO], which augments the TE
Topology Model
o The L3-TE Topology Model, defined in the "ietf-l3-te-topology"
YANG modules of [L3-TE-TOPO], which augments the L3 Topology
Model
The Ethernet Topology Model is used to report the Ethernet links
between the IP routers and the edge ROADMs as well as the
inter-domain links between ASBRs, while the L3 Topology Model is
used to report the IP network topology (e.g., IP routers and IP
links).
The L3-TE Topology Model reports the relationship between the IP
routers and LTPs provided by the L3 Topology Model and the
underlying Ethernet nodes and LTPs provided by the Ethernet Topology
Model.
3.1.2. Inter-domain link Discovery
In the reference network of Figure 1, there are two types of
inter-domain links:
o Links between two IP domains/ASBRs (ASes)
o Links between an IP router and a ROADM
Both types of links are Ethernet physical links.
The inter-domain link information is reported to the MDSC by the two
adjacent PNCs, controlling the two ends of the inter-domain link,
using the Ethernet Topology Model defined in [CLIENT-TOPO].
The MDSC can understand how to merge these inter-domain Ethernet
links together using the plug-id attribute defined in the TE
Topology Model [TE-TOPO], as described in as described in section
4.3 of [TE-TOPO].
A more detailed description of how the plug-id can be used to
discover inter-domain link is also provided in section 5.1.4 of
[TNBI].
Peruzzini et al. Expires December 17, 2020 [Page 9]
Internet-Draft ACTN POI June 2020
Both types of inter-domain Ethernet links are discovered using the
plug-id attributes reported in the Ethernet Topologies exposed by
the two adjacent PNCs.
The MDSC, when discovering an Ethernet inter-domain link between two
Ethernet LTPs which are associated with two IP LTPs, reported in the
IP Topologies exposed by the two adjacent P-PNCs, can also discover
an inter-domain IP link/adjacency between these two IP LTPs.
Two options are possible to discover these inter-domain Ethernet
links:
1. Static configuration
2. LLDP [IEEE 802.1AB] automatic discovery
Since the static configuration requires an administrative burden to
configure network-wide unique identifiers, the automatic discovery
solution based on LLDP is preferable when LLDP is supported.
As outlined in [TNBI], the encoding of the plug-id namespace as well
as of the LLDP information within the plug-id value is
implementation specific and needs to be consistent across all the
PNCs.
3.2. Provisioning of an IP Link/LAG over DWDM
In this scenario, the MSDC needs to coordinate the creation of an IP
link, or a LAG, between two routers through a DWDM network.
It is assumed that the MDSC has already discovered the whole network
topology as described in section 3.1.
3.2.1. YANG models used at the MPIs
3.2.1.1. YANG models used at the Optical MPIs
The optical PNC uses at least the following YANG models:
o The TE Tunnel Model, defined in the "ietf-te" YANG module of
[TE-TUNNEL]
o The WSON Tunnel Model, defined in the "ietf-wson-tunnel" YANG
modules of [WSON-TUNNEL], or the Flexi-grid Media Channel Model,
defined in the "ietf-flexi-grid-media-channel" YANG module of
[Flexi-MC]
Peruzzini et al. Expires December 17, 2020 [Page 10]
Internet-Draft ACTN POI June 2020
o The Ethernet Client Signal Model, defined in the "ietf-eth-tran-
service" YANG module of [CLIENT-SIGNAL]
The TE Tunnel model is generic and augmented by technology-specific
models such as the WSON Tunnel Model and the Flexi-grid Media
Channel Model.
The WSON Tunnel Model or, alternatively, the Flexi-grid Media
Channel Model are used to setup connectivity within the DWDM network
depending on whether the DWDM optical network is based on fixed grid
or flexible-grid.
The Ethernet Client Signal Model is used to configure the steering
of the Ethernet client traffic between Ethernet access links and TE
Tunnels, which in this case could be either WSON Tunnels or
Flexi-Grid Media Channels. This model is generic and applies to any
technology-specific TE Tunnel: technology-specific attributes are
provided by the technology-specific models which augment the generic
TE-Tunnel Model.
3.2.1.2. Required YANG models at the Packet MPIs
The Packet PNC uses at least the following topology YANG models:
o The Base Network Model, defined in the "ietf-network" YANG module
of [RFC8345] (see section 3.1.1)
o The Base Network Topology Model, defined in the "ietf-network-
topology" YANG module of [RFC8345] (see section 3.1.1)
o The L3 Topology Model, defined in the "ietf-l3-unicast-topology"
YANG modules of [RFC8346] (see section 3.1.1.1)
If, as discussed in section 3.2.2, IP Links created over DWDM can be
automatically discovered by the P-PNC, the IP Topology is needed
only to report these IP Links after being discovered by the P-PNC.
The IP Topology can also be used to configure the IP Links created
over DWDM.
3.2.2. IP Link Setup Procedure
The MDSC requires the O-PNC to setup a WDM Tunnel (either a WSON
Tunnel or a Flexi-grid Tunnel) within the DWDM network between the
two Optical Transponders (OTs) associated with the two access links.
Peruzzini et al. Expires December 17, 2020 [Page 11]
Internet-Draft ACTN POI June 2020
The Optical Transponders are reported by the O-PNC as Trail
Termination Points (TTPs), defined in [TE-TOPO], within the WDM
Topology. The association between the Ethernet access link and the
WDM TTP is reported by the Inter-Layer Lock (ILL) identifiers,
defined in [TE-TOPO], reported by the O-PNC within the Ethernet
Topology and WDM Topology.
The MDSC also requires the O-PNC to steer the Ethernet client
traffic between the two access Ethernet Links over the WDM Tunnel.
After the WDM Tunnel has been setup and the client traffic steering
configured, the two IP routers can exchange Ethernet packets between
themselves, including LLDP messages.
If LLDP [IEEE 802.1AB] is used between the two routers, the P-PNC
can automatically discover the IP Link being set up by the MDSC. The
IP LTPs terminating this IP Link are supported by the ETH LTPs
terminating the two access links.
Otherwise, the MDSC needs to require the P-PNC to configure an IP
Link between the two routers: the MDSC also configures the two ETH
LTPs which support the two IP LTPs terminating this IP Link.
3.3. Provisioning of an IP link/LAG over DWDM with path constraints
MDSC must be able to provision an IP link with a fixed maximum
latency constraint, or with the minimum latency available constraint
within each domain but as well inter-domain when required (e.g. by
monitoring traffic KPIs trends for this IP link). Through the O-PNC
fixed latency path/minimum latency path is chosen between PE and
ASBR in each optical domain. Then MDSC needs to select the inter-AS
domain with less latency (in case we have several interconnection
links) to have the right low latency constraint fulfilled end-to-end
across domains.
MDSC must be able to automatically create two IP links between two
routers, over DWDM network, with physical path diversity (avoiding
SRLGs communicated by O-PNCs to the MDSC).
MDSC must be responsible for routing each of this IP links through
different inter-AS domain links so that end-to-end IP links are
fully disjoint.
Optical connectivity must be set up accordingly by MDSC through O-
PNCs.
Peruzzini et al. Expires December 17, 2020 [Page 12]
Kumari, et al. Expires June 23, 2019 [Page 10]
Internet-Draft draft-ietf-dnsop-extended-error December 2018
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
editor.org/info/rfc8094>.
Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ]
From -00 to -01:
o Address comments from IETF meeting.
o document copying the response code
o mention zero length fields are ok
o clarify lookup procedure
o mention that table isn't done
From -03 to -IETF 00:
o Renamed to draft-ietf-dnsop-extended-error
From -02 to -03:
o Added David Lawrence -- I somehow missed that in last version.
From -00 to -01;
o Fixed up some of the text, minor clarifications.
Authors' Addresses
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: warren@kumari.net
Evan Hunt
ISC
950 Charter St
Redwood City, CA 94063
US
Email: each@isc.org
Kumari, et al. Expires June 23, 2019 [Page 11]
Internet-Draft draft-ietf-dnsop-extended-error December 2018
Roy Arends
ICANN
Email: roy.arends@icann.org
Wes Hardaker
USC/ISI
P.O. Box 382
Davis, CA 95617
US
Email: ietf@hardakers.net
David C Lawrence
Oracle + Dyn
150 Dow St
Manchester, NH 03101
US
Email: tale@dd.org
Kumari, et al. Expires June 23, 2019 [Page 12]