Re: [mpls] Review of draft-song-mpls-extension-header-09

[Haoyu Song <[e-mail]>]

Hi Loa,

Thanks for the review. Please find my responses in the attached document. 

Best regards,
Haoyu

-----Original Message-----
From: mpls <[e-mail]> On Behalf Of Loa Andersson
Sent: Monday, August 29, 2022 8:10 AM
To: Stewart Bryant <[e-mail]>; mpls <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
Subject: Re: [mpls] Review of draft-song-mpls-extension-header-09

All,

I have also reviewed the document. Please find, comments, suggestions and questions in the included word file.

/Loa

On 2022-08-24 19:24, Stewart Bryant wrote:
> 
> I know that I was involved in the text in the very early days, but I am worried about it. Things have moved on and it is not clear that the approach which is basically to clone an IPv6 EH is the right approach for where we are now.
> 
> Certainly there are a lot of things that the OTD needs to consider in detail before committing to this design.
> 
> I do not think we should adopt this draft at the stage.
> 
> Detailed comments below.
> 
> Stewart
> 
> MPLS                                                        H. Song, Ed.
> Internet-Draft                                    Futurewei Technologies
> Intended status: Standards Track                                   Z. Li
> Expires: 12 February 2023                                        T. Zhou
>                                                                    Huawei
>                                                              L. Andersson
>                                                  Bronze Dragon Consulting
>                                                                  Z. Zhang
>                                                          Juniper Networks
>                                                                 R. Gandhi
>                                                           J. Rajamanickam
>                                                           J. Bhattacharya
>                                                             Cisco Systems
>                                                            11 August 
> 2022
> 
> SB> The author list exceeds the allowed number, so needs to be trimmed. It would be useful if this was done at adoption.
> 
> ==========
> 
> 
> 
> 1.  Motivation
> 
>     Some applications require adding sizable instructions and/or metadata
>     to user packets within a network.  Such examples include In-situ OAM
>     (IOAM) [RFC9197] and Service Function Chaining (SFC) [RFC7665].
> 
> SB> This is a big change that we are proposing to make to MPLS. Do we have any indication that there is planned deployment of those protocols and whether further use is stalled on this capability?
> 
> ==========
> 
>     New
>     applications are emerging.  It is possible that the instructions and/
>     or metadata for multiple applications are stacked together in one
>     packet to support a compound service.
> 
>     Conceivably, such instructions and/or metadata would be encoded as
>     new headers and encapsulated in user packets.  Such headers may
>     require to be processed in fast path due to performance
>     considerations.  Moreover, such headers may require being attended at
>     each hop on the forwarding path (i.e., hop-by-hop or HBH) or at
>     designated end nodes (i.e., end-to-end or E2E).
> 
> SB> This is all a bit speculative. I think we need to state (or reference) a much tighter use case given the significant cost of putting this in Silicon.
> 
>     The need and requirements to support such applications in MPLS
>     networks, i.e., MPLS Network Actions (MNA), are described in
>     [I-D.ietf-mpls-mna-usecases] and [I-D.ietf-mpls-mna-requirements].
>     It is clear that some headers should be located after the MPLS label
>     stack.  We call such a header "post-stack extension header".  The
>     encapsulation of post-stack extension header(s) poses some challenges
>     to MPLS networks, because the MPLS label stack contains no explicit
>     indicator for the upper layer protocols by design.
> 
>     While the post-stack extension header needs some in-stack indicator
>     to signal its presence, the mechanism specification is out of the
>     scope of this document.  The indication for the presence of the post-
>     stack extension header can be achieved using several mechanisms,
>     including carrying an SPL or signaling it with the label FEC as
>     described in [I-D.ietf-mpls-mna-fwk].  In this document, we focus on
>     the encoding and encapsulation of the post-stack extension headers in
>     an MPLS packet.
> 
> SB> The text to this point could usefully be trimmed and made less speculative.
> 
> SB> At the time of publication as an RFC (if this is published as an RFC) the situation will be that: this information needs to be carried and this is the/one of the ways that it is to be carried.
> 
>     The similar problem has been tackled for some applications before.
> 
> SB> Need to cite the examples with references in the following:
> 
> ==========
> 
>     *  Some previous work such as G-ACH [RFC5586] was explicitly defined
>        for control channel only but what we need is for the user packets.
> 
> SB> We can change that constraint if it is the right thing to do. It was introduced as a result to concern for the h/w likely to be available at the time, but it is not cast in stone.
> 
>     To solve these problems, we introduce post-stack extension header as
>     a general and extensible means to support new MNAs which involve
>     instructions and/or meta data.  The concept is similar to IPv6
>     extension headers which offer a huge potential for extending IPv6's
>     capability (e.g, network security, SRv6 [RFC8754], network
>     programming [RFC8986], SFC [I-D.ietf-spring-sr-service-programming],
>     etc.).  Thanks to the existence of extension headers, it is
>     straightforward to introduce new network services into IPv6 networks.
>     For example, it has been proposed to carry IOAM header
>     [I-D.ietf-ippm-ioam-ipv6-options] as a new extension header option in
>     IPv6 networks.
> 
> SB> I think the point is the the eh mechanism is a mechanism, whether that makes it easy to introduce new eh onto a forwarder or into an operating network is a different matter, particularly in the HxH case.
> 
>     Nevertheless, when applying the extension header to MPLS, some issues
>     of the IPv6 EH should be avoided:
> 
>     *  IPv6's extension headers are chained with the original upper layer
>        protocol headers in a flat stack.  One must scan all the extension
>        headers to access the upper layer protocol headers and the
>        payload.  This is inconvenient and raises some performance
>        concerns for some applications (e.g., DPI and ECMP).  The new
>        scheme for MPLS header extension needs to improve this.
> 
>     *  [RFC8200] enforces many constraints to IPv6 extension headers
>        (e.g., EH can only be added or deleted by the end nodes specified
>        by the IP addresses in the IPv6 header, and there is only one Hop-
>        by-Hop EH that can be processed on the path nodes), which are not
>        suitable for MPLS networks.  For example, MPLS label stacks are
>        added and changed in network, and there could be tunnel within
>        tunnel, so the extension headers need more flexibility.
> 
> SB> Be careful here. The constraints in IPv6 are MTU and Security.
> 
> SB> MTU is less of an non-issue because of the domain specific nature of most MPLS deployments. The security issue may well apply to us as well.
> 
> 2.  MPLS Extension Header
> 
>     The concept and design of the MPLS post-stack extension header comply
>     with the requirements laid out in [I-D.ietf-mpls-mna-requirements].
>     We highlight some specific design requirements for the post-stack
>     extension headers in MPLS networks:
> 
>     Performance:  Unnecessary label stack scanning for a label and the
>        full extension header stack scanning for the upper layer protocol
>        should be avoided.  The extension headers a node needs to process
>        should be located as close to the MPLS label stack as possible.
> 
> SB> How does the design achieve this?
> 
>        Each extension header is better to serve only one application to
>        avoid the need of packing multiple TLV options in one extension
>        header.
> 
> 
> 
> 
> Song, et al.            Expires 12 February 2023                [Page 4]
> 

> Internet-Draft      MPLS Post-Stack Extension Header         August 2022
> 
> 
>     Scalability:  New applications can be supported by introducing new
>        extension headers.  Multiple extension headers can be easily
>        stacked together to support multiple services simultaneously.
> 
> SB> ... until you get to the max header length of the on path routers.
> 
>     Backward Compatibility:  Legacy devices which do not recognize the
>        extension header option should still be able to forward the
>        packets as usual.
> 
> SB> That may or may not be a good thing.
> 
>        If a device recognizes some of the extension
>        headers but not the others in an extension header stack, it can
>        process the known headers only while ignoring the others.
> 
> SB> ... again which may or may not be a good thing.
> 
>     Flexibility:  A node can be configured to process or not process any
>        EH.  Any tunnel end nodes in the MPLS domain can add new EH to the
>        packets which shall be removed on the other end of the tunnel.
> 
> SB> That is not unique to this proposal
> 
> =========
> 
> 
>     Following the MPLS label stack is the 4-octet Header of Extension
>     Headers (HEH), which indicates the total number of extension headers
>     in this packet, the overall length of the extension headers, the type
>     of the original upper layer header, and the type of the next header.
>     The format of the HEH is shown in Figure 2.
> 
>         0           1         2          3
>         0123 4567 89012345 67890123 45678901
>        +----+----+--------+--------+--------+
>        | R  |EHC |  EHTL  |  OUL   |   NH   |
>        +----+----+--------+--------+--------+
> 
>                              Figure 2: HEH Format
> 
>     The meaning of the fields in an HEH is as follows:
> 
>     R:  4-bit reserved.  The nibble value means to avoid conflicting with
>        IP version numbers and other well-defined semantics
>        [I-D.kbbma-mpls-1stnibble].
> 
>     EHC:  4-bit unsigned integer for the Extension Header Counter.  This
>        field keeps the total number of extension headers included in this
>        packet.  It does not count the original upper layer protocol
>        headers.
> 
> SB> What do you mean here? The payload headers?
> 
>        At most 15 EHs are allowed in one packet.
> 
>     EHTL:  8-bit unsigned integer for the Extension Header Total Length
>        in 4-octet units.  This field keeps the total length of the
>        extension headers in this packet, not including the HEH itself.
> 
>     OUL:  8-bit Original Upper Layer protocol number indicating the
>        original upper layer protocol type.  It can be set to "UNKNOWN" if
>        unknown.
> 
> SB> This is a different subject, and needs to be called out and explicitly agreed. There is no need for this as far as I can see, and I am not sure why it needs to be in every EH.
> 
>     NH:  8-bit indicator for the Next Header.  This field identifies the
>        type of the header immediately following the HEH.
> 
>     The value of the reserved nibble needs further consideration.  The
>     EHC field can be used to keep track of the number of extension
>     headers when some headers are inserted or removed at some network
>     nodes.
> 
> SB> Has the WG agreed to inflight insertion and removal?
> 
> SB> If we do this, which label does this apply to when we do nested tunnels?
> 
>     The EHTL field can help to skip all the extension headers in
>     one step if the original upper layer protocol headers or payload need
>     to be accessed.  The OUL field can help identify the type of the
>     original upper layer protocol.
> 
> SB> These are capabilities that we have not as yet agreed that we need. I do not recall them being called up the use case or requirement drafts.
> 
>     The format of an Extension Header (EH) is shown in Figure 3.
> 
> 
> 
> 
> 
> 
> Song, et al.            Expires 12 February 2023                [Page 6]
> 

> Internet-Draft      MPLS Post-Stack Extension Header         August 2022
> 
> 
>         0          1          2          3
>         01234567 89012345 67890123 45678901
>        +--------+--------+--------+-------+
>        |  NH    |  HLEN  |EXT(opt)|       |
>        +--------+--------+--------+       |
>        |                                  |
>        ~        Header Specific Data      ~
>        |                                  |
>        +--------+--------+----------------+
> 
>                              Figure 3: EH Format
> 
>     The meaning of the fields in an EH is as follows:
> 
>     NH:  8-bit indicator for the Next Header.  This field identifies the
>        type of the EH immediately following this EH.
> 
> SB> I am sure that you got the 8 bits by copying IPv6, but do we need 8 bits?
> 
> SB> We are not operating in Internet scope. How many EH types do we think that we will need? Could we operate in domain scope? Could we use some of these bits to specify the action on an unknown EH, and to specify E2E and HxH?
> 
>     HLEN:  8-bit unsigned integer for the Extension Header Length in
>        4-octet units, not including the first 4 octets.
> 
> SB> Are we seriously considering 1KB of EH? That will break pretty much every forwarder.
> 
>     EXT:  8-bit optional type extension.  To save the Next Header numbers
>        and extend the number space, it is possible to use one "Next
>        Header" code to cover a set of sub-types.  Each sub-type is
>        assigned a new code in a different name space.  This field is
>        optional and it is only specified for some specific EH type.
> 
> SB> So are we saying that we need to make provision for 64K EH types?
> 
> SB> EH sub-types could be a concept that is private to a particular EH type, and that might be a more powerful design.
> 
>     Header Specific Data:  Variable length field for the specification of
>        the EH.  This field is in length such that the EH is 4-octet
>        aligned.
> 
> SB> What you do not have here and which may be of use is a flag saying what to do if you do not understand. I also wonder if there needs to be a HxH flag.
> 
> SB> The way this is laid out we need to parse the whole of the EH chain to find out if we are interested in any EH entry. I wonder if we should have a manifest of some sort so just looking at BoS we can find out if anything is of interest?
> 
>     The extension headers as well as the first original upper layer
>     protocol header are chained together through the NH field in HEH and
>     EHs.  The encoding of NH can share the same value registry for IPv4/
>     IPv6 protocol numbers.  Values for new EH types (i.e., NH number)
>     shall be assigned by IANA from the same registry as for the ipv4 and
>     ipv6 protocol numbers (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fprotocol-&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C3e6c9ecf94c04f1a145c08da89d0aac0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637973826696436768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=88DoLPKV6r8UUXpTN45PYPRqL4zULju4xqTti5E3C8k%3D&amp;reserved=0  <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fprotocol-&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C3e6c9ecf94c04f1a145c08da89d0aac0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637973826696436768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=88DoLPKV6r8UUXpTN45PYPRqL4zULju4xqTti5E3C8k%3D&amp;reserved=0>
>     numbers/protocol-numbers.xhtml).
> 
> SB> ... but is that the right registry to use? Do we really want to be tied to the IP protocol numbers registry and do they want us cluttering up their registry - which has to last the life of the Internet - with our extension system which could use its own registry?
> 
> SB> Indeed the result of using our own registry would be a more compact registry space which leads to more efficient forwarding.
> 
>     Specifically, the NH field of the last EH in a chain can have some
>     special values, which shall be assigned by IANA as well:
> 
>     NONE (No Next Header):  Indicates that there is no other header and
>        payload after this header.  This can be used to transport packets
>        with only extension header(s), for example, the control packets
>        for control or the probe packets for measurements.  Note that
>        value 59 was reserved for "IPv6 No Next Header" indicator.  It may
>        be possible for MPLS EH to share this value.
> 
> SB> That needs discussion in 6man
> 
> 
> 
> Song, et al.            Expires 12 February 2023                [Page 7]
> 

> Internet-Draft      MPLS Post-Stack Extension Header         August 2022
> 
> 
>     UNKNOWN (Unknown Next Header):  Indicates that the type of the header
>        after this header is unknown.  This is intended to be compatible
>        with the original MPLS design in which the upper layer protocol
>        type is unknown from the MPLS header alone.
> 
> SB> Not quite true, it is known from the FEC of the BoS label.
> 
>     MPLS:  Indicates that the original upper layer protocol is still MPLS
>        and another MPLS label stack follows.
> 
>     Note that the original upper layer protocol can be of type "MPLS",
>     which implies that in a packet there might be multiple label stacks
>     separated by EHs.  Having more than one independent label stack is
>     not new.  For example, A Bier header could separate the transport/
>     bier labels and the payload labels; An MPLS Pseudo Wire (PW) network
>     could be implemented on the top of another infrastructure MPLS
>     network.
> 
> SB> I do not understand this point.
> 
>     In such cases, we have the flexibility to apply different
>     services to different label stacks.
> 
> 3.  Type of MPLS Extension Headers
> 
>     Basically, there are two types of MPLS EHs: HBH and E2E.  E2E means
>     that the EH is only supposed to be inserted/removed and processed at
>     the MPLS tunnel end points where the MPLS header is inserted or
>     removed.  The EHs that need to be processed on path nodes within the
>     MPLS tunnel are of the HBH type.  However, any node in the tunnel can
>     be configured to ignore an HBH EH, even if it is capable of
>     processing it.
> 
>     If there are two types of EHs in a packet, the HBH EHs must take
>     precedence over the E2E EHs.
> 
> SB> I am worried about how we bind the scope of the EH to a label.
> 
> SB> If I tunnel a packet by pushing a label are the EH in the scope of that tunnel or not? Is that a ubiquitous decision?
> 
>     Making a distinction of the EH types and ordering the EHs in a packet
>     help improve the forwardidng performance.  For example, if a node
>     within an MPLS tunnel finds only E2E EHs in a packet, it can avoid
>     scanning the EH list.
> 
>     The type of an EH (i.e., HBH or E2E) is an intrinsic property of the
>     EH.  In other words, EH type indicates if it needs to be processed on
>     each hop or only on edge node.
> 
> SB> Is that the optimum design?
> 
> 4.  Operation on MPLS Extension Headers
> 
>     When the first EH X needs to be added to an MPLS packet, an EH
>     indicator is inserted into the proper location in the MPLS label
>     stack.  A HEH is then inserted after the MPLS label stack, in which
>     EHCNT is set to 1, EHTLEN is set to the length of X in 4-octet units,
>     and NH is set to the header value of X.  At last, X is inserted after
>     the HEH, in which NH and HELN are set accordingly.  Note that if this
>     operation happens at a PE device, the upper layer protocol is 
> known
> 
> 
> 
> Song, et al.            Expires 12 February 2023                [Page 8]
> 

> Internet-Draft      MPLS Post-Stack Extension Header         August 2022
> 
> 
>     before the MPLS encapsulation, so its value can be saved in the NH
>     field if desired.  Otherwise, the NH field is filled with the value
>     of "UNKNOWN".
> 
> SB> I am wondering if there are cases, for example as a result of nested tunnels where some may be know and some unknown.
> 
> =========
> 
> 5.  Use Cases
> 
>     In this section, we show how MPLS extension header can be used to
>     support several new network applications.
> 
>     In-situ OAM:  In-situ OAM (IOAM) records flow OAM information within
>        user packets while the packets traverse a network.  The
>        instruction and collected data are kept in an IOAM header
>        [RFC9197].  When applying IOAM in an MPLS network, the IOAM header
>        can be encapsulated as an MPLS extension header.
> 
>     Network Telemetry and Measurement:  A network telemetry and
>        instruction header can be carried as an extension header to
>        instruct a node what type of network measurements should be done.
>        For example, the method described in [RFC8321] can be implemented
>        in MPLS networks since the EH provides a natural way to color MPLS
>        packets.
> 
>     Network Security:  Security related functions often require user
>        packets to carry some metadata.  In a DoS limiting network
>        architecture, a "packet passport" header is used to embed packet
>        authentication information for each node to verify.
> 
> SB> You need to comment on the matter of NS and EH addition removal in
> the security case. We spent a little time thinking of this in the TCR 
> case (draft-bcx-rtgwg-tcr), but there are probably others that have 
> considered the problem of partial signatures in more detail.
> 
> Song, et al. Expires 12 February 2023 [Page 9]
 Internet-Draft MPLS 
> Post-Stack Extension Header August 2022 Segment Routing and Network
> Programming: MPLS extension header can support the implementation of a 
> new flavor of the MPLS-based segment routing, with better performance 
> and richer functionalities. The details will be described in another draft.
> 
> SB> Reference?
> 
> 6.  Security Considerations
> 
> SB> We need a security architecture or this will not get past first base.
> 
> ==========
> 
> ==========
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=05%7C01%7Chaoyu.song%40f
> uturewei.com%7C3e6c9ecf94c04f1a145c08da89d0aac0%7C0fee8ff2a3b240189c75
> 3a1d5591fedc%7C1%7C0%7C637973826696436768%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&amp;sdata=qfPRfuSgYAG7UhcGAgl%2FPXHa0XbpRKCuqnlvFH4gQYg%3D&am
> p;reserved=0

-- 
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]