[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

SPRING WG                                                     Ting. Liao
Internet-Draft                                                    Bo. Wu
Intended status: Standards Track                             Fangwei. Hu
Expires: January 7, 2016                                 ZTE Corporation
                                                      Bhumip. Khasnabish
                                                             ZTE TX Inc.
                                                            July 6, 2015


                         SPRING SID Allocation
                 draft-lw-spring-sid-allocation-02.txt

Abstract

   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths within IGP topologies by encoding paths as sequences of
   topological sub-paths, called "segments".  These segments are
   advertised by the link-state routing protocols (IS-IS and OSPF).  And
   a segment is identified by a Segment Routing ID (SID).  This document
   proposes a method to reduce the SID configuration in a SR domain.
   Only the selected SR nodes which named Segment Routing Management
   Nodes (SRMNs) are configured by NMS, while other SRs in the domain
   need zero-SR-configuration.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 7, 2016.

Copyright Notice

   Copyright (c) 2015 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



Liao, et al.             Expires January 7, 2016                [Page 1]


Internet-Draft            SPRING SID Allocation                July 2015


   (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Abbreviations . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  SID generation and allocation . . . . . . . . . . . . . . . .   4
     4.1.  SID generation  . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  SID allocation  . . . . . . . . . . . . . . . . . . . . .   5
   5.  IGP extension . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  The ISIS SID-allocation TLV . . . . . . . . . . . . . . .   6
     5.2.  The OSPF SID-Allocation TLV . . . . . . . . . . . . . . .   7
   6.  SID Allocation Ability extension  . . . . . . . . . . . . . .   8
     6.1.  The ISIS SR Capabilities Sub-TLV extension  . . . . . . .   8
     6.2.  The OSPF SR Capabilities TLV extension  . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Segment Routing (SR) allows for a flexible definition of end-to-end
   paths within IGP topologies by encoding paths as sequences of
   topological sub-paths, called "segments".  These segments are
   advertised by the link-state routing protocols (IS-IS and OSPF).  And
   a segment is identified by a Segment Identifier (SID).  A segment can
   be encoded as a MPLS label or an IPv6 address.  Typically a SID is
   configured by NMS and it very rarely changes.  When the SID
   configured, each node could send out its IGP TLV extensions which had
   described in [I-D.ietf-isis-segment-routing-extensions] and
   [I-D.ietf-ospf-segment-routing-extensions].

   In some situation where users expect to simply plug in a SR node and
   have it automatically enable Segment Routing.  One of the use cases
   is described in [I-D.kh-spring-ip-ran-use-case], with hundreds of
   CSGs in an IP RAN network, the configuration assigned by NMS could be
   very complexity.  And with the complexity of the network such as
   nodes adding and removing, the management on NMS is a hard work.  If
   the CSGs can plug and play, it will be very useful.  And the CSGs



Liao, et al.             Expires January 7, 2016                [Page 2]


Internet-Draft            SPRING SID Allocation                July 2015


   could be uploaded with zero-touch currently, by generating the ip
   address from MAC by default algorithm and with the ospf process
   default uploaded, have a mechanism to ensure the uniqueness of ip.
   Then the CSGs could be connected, and the topology will be collected
   by the ASGs.  With the mechanism described in this draft, there is no
   SR configuration on the CSGs, the CSGs could be zero-touch still,
   reduce the complexity of SR related configuration and reduce the
   complexity of NMS.

   This draft describes a mechanism to optimize SID allocation
   operation.

2.  Conventions and Abbreviations

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] .

   The following notations and abbreviations are used throughout this
   draft.

   ASG: Aggregation Site/Service Gateway.

   BS: Base Station.

   CSG: Cell Site Gateway.

   IP RAN: Internet Protocol RAN

   RAN: Radio Access Network.

   RNC: Radio Network Controller.

   RSG: Radio Service Gateway.

   SR: Segment Routing.

   SID: Segment Identifiers.

3.  Motivation

   As described in [I-D.kh-spring-ip-ran-use-case] , the IP RAN network
   scenario is shown in the figure 1.








Liao, et al.             Expires January 7, 2016                [Page 3]


Internet-Draft            SPRING SID Allocation                July 2015


                        ----------------
                       /                \
                      /                  \
         +------+   +----+             +----+      +----+     +----+
         |  BS  |---|CSG1|             |ASG1|------|RSG1|-----|RNC1|
         +------+   +-+--+             +----+      +----+     +----+
                      |      Access      |  Aggration |
                      |      Domain      |    Domain  |
         +------+   +-+--+             +----+      +----+     +----+
         |  BS  |---|CSG2|             |ASG2|------|RSG2|-----|RNC2|
         +------+   +----+             +----+      +----+     +----+
                       \                /
                        \              /
                         --------------

                         Figure 1 IP RAN Network Scenario

   There are hundreds of CSGs (Cell Site Gateway) and a few sets of ASGs
   (Aggregation Site/Service Gateway) in the Access Domain of an IP RAN
   network.  With the increase of mobile Internet traffic, more CSGs
   could be added to the Access Domain, and CSGs could be installed in
   wide area.  So, there is a great need to do little or no
   configuration on CSGs to avoid configuration operation.

   In current IP RAN implementation, as the CSGs could be uploaded with
   zero-touch, by generating the ip address from MAC by default
   algorithm and with the ospf process default uploaded, have a
   mechanism to ensure the uniqueness of ip.  Then the CSGs could be
   connected, and the topology will be collected by the ASGs.  ASGs are
   configured by NMS, and the configurations on CSGs are configured by
   ASGs, typical MPLS protocols like LDP protocol is used.  With SR
   replacing LDP, complexity in LDP configuration could be greatly
   reduced.  But in current SR process, each SR node should be
   configured by NMS, including the SR related configurations such as
   SIDs and SR algorithm and SR global blocks.

   If the configuration on CSGs still need to be came from ASGs, a
   specific mechanism is proposed in this draft to fulfill this
   requirement.  Like the network in the above figure, an ASG or both
   the ASGs could be selected as a SID management node to advertise CSGs
   and ASGs SID mapping to the whole SR domain.

4.  SID generation and allocation

   In the proposed mechanism, one or more Segment Routing Management
   Nodes (SRMNs) reside at SR nodes and advertise the SID mapping
   information for the various prefix associated with the SR nodes in
   the SR domain.



Liao, et al.             Expires January 7, 2016                [Page 4]


Internet-Draft            SPRING SID Allocation                July 2015


4.1.  SID generation

   The NMS configure the SRGB block to the SRMN.  The SRMN will generate
   SIDs to other nodes'router-ids and to the router-id of itself, the
   generation principle based on the configuration of the NMS or the
   default generation rule, the default allocation rule MAY be based on
   the numerically higher router-id with the higher SID allocated.

4.2.  SID allocation

   As described in section 3, when the SR node is powdered on, the IGP
   protocol as default function loaded, each node flooding out each
   router information in ISIS LSP or OSPF LSA when the ISIS adjacency or
   OSPF adjacency relations formed, and every node will acquire the
   router-ids of other nodes from the information (such as the IP
   address of router id) of IGP TLV.

   Then the SRMN generates the SIDs mapping to the router-ids and
   allocates the SIDs to each SR node by using the extension of SID
   Allocation TLV or the SID Binding TLV(as described in
   [I-D.ietf-isis-segment-routing-extensions] and
   [I-D.ietf-ospf-segment-routing-extensions]. )in the IGP packet,
   flooding the packet out.  In the SID Allocation TLV, it carries the
   router-id and SID mapping, and related algorithm type, and related
   multi-topology number.  And in one SID-Allocation TLV, it can carry
   one or more IP addresses.

   Optionally, If more than one SRMN assigned by the NMS, the SRMNs May
   flood out another extension which indicating having the capability to
   allocate SID, this extension is called the SR Allocation Ability
   extension and be included in the SR capabilities.  When other SR
   nodes receive more than one of the SRMN advertised the extension, the
   SR node could decide how to choose the Allocated SID, the choosing
   principle is based on the value of SRMNs' router id or system id, the
   maximum or the minimum value is chosen, and the SID allocated by the
   maximum or minimum id's SRMN be chosen.  When each SR node received
   the IGP packet with the SID Allocation TLV, it will know which SID is
   allocated to itself, and then the SR node sends out the prefix-SID
   sub-TLV in its IGP packet flooding out in the IGP area.

   Then each SR node will know the other SR nodes' SID, and the related
   algorithm will calculate the path to each SR node's SID.

   With the automatic uniform allocation by the SRMN in the IGP area,
   when a new node is added, the SRMN will know which SIDs had been
   allocated, and allocate an unused SID in the SRGB to the new node's
   IP address.  And if the node has moved, the SRMN will delete the
   related SID to the moving node's IP address and recycle this SID.



Liao, et al.             Expires January 7, 2016                [Page 5]


Internet-Draft            SPRING SID Allocation                July 2015


   The SID uniqueness is managed on the SRMN.

   If more than one SRMN assigned by the NMS, the SR Allocation Ability
   extension will be used, the detail information is described in
   section 4.2.

5.  IGP extension

   The SID Allocation TLV MAY be originated by any assigned router in an
   IS-IS domain or an OSPF domain.  As
   [I-D.ietf-ospf-segment-routing-extensions]  defines OSPF extension
   for the purpose of the advertisements of various SID values, new
   Opaque LSAs [RFC5250] are defined in
   [I-D.ietf-ospf-prefix-link-attr].  But the SID Allocation TLV is no
   need to binding with the prefix of the router or re-advertised by the
   router.  The SID Allocation TLV may be advertised in a new Opaque
   LSA.

5.1.  The ISIS SID-allocation TLV

   The SID Allocation TLV has Type TBD, and has the following format:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |     Length    |     Flags     |     Range     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      MT-ID    |    Algorithm  |           Prefix              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Prefix            |             SID   (variable)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 2 ISIS SID-allocation TLV

   o  Type: TBD.

   o  1 octet of Length: variable, in bytes.

   o  1 octet of flags.

   o  1 octets of Range: The 'Range' field provides the ability to
      specify a range of addresses and their allocated SIDs.  It is
      essentially a compression scheme to allocate a continuous Prefix
      and their continuous, corresponding SID/Label Block.  If a single
      SID is advertised then the range field MUST be set to one.  For
      range advertisements > 1, the number of addresses that need to be




Liao, et al.             Expires January 7, 2016                [Page 6]


Internet-Draft            SPRING SID Allocation                July 2015


      mapped into a Prefix-SID and the starting value of the Prefix-SID
      range.

   o  1 octet of MT-ID: Multi-Topology ID (as defined in [RFC4915]).

   o  1 octet of Algorithm: one octet identifying the algorithm type the
      Prefix-SID is associated.  The following value is defined by this
      document:

      *  0: IGP metric based Shortest Path Tree (SPT).

   o  4 octet of Prefix.

   o  4 octet of SID: according to the flags, it contains:

      *  A 32 bit index defining the offset in the SID/Label space
         advertised by this router using the encodings defined in
         Section 3.1.

      *  A 24 bit label where the 20 rightmost bits are used for
         encoding the label value.

5.2.  The OSPF SID-Allocation TLV

   The SID Allocation TLV has Type TBD, and has the following format:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |     Length    |     Flags     |     Range     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      MT-ID    |    Algorithm  |           Prefix              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Prefix            |             SID   (variable)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 3 OSPF SID-allocation TLV

   o  Type: TBD.

   o  1 octet of Length: variable, in bytes.

   o  1 octet of flags.

   o  1 octets of Range: The 'Range' field provides the ability to
      specify a range of addresses and their allocated SIDs.  It is
      essentially a compression scheme to allocate a continuous Prefix



Liao, et al.             Expires January 7, 2016                [Page 7]


Internet-Draft            SPRING SID Allocation                July 2015


      and their continuous, corresponding SID/Label Block.  If a single
      SID is advertised then the range field MUST be set to one.  For
      range advertisements > 1, the number of addresses that need to be
      mapped into a Prefix-SID and the starting value of the Prefix-SID
      range.

   o  1 octet of MT-ID: Multi-Topology ID (as defined in [RFC4915])

   o  1 octet of Algorithm: one octet identifying the algorithm type the
      Prefix-SID is associated.  The following value is defined by this
      document:

      *  0: IGP metric based Shortest Path Tree (SPT).

   o  4 octet of Prefix.

   o  4 octet of SID: according to the flags, it contains:

      *  A 32 bit index defining the offset in the SID/Label space
         advertised by this router using the encodings defined in
         Section 3.1.

      *  A 24 bit label where the 20 rightmost bits are used for
         encoding the label value.

6.  SID Allocation Ability extension

   With the compatibility consideration, nodes in the SR domain need to
   advertise its SR data-plane capability by using SR-Capabilities TLV
   in OSPF area or SR-Capabilities sub-TLV in ISIS area.  So the
   assigned router advertises its SID allocation capability, it may be
   included in SR-Capabilities Sub-TLV of ISIS or in SR-Capabilities TLV
   of OSPF, with the Special Flag to indicate it is an assigned router.

6.1.  The ISIS SR Capabilities Sub-TLV extension

   The ISIS SR Capabilities Sub-TLV (Type: TBD) is optional, MAY appear
   multiple times inside the Router Capability TLV and has following
   format:












Liao, et al.             Expires January 7, 2016                [Page 8]


Internet-Draft            SPRING SID Allocation                July 2015


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type        |     Length    |    Flags      |    Range      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Range (cont.)       | SID/Label Sub-TLV (variable)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 4 ISIS SR Capabilities Sub-TLV

   o  Type: TBD.

   o  1 octet of Length: variable, in bytes.

   o  1 octet of flags, the following are defined:

         0
         0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |I|V|A|         |
         +-+-+-+-+-+-+-+-+

   where:

   o  I-Flag: IPv4 flag.  If set, then the router is capable of outgoing
      IPv4 encapsulation on all interfaces.

   o  V-Flag: IPv6 flag.  If set, then the router is capable of outgoing
      IPv6 encapsulation on all interfaces.

   o  A-Flag: Allocation flag.  If set, then the router is capable of
      allocating SID capability.

   3 octets of Range: defining the number of values of the range from
   the starting value defined in the SID/Label Sub-TLV.

   SID/Label Sub-TLV: SID/Label value as defined in
   [I-D.ietf-isis-segment-routing-extensions].

6.2.  The OSPF SR Capabilities TLV extension

   As described in [I-D.ietf-ospf-segment-routing-extensions], the SID/
   Label Range TLV as an additional router capability of SR, it is a
   top-level TLV of the Router Information Opaque LSA (defined in
   [RFC4970] ).

   The SID/Label Range TLV MAY appear multiple times and has the
   following format:



Liao, et al.             Expires January 7, 2016                [Page 9]


Internet-Draft            SPRING SID Allocation                July 2015


   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Range Size                 |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sub-TLVs (variable)                    |
      +---------------------------------------------------------------+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 5 OSPF SR Capabilities TLV

   o  Type: TBD.

   o  1 octet of Length: variable, in bytes.

   o  Range Size: 3 octets of the SID/label range.

   o  Reserved: 1 octets, where the following extension are defined:

         0
         0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |A|             |
         +-+-+-+-+-+-+-+-+


   where:

   o  A-Flag: Allocation flag.  If set, then the router is capable of
      allocating SID capability.

   Sub-TLVs: Initially, the only supported Sub-TLV is the SID/Label TLV
   as defined in [I-D.ietf-ospf-segment-routing-extensions].

7.  Security Considerations

   TBD.

8.  Acknowledgements

   In progress.







Liao, et al.             Expires January 7, 2016               [Page 10]


Internet-Draft            SPRING SID Allocation                July 2015


9.  IANA Considerations

   TBD.

10.  Normative References

   [I-D.ietf-isis-segment-routing-extensions]
              Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
              Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
              Extensions for Segment Routing", draft-ietf-isis-segment-
              routing-extensions-05 (work in progress), June 2015.

   [I-D.ietf-ospf-prefix-link-attr]
              Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
              Advertisement", draft-ietf-ospf-prefix-link-attr-06 (work
              in progress), June 2015.

   [I-D.ietf-ospf-segment-routing-extensions]
              Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
              Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", draft-ietf-ospf-segment-
              routing-extensions-05 (work in progress), June 2015.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
              and R. Shakir, "Segment Routing Architecture", draft-ietf-
              spring-segment-routing-03 (work in progress), May 2015.

   [I-D.kh-spring-ip-ran-use-case]
              Khasnabish, B., hu, f., and L. Contreras, "Segment Routing
              in IP RAN use case", draft-kh-spring-ip-ran-use-case-02
              (work in progress), November 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC
              4915, June 2007.

   [RFC4970]  Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
              Shaffer, "Extensions to OSPF for Advertising Optional
              Router Capabilities", RFC 4970, July 2007.

   [RFC5250]  Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
              OSPF Opaque LSA Option", RFC 5250, July 2008.




Liao, et al.             Expires January 7, 2016               [Page 11]


Internet-Draft            SPRING SID Allocation                July 2015


Authors' Addresses

   Ting Liao
   ZTE Corporation
   No.50 Software Avenue
   Nanjing, Jiangsu  210012
   China

   Phone: +86 25 88018801
   Email: liao.ting@zte.com.cn


   Bo Wu
   ZTE Corporation
   No.50 Software Avenue
   Nanjing, Jiangsu  210012
   China

   Phone: +86 25 88018801
   Email: bo.wu@zte.com.cn


   Fangwei Hu
   ZTE Corporation
   No.889 Bibo Rd
   Shanghai  201203
   China

   Phone: +86 21 68896273
   Email: hu.fangwei@zte.com.cn


   Bhumip Khasnabish
   ZTE TX Inc.
   55 Madison Avenue, Suite 160
   Morristown, New Jersey  07960
   USA

   Phone: +001-781-752-8003
   Email: bhumip.khasnabish@ztetx.com











Liao, et al.             Expires January 7, 2016               [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/