RE: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-11.txt>

[Ron Bonica <[e-mail]>]

Folks,

While I am very supportive of the SRv6 effort, I believe that draft-ietf-6man-segment-routing-header still requires work. The following are a) Major issues and  b) minor issues

With a little work, this could be a great document.

MAJOR ISSUES:

1. Introduction (Comment 1)

 SRv6 distinguishes between topological and service-based instructions. A topological instruction steers a packet along a traffic-engineered path through a network topology. It can appear in anywhere in the SRH Segment List except for the final position. If a topological instruction appears in the final position, it causes the packet to be dropped. Draft-ietf-6man-segment-routing-header offers END and END.X as examples of topological instructions.

By contrast, draft-ietf-6man-segment-routing-header does not offer any examples of service-based instructions. In order to understand these, one must read draft-filsfils-spring-network-programing. Many of the service instructions defined in that document invoke VPN services on the endpoint router. For example, End.DT2M causes the IP header and all of its extension headers to be removed, exposing Ethernet payload. The endpoint router learns the exposed inner MAC SA in L2 table T and forwards the Ethernet packet on all appropriate outgoing interfaces. A service-based instruction can only appear in the final position of the SRH Segment List. If a service-based instruction appears in any other position, it causes the packet to be dropped.

Topological instructions are clearly a legitimate use of the Routing Extension header. However, it is not so clear that service-based instructions belong in the Routing Extension header. The document should include text that further defines service-based instructions (possibly offering an example or two) and explains why they belong in a Routing Extension Header as opposed to a Destinations Option Header or even an upper-layer header. This section should explain the benefit in moving these instructions from upper-layer headers (where they are encoded today) into the Routing Extension header.


2.2 SRv6 Segment (Comment 1)

This section says:

" A local SID of N could be an IPv6 address of a local interface of N but it does not have to.  Most often, a local SID is not an address  of a local interface of N.  The My Local SID Table is thus not populated by default with all the addresses of a node."

However, it does not tell us how a SID that is an interface address is processed. Is the processing exactly the same as the END instruction, except that it is allowed when SL == 0? If so, why do both exist.


Section 2.2 SRv6 Segment (Comment 2)

The draft fails to explain how a SID is routed through an IPv6 network once it is copied into an IPv6 Destination Address. Section 3 of draft-filsfils-spring-srv6-network-programming provides an explanation. It explains that the high order bits of the SID represent the node upon which the SID is instantiated. It also explains that the instantiating node advertises that prefix into the routing subsystem. This text should be brought forward into the current draft.



Section 2.2 SRv6 Segment (Comment 3)

The draft fails to explain how a node decides whether it needs to process the SRH. For every other Routing Extension Type, the Routing Extension Header is processed if the IP Destination Address represents a local interface and Segments Left is greater than 0. For the SRv6, SRH is processed even when SL == 0. It is not clear whether the SRH is processed whenever the SID falls within an specific prefix, or when it is actually in "My Local SID Table".

How are the error cases handled (e.g., when the SID was in My Local SID Table when the packet was sent but is not more).


Section 2.2 SRv6 Segment (Comment 4)

The draft fails to specify how an SRv6 capable node behaves when it processes a SID but does not recognize the instruction. (I don't find this in draft-filsfils-spring-srv6-network-programming either).


Section 2.2 SRv6 Segment (Comment 5)

According to RFC 8200:

"If, while processing a received packet, a node encounters a Routing header with an unrecognized Routing Type value, the required behavior of the node depends on the value of the Segments Left field, as follows:

 -  If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header.

-  If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type."

This is safe, so long as all Routing Extension Types use SL == 0  to indicate that the Routing Extension Header has been completely processed. It is may not be safe when SL == 0 means that one more segment needs to be processed. 

In the SRH, SL == 0 indicates that one more segment needs to be processed. The document should address this security consideration.

If you redefine the SL to match RFC 8200's definition, this problem resolves itself.


Section 2.3  Segment Routing (SR) Domain (Comment 1)

RFC 8200 says:

"Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header."

Draft-ietf-6man-segment-routing-header says:

" It is assumed in this document that the SRH is added to the packet by its source, consistently with the source routing model defined in  [RFC8200].  For example:

   o  At the node originating the packet (host, server).

   o  At the ingress node of an SR domain where the ingress node receives an IPv6 packet and encapsulates it into an outer IPv6 header followed by a Segment Routing header."

This gives the reader the impression that draft-ietf-6man-segment-routing-header is in harmony with RFC 8200.

However, Sections 4.13, 5.2  and 5.3 of draft-filsfils-spring-srv6-network-programming offer procedures in which intermediate nodes insert Segment Routing Headers. (Sometimes, they insert a second SRH in a packet that already has an SRH).

Draft-ietf-6man-segment-routing-header should either proscribe SHR insertion (using RFC 2119 language) or update the above-mentioned assumption and define scenarios in which Routing Extension Header insertion is acceptable.



Section 3 Segment Routing Header (Comment 1)

RFC 8200 defines the Segments Left field in the Routing Extension Header as follows:

 "8-bit unsigned integer.  Number of route  segments remaining, i.e., number of explicitly  listed intermediate nodes still to be visited  before reaching the final destination."

Draft-ietf-6man-segment-routing-header redefines the Segments Left field in the Routing Extension Header as follows:

"Defined in [RFC8200], it contains the index, in the Segment List, of the next segment to inspect.  Segments Left is decremented at each segment."

These definitions are different from one another. In the RFC 8200 definition, SL==0 indicates that the Routing Extension Header has been completely processed. In the SRH definition, SL==0 indicates that one segment remains to be processed.

The current draft should adopt the RFC 8200 definition. This would resolve a few of the issues mentioned above.


Section 3 Segment Routing Header (Comment 2)

The draft fails to describe P-bit processing. How should a node behave when it receives a packet with the P-bit set? Clear?


Section 3 Segment Routing Header (Comment 3)

The draft fails to describe O-bit processing. 

While some text can be found in Section 6.3 of Draft-filsfils-spring-srv6-network-programming, that text is incomplete. It says that a) O-bit processing is optional and b) the O-bit causes a timestamped copy of the packet to be punted to the control plane. It doesn't say what the control plane does with this information

Section 3 Segment Routing Header (Comment 4)

The draft fails to describe how the tag field is processed.

Section 3.1 SRH TLV's (Comment 1)

Draft-ietf-6man-segment-routing-header says:

" Type Length Value (TLV) contain optional information that may be used  by the node identified in the DA of the packet.  It has to be noted that the information carried in the TLVs is not intended to be used  by the routing layer.  Typically, TLVs carry information that is consumed by other components (e.g.: OAM) than the routing function."

Given that this information is not consumed by the routing layer, the authors should explain why it is in a Routing Extension Header, as opposed to a Destination Option.


Section 3.1.1 Ingress Node TLV (Comment 1)

It is not clear how this TLV will be useful. When the SRH is created by the originating node, the  ingress TLV is represented by the IPv6 source address. When the SRH is prepended by an SR ingress node,  the ingress TLV is represented by the IPv6 Destination Address of the outer IPv6 header


Section 3.1.1 Ingress Node TLV (Comment 2)

The following text requires explanation:

" Ingress Node: 128 bits.  Defines the node where the packet is   expected to enter the SR domain.  In the encapsulation case  described in Section 2.3.1, this information corresponds to the SA  of the encapsulating header."

The words 'is expected' implies that the packet has not yet entered the SR domain. If that is the case, how can it have an SRH?

Section 3.1.2 Egress Node TLV (Comment 1)

It is not clear how this TLV will be useful.  Can't the egress node be derived from the high order bits of the final members of the Segment list. Draft-filsfils-spring-srv6 calls these bits the locator.


Section 3.1.3 Opaque Container TLV Comment 1)

The Opaque container field is defined as "128 bits of opaque data not relevant for the  routing layer.  Typically, this information is consumed by a non- routing component of the node receiving the packet (i.e.: the node in the DA)."

If it is not relevant to routing, and its meaning is not define, why is it in a Routing Extension Header?

Section 3.1.6 NSH Carrier TLV (Comment 1)

By including the NSH Carrier TLV in the SRH, SRv6 becomes coupled to SRv6. Can you conceive of a scenario where you might want to deploy NSH without SRv6? If so, it would be a good idea to move this information to an IPv6 Destination Option.

Also, this section talks about NSH TLVs. No TLVs are defined in RFC 8300.


Section 3.1.6 NSH Carrier TLV (Comment 2)

Does this TLV need to be mutable? Might every node accumulate metadata?

Section 3.2.  SRH and RFC8200 behavior (Comment 1)

Draft-ietf-6man-segment-routing-header says that the SRH " SHOULD only appear once in the packet". However, Section 4.13 of draft-filfils-spring-srv6-network-programming talks about a scenarios in which the SRH can appear many times in a packet.

The current draft should either a) upgrade the SHOULD to a MUST or b) explain when it is acceptable for a packet to include multiple instances of the SRH and place an upper limit on the number of SRH instances that a packet can contain.

Section 4 SRH Functions (Comment 1)

Draft-ietf-6man-segment-routing header says that " [I-D.filsfils-spring-srv6-network-programming] defines the basic  functions associated with SRv6 SID's." Given that, the reference to draft- filsfils-spring-srv6-network-programming should be normative.


Section 4.1  Endpoint Function (End)  (Comment 1)

This section says, "If the FIB lookup matches a multicast state, then the related  Reverse Path Forwarding (RPF) check must be considered successful." The draft should dive deeper into multicast considerations. Multicast forwarding may be acceptable at some points in the segment list, while dangerous at other points.

Section 4.1  Endpoint Function (End)  (Comment 2)

This section says, " An SRv6-capable node MUST include the Flow Label of the IPv6 header in its hash computation for ECMP load-balancing."  

This works only if the node that originated the packet sets the Flow Label to something other than zero. Furthermore, load balancing will still break of intermediate, none SRv6-capable nodes don't include the Flow Label in the hash computation

The draft needs a section on load balancing and ECMP.

Section 4.1  Endpoint Function (End)  (Comment 3)

This section says, " By default, a local SID bound to the End function does not allow the decapsulation of an outer header.  As a consequence, an End  SID cannot be the last SID of an SRH and cannot be the DA of a  packet without SRH".

It continues to say, " If the decapsulation is desired, then another function must be  bound to the SID (e.g., End.DX6 defined in  [I-D.filsfils-spring-srv6-network-programming]).  This prevents  any unintentional decapsulation by the segment endpoint node."

But consider the case where the source node generates the SRH and the SRH is preserved all the way to the destination. In that case, no decapsulation is required. So, why is END not allowed to be the last SID of an SRH in that scenario?


Section 4.1  Endpoint Function (End)  (Comment 4)

Section 4.20 of Draft-filsfils-srv6-network-programming appears to modify this procedure to support Ultimate SRH Popping and Penultimate SRH popping. These modifications should be brought forward into the current draft


Section 5.1 Source SR Node (Comment 1)

The draft says, " The Segments Left field is set to n-1 where n is the number of  elements in the Segment List."

Please compare this with the example offered in Section 4.4. of RFC 2460. In that example,  Segments Left field is set to n where n is the number of  elements in the Segment List.

If you did that, many of the above mentioned problems would resolve themselves.

Section 5.2 Transit Node (Comment 1)

The draft says, " the only node who is allowed to inspect  the Routing Extension Header (and therefore the SRH), is the node corresponding to the DA of the packet."

Clearly, if the DA is a local interface, the node should inspect the SRH. But if the DA does not represent an interface, should it inspect the packet only if the DA is in My Local SID Table? Or if the DA falls within a prefix that was allocated for My Local SID Table.

In either case, the draft should address what happens if the DA was in My Local SID Table when the packet was sent but is no longer there.



MINOR ISSUES:

Section 3 Segment Routing Header (Comment 1)

Why are the U-bit not contiguous?

Section 3 Segment Routing Header (Comment 2)

The A-bit seems to be redundant. The presence of TLVs can be determined from the values of the Header Extension Length and Last Entry fields.

Section 3.1.1, 3,1,2 and 3.1.3 Ingress, Egress and Opaque TLVs (Comment 1)

Why is a Flags field defined when no flags are defined? You could merge this field with the RESERVED field.


Section 4.1 Endpoint Function (Comment 1)

The End function is also defined in Section 4.1 of draft-filsfils-spring-srv6-network-programming. Which definition is normative?

Section 4.2 End.X: Endpoint with Layer-3 cross-connect  (Comment 1)

The End.X function is also defined in Section 4.2 of draft-filsfils-spring-srv6-network-programming. Which definition is normative?


NITS:

The Nit Checker complains about a downref.

> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Bob Hinden
> Sent: Thursday, March 29, 2018 4:31 PM
> To: IPv6 List <[e-mail]>
> Cc: Bob Hinden <[e-mail]>
> Subject: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-
> 11.txt>
> 
> 
> This message starts a two week 6MAN Working Group Last Call on advancing:
> 
>        Title           : IPv6 Segment Routing Header (SRH)
>        Authors         : Stefano Previdi
>                          Clarence Filsfils
>                          John Leddy
>                          Satoru Matsushima
>                          Daniel Voyer
> 	Filename       : draft-ietf-6man-segment-routing-header-11.txt
> 	Pages          : 34
> 	Date           : 2018-03-28
> 
>      https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header
> 
> as a Proposed Standard.  Substantive comments and statements of support
> for publishing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the author.  This last call will end on 12
> April 2018.
> 
> An issue tracker will be setup to track issues raised on this document.
> 
> Thanks,
> Bob & Ole
> 
> 
>