Skip to main content

Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC)
draft-mglt-ipsecme-ikev2-diet-esp-extension-04

Revision differences

Document history

Date Rev. By Action
2024-03-18
04 Tero Kivinen IETF WG state changed to Adopted by a WG from Call For Adoption By WG Issued
2024-03-18
04 Daniel Migault New version available: draft-mglt-ipsecme-ikev2-diet-esp-extension-04.txt
2024-03-18
04 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2024-03-18
04 Daniel Migault Uploaded new revision
2023-12-30
03 (System) Document has expired
2023-11-27
03 Tero Kivinen
Internet-Draft    OSPF Extensions for Segment Routing          May 2017

        NP-Flag: No-PHP flag.  If set, then the penultimate …
Internet-Draft    OSPF Extensions for Segment Routing          May 2017

        NP-Flag: No-PHP flag.  If set, then the penultimate hop MUST
        NOT pop the Prefix-SID before delivering packets to the node
        that advertised the Prefix-SID.

        M-Flag: Mapping Server Flag.  If set, the SID was advertised by
        a Segment Routing Mapping Server as described in
        [I-D.filsfils-spring-segment-routing-ldp-interop].

        E-Flag: Explicit-Null Flag.  If set, any upstream neighbor of
        the Prefix-SID originator MUST replace the Prefix-SID with the
        Explicit-NULL label (0 for IPv4) before forwarding the packet.

        V-Flag: Value/Index Flag.  If set, then the Prefix-SID carries
        an absolute value.  If not set, then the Prefix-SID carries an
        index.

        L-Flag: Local/Global Flag.  If set, then the value/index
        carried by the Prefix-SID has local significance.  If not set,
        then the value/index carried by this Sub-TLV has global
        significance.

        Other bits: Reserved.  These MUST be zero when sent and are
        ignored when received.

      MT-ID: Multi-Topology ID (as defined in [RFC4915]).

      Algorithm: Single octet identifying the algorithm the Prefix-SID
      is associated with as defined in Section 3.1.

      A router receiving a Prefix-SID from a remote node and with an
      algorithm value that such remote node has not advertised in the
      SR-Algorithm sub-TLV (Section 3.1) MUST ignore the Prefix-SID sub-
      TLV.

      SID/Index/Label: According to the V and L flags, it contains
      either:

        A 32-bit index defining the offset in the SID/Label space
        advertised by this router.

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

  If multiple Prefix-SIDs are advertised for the same prefix, the
  receiving router MUST use the first encoded SID and MAY use
  subsequent SIDs.

Psenak, et al.          Expires November 23, 2017              [Page 13]
Internet-Draft    OSPF Extensions for Segment Routing          May 2017

  When propagating Prefix-SIDs between areas, if multiple prefix-SIDs
  are advertised for a prefix, an implementation SHOULD preserve the
  original order when advertising prefix-SIDs to other areas.  This
  allows implementations that only support a single Prefix-SID to have
  a consistent view across areas.

  When calculating the outgoing label for the prefix, the router MUST
  take into account the E and P flags advertised by the next-hop router
  if that router advertised the SID for the prefix.  This MUST be done
  regardless of whether the next-hop router contributes to the best
  path to the prefix.

  The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for
  Prefix-SIDs allocated to inter-area prefixes that are originated by
  the ABR based on intra-area or inter-area reachability between areas,
  unless the advertised prefix is directly attached to the ABR.

  The NP-Flag (No-PHP) MUST be be set and the E-flag MUST be clear for
  Prefix-SIDs allocated to redistributed prefixes, unless the
  redistributed prefix is directly attached to the ASBR.

  If the NP-Flag is not set, then any upstream neighbor of the Prefix-
  SID originator MUST pop the Prefix-SID.  This is equivalent to the
  penultimate hop popping mechanism used in the MPLS dataplane.  In
  such case, MPLS EXP bits of the Prefix-SID are not preserved for the
  final destination (the Prefix-SID being removed).  If the NP-flag is
  not set then the received E-flag is ignored.

  If the NP-flag is set then:

      If the E-flag is not set, then any upstream neighbor of the
      Prefix-SID originator MUST keep the Prefix-SID on top of the
      stack.  This is useful when the originator of the Prefix-SID must
      stitch the incoming packet into a continuing MPLS LSP to the final
      destination.  This could occur at an Area Border Router (prefix
      propagation from one area to another) or at an AS Boundary Router
      (prefix propagation from one domain to another).

      If the E-flag is set, then any upstream neighbor of the Prefix-SID
      originator MUST replace the Prefix-SID with an Explicit-NULL
      label.  This is useful, e.g., when the originator of the Prefix-
      SID is the final destination for the related prefix and the
      originator wishes to receive the packet with the original EXP
      bits.

  When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at
  reception.

Psenak, et al.          Expires November 23, 2017              [Page 14]
Internet-Draft    OSPF Extensions for Segment Routing          May 2017

  As the Mapping Server does not specify the originator of a prefix
  advertisement, it is not possible to determine PHP behavior solely
  based on the Mapping Server advertisement.  However, PHP behavior
  SHOULD be done in following cases:

      The Prefix is intra-area type and the downstream neighbor is the
      originator of the prefix.

      The Prefix is inter-area type and downstream neighbor is an ABR,
      which is advertising prefix reachability and is also generating
      the Extended Prefix TLV with the A-flag set for this prefix as
      described in section 2.1 of [RFC7684].

      The Prefix is external type and downstream neighbor is an ASBR,
      which is advertising prefix reachability and is also generating
      the Extended Prefix TLV with the A-flag set for this prefix as
      described in section 2.1 of [RFC7684].

  When a Prefix-SID is advertised in an Extended Prefix Range TLV, then
  the value advertised in the Prefix SID Sub-TLV is interpreted as a
  starting SID value.

  Example 1: If the following router addresses (loopback addresses)
  need to be mapped into the corresponding Prefix SID indexes:

            Router-A: 192.0.2.1/32, Prefix-SID: Index 1
            Router-B: 192.0.2.2/32, Prefix-SID: Index 2
            Router-C: 192.0.2.3/32, Prefix-SID: Index 3
            Router-D: 192.0.2.4/32, Prefix-SID: Index 4

  then the Prefix field in the Extended Prefix Range TLV would be set
  to 192.0.2.1, Prefix Length would be set to 32, Range Size would be
  set to 4, and the Index value in the Prefix-SID Sub-TLV would be set
  to 1.

  Example 2: If the following prefixes need to be mapped into the
  corresponding Prefix-SID indexes:

            192.0.2.0/30, Prefix-SID: Index 51
            192.0.2.4/30, Prefix-SID: Index 52
            192.0.2.8/30, Prefix-SID: Index 53
            192.0.2.12/30, Prefix-SID: Index 54
            192.0.2.16/30, Prefix-SID: Index 55
            192.0.2.20/30, Prefix-SID: Index 56
            192.0.2.24/30, Prefix-SID: Index 57

Psenak, et al.          Expires November 23, 2017              [Page 15]
Internet-Draft    OSPF Extensions for Segment Routing          May 2017IETF WG state changed to Call For Adoption By WG Issued
2023-11-27
03 Tero Kivinen Notification list changed to none
2023-11-27
03 Tero Kivinen Changed group to IP Security Maintenance and Extensions (IPSECME)
2023-11-27
03 Tero Kivinen Changed stream to IETF
2023-11-02
03 Tero Kivinen Added to session: IETF-118: ipsecme  Thu-1200
2023-07-19
03 Tero Kivinen Added to session: IETF-117: ipsecme  Wed-2230
2023-06-28
03 Daniel Migault New version available: draft-mglt-ipsecme-ikev2-diet-esp-extension-03.txt
2023-06-28
03 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2023-06-28
03 Daniel Migault Uploaded new revision
2022-11-14
02 (System) Document has expired
2022-05-13
02 Daniel Migault New version available: draft-mglt-ipsecme-ikev2-diet-esp-extension-02.txt
2022-05-13
02 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2022-05-13
02 Daniel Migault Uploaded new revision
2018-12-28
01 (System) Document has expired
2018-11-04
01 Tero Kivinen Added to session: IETF-103: ipsecme  Wed-1350
2018-06-26
01 Tobias Guggemos New version available: draft-mglt-ipsecme-ikev2-diet-esp-extension-01.txt
2018-06-26
01 (System) New version approved
2018-06-26
01 (System) Request for posting confirmation emailed to previous authors: Tobias Guggemos , Daniel Migault
2018-06-26
01 Tobias Guggemos Uploaded new revision
2018-04-30
00 (System) Document has expired
2017-10-29
00 Cindy Morgan This document now replaces draft-mglt-6lo-diet-esp-context-ikev2-extension instead of None
2017-10-29
00 Cindy Morgan Reviewed suggested replacement relationships: draft-mglt-6lo-diet-esp-context-ikev2-extension
2017-10-27
00 (System) Added suggested replacement relationships: draft-mglt-6lo-diet-esp-context-ikev2-extension
2017-10-27
00 (System) This document now replaces None instead of None
2017-10-27
00 Daniel Migault New version available: draft-mglt-ipsecme-ikev2-diet-esp-extension-00.txt
2017-10-27
00 (System) New version approved
2017-10-27
00 Daniel Migault Request for posting confirmation emailed  to submitter and authors: Tobias Guggemos , Daniel Migault
2017-10-27
00 Daniel Migault Uploaded new revision