draft-ietf-lsvr-l3dl-04.txt   draft-ietf-lsvr-l3dl-05.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Arrcus & Internet Initiative Japan Internet-Draft Arrcus & Internet Initiative Japan
Intended status: Standards Track R. Austein Intended status: Standards Track R. Austein
Expires: November 8, 2020 K. Patel Expires: November 26, 2020 K. Patel
Arrcus Arrcus
May 7, 2020 May 25, 2020
Layer 3 Discovery and Liveness Layer 3 Discovery and Liveness
draft-ietf-lsvr-l3dl-04 draft-ietf-lsvr-l3dl-05
Abstract Abstract
In Massive Data Centers, BGP-SPF and similar routing protocols are In Massive Data Centers, BGP-SPF and similar routing protocols are
used to build topology and reachability databases. These protocols used to build topology and reachability databases. These protocols
need to discover IP Layer 3 attributes of links, such as neighbor IP need to discover IP Layer 3 attributes of links, such as neighbor IP
addressing, logical link IP encapsulation abilities, and link addressing, logical link IP encapsulation abilities, and link
liveness. This Layer 3 Discovery and Liveness protocol collects liveness. This Layer 3 Discovery and Liveness protocol collects
these data, which may then be disseminated using BGP-SPF and similar these data, which may then be disseminated using BGP-SPF and similar
protocols. protocols.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 November 8, 2020. This Internet-Draft will expire on November 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 11, line 24 skipping to change at page 11, line 24
For the purpose of computing a checksum, the checksum field itself is For the purpose of computing a checksum, the checksum field itself is
assumed to be zero. assumed to be zero.
The following code describes a suggested algorithm. This The following code describes a suggested algorithm. This
specification avoids mandatory to implement, algorithm agility, etc. specification avoids mandatory to implement, algorithm agility, etc.
What matters is that the same algorithm is used consistently in any What matters is that the same algorithm is used consistently in any
deployment. deployment.
Sum up 32-bit unsigned ints in a 64-bit long, then take the high- Sum up 32-bit unsigned ints in a 64-bit long, then take the high-
order section, shift it right, rotate, add it in, repeat until zero. order section, shift it right filling on the left with zeros, rotate,
add it in, repeat until the high order 32 bits are all zero.
<CODE BEGINS> <CODE BEGINS>
#include <stddef.h> #include <stddef.h>
#include <stdint.h> #include <stdint.h>
/* The F table from Skipjack, and it would work for the S-Box. */ /* The F table from Skipjack, and it would work for the S-Box. */
static const uint8_t sbox[256] = { static const uint8_t sbox[256] = {
0xa3,0xd7,0x09,0x83,0xf8,0x48,0xf6,0xf4,0xb3,0x21,0x15,0x78, 0xa3,0xd7,0x09,0x83,0xf8,0x48,0xf6,0xf4,0xb3,0x21,0x15,0x78,
0x99,0xb1,0xaf,0xf9,0xe7,0x2d,0x4d,0x8a,0xce,0x4c,0xca,0x2e, 0x99,0xb1,0xaf,0xf9,0xe7,0x2d,0x4d,0x8a,0xce,0x4c,0xca,0x2e,
0x52,0x95,0xd9,0x1e,0x4e,0x38,0x44,0x28,0x0a,0xdf,0x02,0xa0, 0x52,0x95,0xd9,0x1e,0x4e,0x38,0x44,0x28,0x0a,0xdf,0x02,0xa0,
skipping to change at page 18, line 9 skipping to change at page 18, line 9
Key Length is a 16-bit field denoting the length in octets of the Key Key Length is a 16-bit field denoting the length in octets of the Key
itself, not including the Auth Type or the Key Length. If the Auth itself, not including the Auth Type or the Key Length. If the Auth
Type is zero, then the Key Length MUST also be zero, and there MUST Type is zero, then the Key Length MUST also be zero, and there MUST
BE no Key data. BE no Key data.
The Key is specific to the operational environment. A failure to The Key is specific to the operational environment. A failure to
authenticate is a failure to start the L3DL session, an ERROR PDU authenticate is a failure to start the L3DL session, an ERROR PDU
MUST BE sent (Error Code 3), and HELLOs MUST be restarted. MUST BE sent (Error Code 3), and HELLOs MUST be restarted.
Although delay and jitter in responding with an OPEN were specified
above, beware of load created by long strings of authentication
failures and retries.
The Serial Number is that of the last received and processed PDU. The Serial Number is that of the last received and processed PDU.
This allows a receiver sending an OPEN to tell the sender that the This allows a receiver sending an OPEN to tell the sender that the
receiver wants to resume a session and the sender only needs to send receiver wants to resume a session and the sender only needs to send
data more recent than the Serial Number. If this OPEN is not trying data more recent than the Serial Number. If this OPEN is not trying
to restart a lost session, the Serial Number MUST BE set to zero. to restart a lost session, the Serial Number MUST BE set to zero.
The Signature fields are described in Section 8 and in an asymmetric The Signature fields are described in Section 8 and in an asymmetric
key environment serve as a proof of possession of the signing auth key environment serve as a proof of possession of the signing auth
data by the sender. data by the sender.
skipping to change at page 20, line 15 skipping to change at page 20, line 15
The Signature fields are described in Section 8. The Signature fields are described in Section 8.
12.1. Retransmission 12.1. Retransmission
If a PDU sender expects an ACK, e.g. for an OPEN, an Encapsulation, a If a PDU sender expects an ACK, e.g. for an OPEN, an Encapsulation, a
VENDOR PDU, etc., and does not receive the ACK for a configurable VENDOR PDU, etc., and does not receive the ACK for a configurable
time (default one second), and the interface is live at layer 2, the time (default one second), and the interface is live at layer 2, the
sender resends the PDU using exponential back-off, see [RFC1122]. sender resends the PDU using exponential back-off, see [RFC1122].
This cycle MAY be repeated a configurable number of times (default This cycle MAY be repeated a configurable number of times (default
three) before it is considered a failure. The session MAY BE three) before it is considered a failure. The session MAY BE
considered closed this in case of this ACK failure. considered closed in this case of this ACK failure.
If the link is broken at layer 2, retransmission MAY BE retried when If the link is broken at layer 2, retransmission MAY BE retried when
the link is restored. the link is restored.
13. The Encapsulations 13. The Encapsulations
Once the devices know each other's LLEIs, know each other's upper Once the devices know each other's LLEIs, know each other's upper
layer (L2.5 and L3) identities, have means to ensure link state, layer (L2.5 and L3) identities, have means to ensure link state,
etc., the L3DL session is considered established, and the devices etc., the L3DL session is considered established, and the devices
SHOULD exchange L3 interface encapsulations, L3 addresses, and L2.5 SHOULD exchange L3 interface encapsulations, L3 addresses, and L2.5
skipping to change at page 33, line 8 skipping to change at page 33, line 8
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
S., and J. Dong, "BGP-LS extensions for Segment Routing S., and J. Dong, "BGP-LS extensions for Segment Routing
BGP Egress Peer Engineering", draft-ietf-idr-bgpls- BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
segment-routing-epe-19 (work in progress), May 2019. segment-routing-epe-19 (work in progress), May 2019.
[I-D.ietf-lsvr-bgp-spf] [I-D.ietf-lsvr-bgp-spf]
Patel, K., Lindem, A., Zandi, S., and W. Henderickx, Patel, K., Lindem, A., Zandi, S., and W. Henderickx,
"Shortest Path Routing Extensions for BGP Protocol", "Shortest Path Routing Extensions for BGP Protocol",
draft-ietf-lsvr-bgp-spf-08 (work in progress), March 2020. draft-ietf-lsvr-bgp-spf-09 (work in progress), May 2020.
[I-D.ymbk-lsvr-l3dl-signing] [I-D.ymbk-lsvr-l3dl-signing]
Bush, R. and R. Austein, "Layer 3 Discovery and Liveness Bush, R. and R. Austein, "Layer 3 Discovery and Liveness
Signing", draft-ymbk-lsvr-l3dl-signing-01 (work in Signing", draft-ymbk-lsvr-l3dl-signing-01 (work in
progress), May 2020. progress), May 2020.
[IANA-PEN] [IANA-PEN]
"IANA Private Enterprise Numbers", "IANA Private Enterprise Numbers",
<https://www.iana.org/assignments/enterprise-numbers/ <https://www.iana.org/assignments/enterprise-numbers/
enterprise-numbers>. enterprise-numbers>.
 End of changes. 8 change blocks. 
7 lines changed or deleted 12 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/