[mpls] Gunter Van de Velde's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

Gunter Van de Velde has entered the following ballot position for
draft-ietf-mpls-spring-inter-domain-oam-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-inter-domain-oam/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Gunter Van de Velde, RTG AD, comments for
draft-ietf-mpls-spring-inter-domain-oam-17

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/
documenting the handling of ballots.

Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson and
for the shepherd writeup by Adrian Farrel.

Many thanks for this write-up. It is well written. I did find when reading the
document that some constructs were presented more complex as necessary.

Please find in this review three blocking DISCUSS observations, followed by
non-blocking high-level observations. Additionally, there is a set of detailed
comments categorized as [minor] and [major] observations, which I hope you will
find useful for improving the document.

#DISCUSS items
#=============
##DISCUSS1
Why is there the A-flag? would the existence of an SR Algorithm in the TypeC/D
subTLVs not be sufficient? It implicit suggests that there is an algorithm?

##DISCUSS2
What should be done when, for Type-C and D, the encoded IP address does not
match the encoded SID for the node or the correct algorithm for that node? Is
there a validation process or error messaging in place?

##DISCUSS3
section 5.3 documents that "An MPLS packet is constructed with an echo reply
where the top label MUST be constructed from the first segment from the Reply
Path TLV while the remaining labels MUST follow the order from the Reply Path
TLV".  This text seems to allow that random segments can be inserted as long as
the original ordering is kept. Is that intentional? if yes, such prescribed
behavior should be explicitly documented. If not allowed, then that should be
included in formal procedure rules.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

#GENERIC COMMENTS
#================
##There is some usage of RFC2119 normative language that may not be needed in
some sections. Some have been flagged in the detail review

##The SID is encoded with only a label in the Type-A/C/D. SR also allows a SID
to be an index instead of a label. Is there a reason why index was excluded?

##with the explanation of the Type-A/C/D subTLVs there was some duplicate text
for explaining the fields. I would suggest to revise and the fields and the
formal procedures only once per Type. Now some fields are described twice in
the same section

##Section 6 details an example. Examples are not formal normative procedures.
It seems more opportune to place the example in Appendix to reduce the formal
part of the draft and to clearly identify it is informational. It makes the
main part of the formal procedure of the RFC less long

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

26         domains.  This document describes mechanisms to facilitate LSP ping
27         and traceroute in inter-AS and inter-domain SR-MPLS networks
28         efficiently with a simple Operations, Administration and Maintenance
29         (OAM) protocol extension which uses data plane forwarding alone for
30         forwarding echo replies on transit nodes.

[minor]
I got confused wit the wording of 'alone' and am not convinced it is used
correctly.

"This document outlines mechanisms to enable efficient LSP ping and traceroute
in inter-AS and inter-domain SR-MPLS networks through a straightforward
extension to the Operations, Administration, and Maintenance (OAM) protocol,
relying solely on data plane forwarding for handling echo replies on transit
nodes."

115        [RFC8660] specifies SR with an MPLS data plane.  [RFC8402] describes
116        BGP peering SIDs, and [RFC9087] describes Egress Peer Engineering,

[minor]
s/BGP peering SIDs/BGP Peering Segments/
s/Egress Peer Engineering/Centralized BGP Egress Peer Engineering/

117        which will help in steering packets from one AS to another.  Using
118        the above SR capabilities, paths that span across multiple ASes can
119        be created.

[minor]
slight rewrite from readability perspective:
"By utilizing these SR capabilities, it is possible to create paths that span
multiple ASes."

192        SR label stack.  The return path can either be derived by a smart
193        application or controller that has a full topology view.  This
194        document also proposes mechanisms to derive the return path
195        dynamically during traceroute procedures.

[major]
I am not sure what is a 'smart' application or controller. Is a full topology
view really required? a topology view of the network section being investigated
seems sufficient, not?

197        The current document is focused on the inter-domain use case.
198        However, the protocol extensions described in this document may be
199        applied to indicate the return path for other use cases as well,
200        which are out-of-scope for this document and therefore not further
201        described in this document.  SRv6 data plane is not in the scope of
202        this document.

[minor]
Why is the text seems complicated constructed. What about the following:

"This document focuses on the inter-domain use case. The protocol extensions
described may also indicate the return path for other use cases, which are
outside the scope of this document and are not further detailed here. The SRv6
data plane is also not covered in this document."

204     1.1.  Definition of Domain

206        The term domain used in this document implies an IGP domain where
207        every node is visible to every other node for shortest path
208        computation.  The domain implies an IGP area or level.  An AS
209        consists of one or more IGP domains.  The procedures described in
210        this document apply to paths built across multiple domains which
211        include inter-area as well as inter-AS paths.  The procedures and
212        deployment scenarios described in this document apply to inter-AS
213        paths where the participating ASes belong to closely coordinating
214        administrations or to single ownership.  This document applies to SR-
215        MPLS networks where all nodes in each of the domains are SR capable.
216        It also applies to SR-MPLS networks where SR acts as an overlay
217        having SR-incapable underlay nodes.  In such networks, the traceroute
218        procedure is executed only on the overlay SR nodes.

[minor]
I found this section hard to parse. The following text proposal processes
slightly better:

"In this document, the term "domain" refers to an IGP domain where every node
is visible to every other node for the purpose of shortest path computation,
implying an IGP area or level. An Autonomous System (AS) comprises one or more
IGP domains. The procedures described herein are applicable to paths
constructed across multiple domains, including both inter-area and inter-AS
paths. These procedures and deployment scenarios are relevant for inter-AS
paths where the participating ASes are under closely coordinating
administrations or single ownership. This document pertains to SR-MPLS networks
where all nodes within each domain are SR-capable. It also applies to SR-MPLS
networks where SR functions as an overlay with SR-incapable underlay nodes. In
such networks, the traceroute procedure is executed only on the overlay SR
nodes. "

253        Reply Path (RP) TLV is defined in [RFC7110].  SR networks statically
254        assign the labels to nodes and a PMS/head-end may know the entire
255        database.  The reverse path can be built from the PMS/head-end by

[major]
What for database? The LSDB? a database with the all the nodes and assigned
SIDs? something else?

265        The type of segment that the head-end chooses to send in the Reply
266        Path TLV is governed by local policy.  Implementations MAY provide
267        Command Line Interface (CLI) input parameters in the form of Labels/
268        IPv4 addresses/IPv6 addresses or a combination of these which get
269        encoded in the Reply Path TLV.  Implementations MAY also provide
270        mechanisms to acquire the database of remote domains and compute the
271        return path based on the acquired database.  For traceroute purposes,
272        the return path will have to consider the reply being sent from every
273        node along the path.  The return path changes when the traceroute

[major]
I do not understand why these are uppercase MAY? no formal protocol procedures
are provided in this section? consider lower case as it distracts from formal
protocol procedures

[major]
The term 'database' is unclear. What for database is exactly intended? A node
may have many databases

279        Some networks may consist of pure IPv4 domains and pure IPv6 domains.
280        Handling end-to-end MPLS OAM for such networks is out of the scope of
281        this document.  It is recommended to use dual-stack in such cases and
282        use end-to-end IPv6 addresses for MPLS ping and traceroute
283        procedures.

[minor]
Clarification: I suspect that it is intended to indicate that it is pure
ipv4-only or ipv6-only networks?

295        The below types of Segment sub-TLVs apply to the Reply Path TLV.  The
296        code points for the sub-TLVs are taken from the IANA registry common
297        to TLVs 1, 16, and 21.  This document defines the Segment sub-TLVs
298        usage and processing when it appears in TLV 21.  If these sub-TLVs
299        appear in TLVs 1 or 16, appropriate error codes MUST be returned as
300        defined in [RFC8029].

[major]
While the text here is is not wrong, it is confusing type-A/C/D and then three
code-point TLVs... The text should be more explit that code points punt
towards: 1       Target FEC Stack 16      Reverse-path Target FEC Stack 21     
Reply Path

and be more explicit that the new defined sub-TLVs are only to be used with
TLV21 (Reply Path TLV).

327        Type: TBD1(to be assigned by IANA from the registry "Sub-TLVs for TLV
328        Types 1, 16, and 21").

[minor]
Should it not specify a field length of 2 octets?

330        Length: 2 octets.  Carries value 8.  The length excludes the length
331        of the Type and Length Fields.

[minor]
The length "value" exclude....

335        RESERVED: 3 octets of reserved bits.  MUST be set to zero when
336        sending; MUST be ignored on receipt.

[minor]
I believe that the declaration for reserved is the correct one, but want to
double check. If there is any potential that in future these bits may be used,
then instead Future Use may be better choice.

342        S: 1 bit Reserved.

[minor]
few lines above the RESERVED 3 octets were described directly, however the
formal procedure for handling S bit is explained later in the text, which is
inconsistent

390        Length: 2 octets.  Carries value 8 without SID included or 12 with
391        SID included.

[minor]
The text should be more prescriptive.
"Caries value 8 when no optional SID is included or value 12 when optional SID
is included."

395        SR Algorithm: 1 octet specifying SR Algorithm as described in section
396        3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present.
397        SR Algorithm is used by the receiver to derive the Label.  When
398        A-flag is unset, this field has no meaning and thus MUST be set to
399        zero on transmission and ignored on receipt.

[major]
Is the algorithm not always used by the received to derive the used label?
the algorithm is either 0 (or 1) or one of the flex-algorithms.
Iam not sure why there is an A-flag? could the setting of AR Algorithm not
implicit assume that there is an SR Algorithm? why a specific A-fleg?

404        IPv4 Node Address: 4-octet IPv4 address representing a node.

[minor]
Should it be mentioned that this should be best a stable address (e.g a
loopback address?)

406        SID: optional: 4-octet field containing label, TC, S and TTL as
407        defined in Section 4.1.  When the SID field is present, it MUST be
408        used for constructing the Reply Path.

[major]
A SID can be a label or an index. Is there a reason to exclude the index type
of SID? (see: https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.2 )

414        The SID is optional and specifies a 4-octet MPLS SID containing
415        label, TC, S and TTL as defined in Section 4.1.

[minor]
Seems duplicate text meanings already documented in line406-408

417        If the length is 8, then only the IPv4 Node Address is present.
419        If the length is 12, then the IPv4 Node Address and the MPLS SID are
420        present.

[minor]
Is this not already documented earlier when the Length field is described?

422     4.3.  Type D: IPv6 Node Address with Optional SID for SR MPLS

[minor]
This section has similar editorial issues as section 4.2 where some fields are
explained twice. Maybe optimise the formal text

494        A-Flag: This flag indicates the presence of SR Algorithm ID in the
495        "SR-Algorithm" field applicable to various segment Types.

[major]
Why not use the existence of the SR Algorithm field instead of a A-flag?

507        This section uses the term "initiator" for the node that initiates
508        the MPLS ping or MPLS traceroute procedure.  The term "responder" is
509        used for the node that receives the echo request and sends the echo
510        reply.  The term egress node is used to identify the last node where
511        the MPLS ping or traceroute is destined to.  In an MPLS network any
512        node can be initiator or responder or egress.

[minor]
What is the difference between 'responder and the 'egress node'? should they be
the same node?

516        In the inter-AS scenario, the procedures described in this document
517        are used to specify the return path, if IP connectivity to the
518        initiator is not available, and may be used in any case.  The LSP

[minor]
Readability rewrite:
"In the inter-AS scenario, the procedures outlined in this document are
employed to specify the return path when IP connectivity to the initiator is
unavailable. These procedures may also be utilized regardless of the
availability of IP connectivity. "

529        As described in [RFC7110], when Reply mode is set to 5 (Reply via
530        Specified Path), the echo request must contain the Reply path TLV.
531        Absence of Reply Path TLV is treated as a malformed echo request.

[minor]
In previous section uppercase RFC2119 language is used. Would using MUST here
not be justified?

532        When an echo request is received, if the responder does not know the
533        Reply Mode 5 defined in [RFC7110], an echo reply with the return code
534        set to "Malformed echo request received" and the Subcode set to zero
535        must be sent back to the initiator according to the rules of
536        [RFC8029].  If the echo request message contains a malformed Segment

[minor]
instead of 'does not know' i suspect what is meant is 'does not support'?

541        When a Reply Path TLV is received, the responder that supports
542        processing it, MUST use the segments in Reply Path TLV to build the
543        echo reply.  The responder MUST follow the normal FEC validation
544        procedures as described in [RFC8029] and [RFC8287] and this document
545        does not suggest any change to those procedures.  When the echo reply

[major]
If validation fails (e.g. sid does not exist or is not reachable for example)
would this cause a echo reply to be returned with some error subcode?

545        does not suggest any change to those procedures.  When the echo reply
546        has to be sent out the Reply Path TLV MUST be used to construct the
547        MPLS packet to send out.

[major]
Must the MPLS label stack created by the node be an exact copy of the sid stack
encoded in the Reply Path TLV? can there be MPLS labels added (for redirecting
purposes or special services)?

555        segment from the Reply Path TLV.  The remaining labels MUST follow
556        the order from the Reply Path TLV.  The responder MAY check the

[major]
What if te order of labels is kept, but some other labels are inserted for
steering or other purposes?

566        if such information is available from the controller or via operator
567        input.  In such cases, the node sending the echo reply MUST derive
568        the MPLS labels based on Node-SIDs associated with the IPv4/IPv6
569        addresses or from the optional MPLS SIDs in the Type-C/Type-D
570        segments and encode the echo reply with MPLS labels.

[major]
What if the Type-C/D encoded IP address does not correspond with that nodes
SID? What would happen? for example IP address 1.1.1.1 has SID 111 but in the
subTLV the address 1.1.1.1 is encoded with ID222. Would that give an error or
is there some validation?

636        it is RECOMMENDED to add a Type-C or a Type-D segment, but
637        implementations MAY safely use other approaches if they see benefits
638        in doing so.  If the existing segment in the Reply Path TLV is a

[minor]
I am confused by the wording of other approaches? If Type-C or D is not used,
only Type-A remains. Is that 'the other' approaches? If yes, then why not just
say to insert Type-A?

646        When an ASBR receives an echo request from another AS, and the ASBR
647        is configured to build the return path dynamically, the ASBR should
648        build a Reply Path TLV and include it in the echo reply.  The Reply

[major]
This is most likely a clarification item. Would this result into potentially
multiple Replay Path TLVs to be appended? or to have additional subTLVs (i.e.
Type-A) to be inserted into the Type 21 TLV? i believe that later in the
paragraph it is indicated that subTLVs are added

674        An ASBR that receives the echo request from a neighbor belonging to
675        the same AS, MUST look at the Reply Path TLV received in the echo
676        request.  If the Reply Path TLV consists of a Type-C/Type-D segment,

[minor]
IS 'receiving' correct? it is receiving and if the local SID is the top sid of
the received packet then the processing takes place. Otherwise the packet is
presumably MPLS switched onwards without any processing by the local node.

701     6.  Detailed Example

[major]
This is an example of the formal procedures outlined in this document.
Examples are not formal procedures and are better placed into the Appendix.

950        IANA should assign three new sub-TLVs from the "sub-TLVs for TLV
951        Types 1, 16, and 21" sub-registry of the "Multiprotocol Label
952        Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
953        registry.

[major]
These subTLVs can only be in the TLV21. Should that be mentioned on the IANA
page in the registry notes?

978        New entries are assigned by Standards Action.  Initial entries in the
979        registry are as follows:

[minor]
Using standards action would not allow the allocation of flags for experimental
purpose. Maybe more appropriate is to allocate using 'IETF Review' (also known
as IETF Consensus)?