rfc9296xml2.original.xml   rfc9296.xml 
<?xml version='1.0' ?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY nbsp "&#160;">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <!ENTITY zwsp "&#8203;">
nce.RFC.2119.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC2863 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <!ENTITY wj "&#8288;">
nce.RFC.2863.xml">
<!ENTITY RFC5309 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5309.xml">
<!ENTITY RFC7224 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7224.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY RFC8343 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8343.xml">
<!ENTITY RFC8561 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8561.xml">
<!ENTITY RFC6991 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6991.xml">
]> ]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-liu-lsr-p2poverla
<rfc docName="draft-liu-lsr-p2poverlan-12" ipr="trust200902" category="info"> n-12"
<front> number="9296" ipr="trust200902" category="info" obsoletes="" updates="" su
<title abbrev='IfStackTable for P2poverLAN interface'>Interface S bmissionType="independent" xml:lang="en" tocInclude="true" symRefs="true" versio
tack Table Definition and Example for Point-to-Point (P2P) Interface over LAN</t n="3" sortRefs="true">
itle>
<author initials="D." surname="Liu" fullname="Daiying Liu"> <front>
<organization>Ericsson</organization> <title abbrev="IfStackTable for P2poverLAN interface">ifStackTable for the P
<address> oint-to-Point (P2P) Interface over a LAN Type: Definition and Examples</title>
<postal> <seriesInfo name="RFC" value="9296"/>
<street>No.5 Lize East street</street> <author initials="D." surname="Liu" fullname="Daiying Liu">
<code>100102</code> <organization>Ericsson</organization>
<city>Beijing</city> <address>
<country>China</country> <postal>
</postal> <street>No.5 Lize East Street</street>
<email>harold.liu@ericsson.com</email> <code>100102</code>
</address> <city>Beijing</city>
</author> <country>China</country>
<author initials="J." surname="Halpern" fullname="Joel Halpern"> </postal>
<organization>Ericsson</organization> <email>harold.liu@ericsson.com</email>
<address> </address>
<email>joel.halpern@ericsson.com</email> </author>
</address> <author initials="J." surname="Halpern" fullname="Joel Halpern">
</author> <organization>Ericsson</organization>
<author initials="C." surname="Zhang" fullname="Congjie Zhang"> <address>
<organization>Ericsson</organization> <email>joel.halpern@ericsson.com</email>
<address> </address>
<email>congjie.zhang@ericsson.com</email> </author>
</address> <author initials="C." surname="Zhang" fullname="Congjie Zhang">
</author> <organization>Ericsson</organization>
<date year="2022" month="May" day="24"/> <address>
<area>General</area> <email>congjie.zhang@ericsson.com</email>
<keyword>RFC</keyword> </address>
<keyword>Internet-Draft</keyword> </author>
<keyword>XML</keyword> <date year="2022" month="August"/>
<keyword>Extensible Markup Language</keyword>
<abstract> <abstract>
<t>RFC 5309 defines the Point-to-Point (P2P) circuit type <t>RFC 5309 defines the Point-to-Point (P2P) circuit type, one of the two
, one of the two circuit types used in the link state routing protocols, circuit types used in the link-state routing protocols, and
and highlights that it is important to identify highlights that it is important to identify the
the correct circuit type when forming adjacencies, flooding correct circuit type when forming adjacencies, flooding
link state database packets, and monitoring the link state. link-state database packets, and monitoring the link state.
</t> </t>
<t> <t>
This document provides advice about the ifStack for the P2P interface o This document provides advice about the ifStack for the P2P interface o
ver LAN ifType ver a LAN Type
to facilitate operational control, maintenance and statistics. to facilitate operational control, maintenance, and statistics.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t><xref target="RFC5309"/> defines the P2P circuit type <t><xref target="RFC5309" format="default"/> defines the Point-to-Point (P
and highlights that it is important to identify the correct circuit type 2P) circuit type and highlights that it is important to identify the correct cir
when forming adjacencies, flooding link state da cuit type when forming adjacencies, flooding link-state database packets, and mo
tabase packets, and monitoring the link state. nitoring the link state.
</t> </t>
<t> <t>
To simplify configuration and operational control, it is helpful To simplify configuration and operational control, it is helpful
to represent the fact that an interface is to be considered to represent the fact that an interface is to be considered
a P2P interface over LAN type explicitly in the interface stack. This a P2P interface over a LAN type explicitly in the interface stack. This
enables, for example, routing protocols to automatically inherit enables, for example, routing protocols to automatically inherit
the correct operating mode from the interface stack without further conf iguration (No need to explicitly configure the P2P interface in routing protocol s). the correct operating mode from the interface stack without further conf iguration (i.e., there is no need to explicitly configure the P2P interface in r outing protocols).
</t> </t>
<t>It is helpful to map the P2P interface over LAN type in the interface m <t>It is helpful to map the P2P interface over a LAN type in the interface
anagement stack table. management stack table. If no entry specifies the lower layer of the P2P interf
If no entry specifies the P2P interface lower layer, management tools lo ace, then management tools lose the ability to
se the ability to
retrieve and measure properties specific to lower layers. retrieve and measure properties specific to lower layers.
</t> </t>
<t>The P2P interface over LAN type is intended to be used solely as a mean
s to signal in standard network management protocols <t>In standard network management protocols that make use of
that make use of ifStackTables that the upper layer interface is P2P int ifStackTables, the P2P interface over a LAN type is intended to be used
erface, and thus the upper and lower layers of P2P over LAN type solely as a means to signal that the upper-layer interface of link-data layer
will be expected to apply appropriate semantics: is a P2P interface. Thus, the upper and lower layers of P2P over a LAN type are
In general, P2P over LAN type higher layer SHOULD always be "ipForward" expected to apply appropriate semantics. In general, the higher layer of a P2
(Value 142, <xref target="Assignment"/>), P over a LAN type <bcp14>SHOULD</bcp14> be "ipForward" (value 142 in
and the P2P over LAN type lower layer SHOULD be any appropriate link dat <xref target="Assignment" format="default"/>), and the lower layer of P2P ove
a layer of "ipForward". r a LAN type <bcp14>SHOULD</bcp14> be any appropriate link-data layer of "ipForw
ard".
</t> </t>
<t>The assignment of 303, as the value for p2pOverLan ifType was made by E <t>The assignment of 303 as the value for the p2pOverLan ifType was made b
xpert Review <xref target="Assignment"/>. y Expert Review (see <xref target="Assignment" format="default"/> and <xref targ
So the purpose of this document is to request IANA to add this document et="RFC8126" format="default"/>).
as a reference to ifType 303, as well as The purpose of this document is to serve as a reference for ifType 303 by sugges
suggest how to use ifStackTable for the P2P interface over LAN type, and ting how the ifStackTable for the P2P interface over a LAN type is to be used an
provide examples. d providing examples.
</t> </t>
<t>It should be noted that this document reflects the operating model used on some routers. Other routers that use different models may not represent a P2 P as a separate interface. <t>It should be noted that this document reflects the operating model used on some routers. Other routers that use different models may not represent a P2 P as a separate interface.
</t> </t>
</section> </section>
<section title="Requirements Language"> <section numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Requirements Language</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this <t>
document are to be interpreted as described in <xref target="RFC2119"/> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<xref target="RFC8174"/>. IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="sec3" numbered="true" toc="default">
<name>Interface Stack Table for P2P Interface Type</name>
<section anchor="sec3_1" numbered="true" toc="default">
<name>P2P Interface: higher-layer-if and lower-layer-if</name>
<section anchor="sec3" title="Interface Stack Table for P2P Interface Type"> <t>If a device implements the IF-MIB <xref target="RFC2863" format="defau
<section anchor="sec3_1" title="P2P Interface higher-layer-if and lower-l lt"/>, then each entry in the "/interfaces/interface" list (see "A YANG Data Mod
ayer-if"> el for Interface Management" <xref target="RFC8343" format="default"/>) in the o
<t>If a device implements the IF-MIB <xref target="RFC2863"/>, each entry perational state is typically
in the mapped to one ifEntry as required in <xref target="RFC8343" format="default"/>.
"/interfaces/interface" list (in "Interface Management YANG") in the Therefore, the P2P interface over a LAN type should also be fully mapped to one
operational state is typically ifEntry by defining the "ifStackTable" ("higher-layer-if" and "lower-layer-if",
mapped to one ifEntry as required in <xref target="RFC8343"/>. Theref defined in <xref target="RFC8343" format="default"/>).
ore the P2P interface over LAN type </t>
should also be fully mapped to one ifEntry by defining the "ifStackTa <t>In the ifStackTable, the higher layer of the P2P interface over a LAN
ble" ("higher-layer-if" and "lower-layer-if", defined in <xref target="RFC8343"/ type <bcp14>SHALL</bcp14> be network layer "ipForward" to enable IP routing, an
>). d the lower layer of the P2P interface over a LAN type <bcp14>SHOULD</bcp14> be
</t> any link-data layer that can be bound to "ipForward", including "ethernetCsmacd"
<t>In ifStackTable the P2P interface over LAN type higher layer SHALL be , "ieee8023adLag", "l2vlan", and so on (defined in the iana-if-type YANG module
network layer "ipForward" <xref target="IANA-ifTYPE" format="default"/>).
to enable IP routing, </t>
and the P2P interface over LAN type lower layer SHOULD be any li <t>The P2P interface over the LAN type ifStackTable can be defined along
nk data layer that can be bound to "ipForward" the lines of the following example, which complies with <xref target="RFC8343"
including "ethernetCsmacd", "ieee8023adLag", "l2vlan", and so on format="default"/> and <xref target="RFC6991" format="default"/>.
(defined in IANA). In the example, "lower-layer-if" takes "ethernetCsmacd", but, in
</t> fact, "lower-layer-if" can be any other available link-data layer. See <xref tar
<t>The P2P interface over LAN type ifStackTable can be defined along the get="sec7" format="default"/> for more examples.
lines of following example </t>
(In the example, "lower-layer-if" takes "ethernetCsmacd" but in f <figure anchor="xml_happy_1">
act, "lower-layer-if" can be any other available link data layer. See <xref targ <sourcecode name="" type="" markers="true"><![CDATA[
et="sec7"/> for more examples)
which complies with <xref target="RFC8343"/> <xref target="RFC699
1"/>:
</t>
<figure align="center" anchor="xml_happy_1">
<artwork align="center"><![CDATA[
<CODE BEGINS>
<interface> <interface>
<name>isis_int</name> <name>isis_int</name>
<type>ianaift:ipForward</type> <type>ianaift:ipForward</type>
</interface> </interface>
<interface> <interface>
<name>eth1</name> <name>eth1</name>
<type>ianaift:ethernetCsmacd</type> <type>ianaift:ethernetCsmacd</type>
</interface> </interface>
skipping to change at line 142 skipping to change at line 132
<admin-status>down</admin-status> <admin-status>down</admin-status>
<oper-status>down</oper-status> <oper-status>down</oper-status>
<statistics> <statistics>
<discontinuity-time> <discontinuity-time>
2021-04-01T03:00:00+00:00 2021-04-01T03:00:00+00:00
</discontinuity-time> </discontinuity-time>
<!-- counters now shown here --> <!-- counters now shown here -->
</statistics> </statistics>
</interface> </interface>
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="sec3_2" numbered="true" toc="default">
<section anchor="sec3_2" title="P2P Interface Statistics"> <name>P2P Interface Statistics</name>
<t>Because multiple IP interfaces can be bound to one physical port, <t>Because multiple IP interfaces can be bound to one physical port,
the statistics on the physical port SHOULD be a complete set whi the statistics on the physical port <bcp14>SHOULD</bcp14> be a c
ch includes statistics of all upper layer interfaces. omplete set that includes statistics of all upper-layer interfaces.
Therefore, each p2p interface collects and displays traffic that Therefore, each P2P interface collects and displays traffic that
has been sent to it via has been sent to it via
higher layers or received from it via lower layers. higher layers or received from it via lower layers.
</t> </t>
</section> </section>
<section anchor="sec3_3" title="P2P Interface Administrative State">
<t>The P2P interface can be shutdown independently of the underlying inte <section anchor="sec3_3" numbered="true" toc="default">
rface. <name>P2P Interface Administrative State</name>
</t> <t>The P2P interface can be shut down independently of the underlying in
<t>If the P2P interface is administratively up, terface.
then the "oper-status", defined in <xref target="RFC8343"/>, of </t>
that interface SHALL fully reflect state of the underlying interface; <t>If the P2P interface is administratively up,
then the "oper-status" (defined in <xref target="RFC8343" format
="default"/>) of that interface <bcp14>SHALL</bcp14> fully reflect the state of
the underlying interface;
if the P2P interface is administratively down, if the P2P interface is administratively down,
then the "oper-status" of that interface SHALL be down. Examples then the "oper-status" of that interface <bcp14>SHALL</bcp14> be
can be found in <xref target="sec7"/>. down. Examples can be found in <xref target="sec7" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>The writeable attribute "admin-status" of p2povervlan ifType is inherit <t>The writable attribute "admin-status" of the p2povervlan ifType is inhe
ed from <xref target="RFC8343"/>. rited from <xref target="RFC8343" format="default"/>.
Other objects associated with the p2povervlan ifType are read-only. Other objects associated with the p2povervlan ifType are read-only.
With this in mind, the considerations discussed Section 7 of [RFC8343] o therwise apply to the p2povervlan ifType. With this in mind, the considerations discussed in <xref target="RFC8343 " sectionFormat="of" section="7"/> otherwise apply to the p2povervlan ifType.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t>In the Interface Types registry, IANA has assigned a value of 303 <t>In the "Interface Types (ifType)" registry, value 303 is assigned
for p2pOverLan <xref target="Assignment"/> with a reference of < to p2pOverLan <xref target="Assignment" format="default"/>. As this docume
xref target="RFC5309"/>. nt explains how the p2pOverLan (303) ifType is to be used, IANA has amended the
IANA is requested to amend the reference for that code point to reference for p2pOverLan (303) to point to this document (instead of <xref targe
be to this document t="RFC5309" format="default"/>) and
and to make a similar amendment in the YANG iana-if-type module made a similar amendment in the YANG iana-if-type module <xref target="IANA-ifTY
(originally specified in PE" format="default"/> (originally specified in <xref target="RFC7224" format="d
<xref target="RFC7224"/>) which currently points to <xref target efault"/>).
="RFC8561"/>, </t>
as this document explains how the ifType is to be used.
</t>
</section>
<section anchor="sec8" title="Acknowledgements">
<t>The authors would like to thank Rob Wilton for his reviews and valuable
comments and suggestions.</t>
</section> </section>
</middle> </middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2863.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5309.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7224.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8343.xml"/>
<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ce.RFC.8561.xml"/>-->
</references>
<references>
<name>Informative References</name>
<back> <reference anchor="Assignment" target="https://www.iana.org/assignments/
<references title="Normative references"> smi-numbers">
&RFC2119; <front>
&RFC2863; <title>Interface Types (ifType)</title>
&RFC5309; <author><organization>IANA</organization></author>
&RFC7224; </front>
&RFC8174; </reference>
&RFC8343;
&RFC8561;
</references>
<references title="Informative References"> <reference anchor="IANA-ifTYPE" target=" https://www.iana.org/assignment
<reference anchor="Assignment" target="https://www.iana.org/assignments/sm s/yang-parameters">
i-numbers/smi-numbers.xhtml#smi-numbers-5"> <front>
<front> <title>YANG Module Names</title>
<title>Interface Types (ifType)</title><a <author><organization>IANA</organization></author>
uthor/><date/></front> </front>
</reference> </reference>
&RFC6991;
</references>
<section anchor="sec7" title="Examples"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>In the case of underlying interface is VLAN sub-interface, the ifStack FC.6991.xml"/>
Table should be defined as: <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
</t> C.8126.xml"/>
<figure align="center" anchor="xml_happy_2"> </references>
<artwork align="center"><![CDATA[ </references>
<CODE BEGINS> <section anchor="sec7" numbered="true" toc="default">
<name>Examples</name>
<t>If the underlying interface is a VLAN sub-interface, the ifStackTable s
hould be defined as:
</t>
<figure anchor="xml_happy_2">
<sourcecode name="" type="" markers="true"><![CDATA[
<interface> <interface>
<name>isis_int</name> <name>isis_int</name>
<type>ianaift:ipForward</type> <type>ianaift:ipForward</type>
</interface> </interface>
<interface> <interface>
<name>eth1_valn1</name> <name>eth1_valn1</name>
<type>ianaift:l2vlan</type> <type>ianaift:l2vlan</type>
</interface> </interface>
skipping to change at line 238 skipping to change at line 238
<admin-status>down</admin-status> <admin-status>down</admin-status>
<oper-status>down</oper-status> <oper-status>down</oper-status>
<statistics> <statistics>
<discontinuity-time> <discontinuity-time>
2021-04-01T03:00:00+00:00 2021-04-01T03:00:00+00:00
</discontinuity-time> </discontinuity-time>
<!-- counters now shown here --> <!-- counters now shown here -->
</statistics> </statistics>
</interface> </interface>
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure> </figure>
<t>If the underlying interface is Link Aggregation Group (LAG), the ifStac
<t>In the case of underlying interface is LAG, the ifStackTable should be kTable should be defined as:
defined as: </t>
</t> <figure anchor="xml_happy_3">
<figure align="center" anchor="xml_happy_3"> <sourcecode name="" type="" markers="true"><![CDATA[
<artwork align="center"><![CDATA[
<CODE BEGINS>
<interface> <interface>
<name>isis_int</name> <name>isis_int</name>
<type>ianaift:ipForward</type> <type>ianaift:ipForward</type>
</interface> </interface>
<interface> <interface>
<name>eth1_lag1</name> <name>eth1_lag1</name>
<type>ianaift:ieee8023adLag</type> <type>ianaift:ieee8023adLag</type>
</interface> </interface>
skipping to change at line 274 skipping to change at line 271
<admin-status>down</admin-status> <admin-status>down</admin-status>
<oper-status>down</oper-status> <oper-status>down</oper-status>
<statistics> <statistics>
<discontinuity-time> <discontinuity-time>
2021-04-01T03:00:00+00:00 2021-04-01T03:00:00+00:00
</discontinuity-time> </discontinuity-time>
<!-- counters now shown here --> <!-- counters now shown here -->
</statistics> </statistics>
</interface> </interface>
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure> </figure>
<t>If the P2P interface and underlying interface are both administratively
<t>In the case of P2P interface and underlying interface are both adminis up and the underlying interface operational status is up:
tratively up, and the underlying interface operational status is up: </t>
</t> <figure anchor="xml_happy_4">
<figure align="center" anchor="xml_happy_4"> <sourcecode name="" type="" markers="true"><![CDATA[
<artwork align="center"><![CDATA[
<CODE BEGINS>
<interface> <interface>
<name>p2p</name> <name>p2p</name>
<type>ianaift:p2pOverLan</type> <type>ianaift:p2pOverLan</type>
<higher-layer-if>isis_int</higher-layer-if> <higher-layer-if>isis_int</higher-layer-if>
<lower-layer-if>eth1</lower-layer-if> <lower-layer-if>eth1</lower-layer-if>
<admin-status>up</admin-status> <admin-status>up</admin-status>
<oper-status>up</oper-status> <oper-status>up</oper-status>
</interface> </interface>
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure> </figure>
<t>If the P2P interface and underlying interface are administratively up b
<t>In the case of P2P interface and underlying interface are administrati ut the underlying interface operational status is down:
vely up, but the underlying interface operational status is down: </t>
</t> <figure anchor="xml_happy_5">
<figure align="center" anchor="xml_happy_5"> <sourcecode name="" type="" markers="true"><![CDATA[
<artwork align="center"><![CDATA[
<CODE BEGINS>
<interface> <interface>
<name>p2p</name> <name>p2p</name>
<type>ianaift:p2pOverLan</type> <type>ianaift:p2pOverLan</type>
<higher-layer-if>isis_int</higher-layer-if> <higher-layer-if>isis_int</higher-layer-if>
<lower-layer-if>eth1</lower-layer-if> <lower-layer-if>eth1</lower-layer-if>
<admin-status>up</admin-status> <admin-status>up</admin-status>
<oper-status>down</oper-status> <oper-status>down</oper-status>
</interface> </interface>
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure> </figure>
<t>If the P2P interface is administratively down:
<t>In the case of P2P interface is administratively down: </t>
</t> <figure anchor="xml_happy_6">
<figure align="center" anchor="xml_happy_6"> <sourcecode name="" type="" markers="true"><![CDATA[
<artwork align="center"><![CDATA[
<CODE BEGINS>
<interface> <interface>
<name>p2p</name> <name>p2p</name>
<type>ianaift:p2pOverLan</type> <type>ianaift:p2pOverLan</type>
<higher-layer-if>isis_int</higher-layer-if> <higher-layer-if>isis_int</higher-layer-if>
<lower-layer-if>eth1</lower-layer-if> <lower-layer-if>eth1</lower-layer-if>
<admin-status>down</admin-status> <admin-status>down</admin-status>
<oper-status>down</oper-status> <oper-status>down</oper-status>
</interface> </interface>
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure> </figure>
<t>If the P2P interface is administratively up but the underlying interfac
<t>In the case of P2P interface is administratively up but underlying is e is administratively down:
administratively down: </t>
</t> <figure anchor="xml_happy_7">
<figure align="center" anchor="xml_happy_7"> <sourcecode name="" type="" markers="true"><![CDATA[
<artwork align="center"><![CDATA[
<CODE BEGINS>
<interface> <interface>
<name>p2p</name> <name>p2p</name>
<type>ianaift:p2pOverLan</type> <type>ianaift:p2pOverLan</type>
<higher-layer-if>isis_int</higher-layer-if> <higher-layer-if>isis_int</higher-layer-if>
<lower-layer-if>eth1</lower-layer-if> <lower-layer-if>eth1</lower-layer-if>
<admin-status>up</admin-status> <admin-status>up</admin-status>
<oper-status>down</oper-status> <oper-status>down</oper-status>
</interface> </interface>
<CODE ENDS> ]]></sourcecode>
]]></artwork>
</figure> </figure>
</section> </section>
</back>
<section anchor="sec8" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Rob Wilton"/> for hi
s reviews and valuable comments and suggestions.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 36 change blocks. 
251 lines changed or deleted 250 lines changed or added

This html diff was produced by rfcdiff 1.48.