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

From: Ron Bonica <[email-masked]>
Date: Wed, 4 Apr 2018 16:22:54 +0000

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 <[email-masked]> On Behalf Of Bob Hinden
> Sent: Thursday, March 29, 2018 4:31 PM
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> 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
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Apr 2018 08:30:40 +1200

Ron, great review. Here are a few comments on some of your comments.

> Folks,
...> Section 2.2 SRv6 Segment (Comment 5)
> If you redefine the SL to match RFC 8200's definition, this problem resolves itself.

Yes, it seems completely wrong to change the generic definition of SL. It creates
confusion and introduces problems for no reason. What's hard to understand in
the phrase "segments left"? Your later comments make this 100% clear.

> Draft-ietf-6man-segment-routing-header should either proscribe SHR insertion (using RFC 2119 language)

IMHO it doesn't need to, since it has RFC8200 as a normative reference. The
"It is assumed..." sentence seems acceptable to me.

> or update the above-mentioned assumption and define scenarios in which Routing Extension Header insertion is acceptable.

The debate around draft-voyer-6man-extension-header-insertion is far from over,
and I don't see draft-filsfils-spring-srv6-network-programming progressing
until that is settled. (You are probably correct in your later comment that
spring-srv6-network-programming needs to be a normative reference, so that
will hold up the current draft anyway.)

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

(For anybody checking this, in the text "Flow Label" is misspelt "FlowLabel".)
 
> This works only if the node that originated the packet sets the Flow Label to something other than zero.

Well, we don't know what else is being used for ECMP, do we? If the flow label
is zero, it has no effect, but whatever other fields are used for ECMP might
do the job. It's a bit odd to mention ECMP exactly once in the document, with
no details.

(The flow label is mentioned once elsewhere, in section 4.2 "End.X: Endpoint
with Layer-3 cross-connect" but almost as a throw-away line.)

> Furthermore, load balancing will still break of intermediate, none SRv6-capable nodes don't include the Flow Label in the hash computation

Not necessarily. It only breaks in some ECMP topologies where some paths
contain flow-label balancers and others don't. In fact, it's not got
much to do with SRv6 at all.

> The draft needs a section on load balancing and ECMP.

Either that, or say nothing at all. If it is a requirement that sources
set the flow label, there needs to be a normative citation of RFC 6437,
which defines how to do it. (If you're encapsulating, RFC 6438 might
also be relevant.)

     Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 4 Apr 2018 14:10:59 -0700

The issue tracker has been setup for this w.g. last call.

You can see the open tickets at:

https://trac.ietf.org/trac/6man/report/1

I think I captured everything, let me know if I didn’t.

I didn’t add a cc: to each ticket because I thought it would create too much email on the list.  The discussion should continue on the list.

Thanks,
Bob

> On Mar 29, 2018, at 1:30 PM, Bob Hinden <[email-masked]> wrote:
> 
> 
> Editorial suggestions can be sent to the author.  This last call will
> end on 12 April 2018.
>

---

From: stefano previdi <[email-masked]>
Date: Thu, 5 Apr 2018 11:29:54 +0200

Ron,

on comment 5:

> In the SRH, SL == 0 indicates that one more segment needs to be processed.

sorry, I don’t understand. 

Can you point me the text in draft-ietf-6man-segment-routing-header that states that ? 

If it’s the case it should be obviously corrected.

SL==0 means the packet is traveling within the last segment.

draft-ietf-6man-segment-routing-header does not modify the semantic of “Segments Left”. 

It does modify the way segment list is encoded (that’s one of the reason it’s a different routing header type) but not the "Segments Left” field semantic.

s.

> The document should address this security consideration.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Thu, 5 Apr 2018 18:44:58 +0000

Hi Stephano,

I'm glad you asked this question. RFC 8200 and draft-ietf-6man-segment-routing-header define Segments Left (SL) differently. The difference is a bit subtle and took me a few readings to catch.

RFC 8200 defines SL as follows:

Therefore, if a packet arrives at a node and the following conditions are true, the node skips over the Routing Extension Header and processes the next header:

- The packets IPv6 Destination address is local to the node
- The packet contains a Routing Extension Header
- The SL value in the Routing Extension Header is equal to 0

In RFC 2460, Routing Extension Type RH0 was compliant with this behavior. The description of RHO (RFC 2460, Section 4.4) explains how RH0 used to process SL, offering pseudocode and an example. Between the publication of RFC 2460 and RFC 8200, RHO was deprecated for other reasons. Therefore, the detailed example of SL handling was not brought forward into RFC 8200.

But even though this example was not brought forward into RFC 8200, it explains why RFC 8200 says:

 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 because an SL value of 0 means that the Routing Extension Header has already been completely processed by upstream nodes. Even if the node recognized the Routing Type, it still would skip over it.

By contrast, draft-ietf-6man-segment-routing header defines the Segments Left 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.

Therefore, if a packet arrives at a node and the following conditions are true, the node processes Segment[0]:

- The packets IPv6 Destination address is local to the node
- The packet contains a Routing Extension Header
- The SL value in the Routing Extension Header is equal to 0

This is different from the behavior described in RFC 8200 and 2460. It also raises two questions:

- If the node doesn't recognize SRH, is it safe to ignore the SRH, as recommended by RFC 8200
- If the node does recognize SRH and the segment requires decapsulation and forwarding, are Extension Headers that follow SRH (e.g. Fragment, Destination Options) ignored?

                                                             Ron

> From: stefano previdi <[email-masked]>
> Sent: Thursday, April 5, 2018 5:30 AM
> To: Ron Bonica <[email-masked]>
> Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
> Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-
> header-11.txt>
> 
> Ron,
> 
> on comment 5:
> 
> 
> > "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.
> >
> It does modify the way segment list is encoded (that’s one of the reason it’s
> a different routing header type) but not the "Segments Left” field semantic.
> 
> s.
> 
> 
> 
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 5 Apr 2018 19:38:59 +0000

Hi Ron, I’m glad you’re feeling a bit better.

Your analysis of SL is not correct.  Both 2460, 8200 and SRH say the same thing for SL==0 but you’re getting stuck on what 'the index, in the Segment List, of the next segment to inspect’ means.

Using the same example from 2460 section 4.4 but modifying for the Segment List[] defined in SRH.

 As the packet travels from S to I1:
        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I1            Segments Left = 3
                                            Segment List[0] = D
                                            Segment List[1] = I3
                                            Segment List[2] = I2
                                            Segment List[3] = I1
   As the packet travels from I1 to I2:
        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I2            Segments Left = 2
                                            Segment List[0] = D
                                            Segment List[1] = I3
                                            Segment List[2] = I2
                                            Segment List[3] = I1
  As the packet travels from I2 to I3:
        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I3            Segments Left = 1
                                            Segment List[0] = D
                                            Segment List[1] = I3
                                            Segment List[2] = I2
                                            Segment List[3] = I1
   As the packet travels from I3 to D:
        Source Address = S                  Hdr Ext Len = 6
        Destination Address = D             Segments Left = 0
                                            Segment List[0] = D
                                            Segment List[1] = I3
                                            Segment List[2] = I2
                                            Segment List[3] = I1
SL always points to the "next segment to inspect", that segment is also in the Destination Address. 
For example between I1 and I2, the next segment to inspect is I2, the SL==2 which is the index in Segment List of I2.  
The same is true for I3 to D where SL==0, the next segment to inspect is D, but the SRH need not be processed because SL==0.

Section 4.1 of SRH shows this quite clearly in its description of the END function where SL is decremented then the Segment at SRH[SL] is used to update the Destination Address.
1. IF SegmentsLeft > 0 THEN
2.    decrement SL
3.    update the IPv6 DA with SRH[SL]
4.    FIB lookup on updated DA
5.    forward accordingly to the matched entry
8.  ELSE
7.    drop the packet

I hope this clears up the confusion.

Darren

> On Apr 5, 2018, at 2:44 PM, Ron Bonica <[email-masked]> wrote:
> 
> Hi Stephano,
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 5 Apr 2018 21:06:46 +0000

Darren,

Thanks! I am feeling much better than yesterday!

I think that we are getting to the bottom of that subtle difference between SL in RFC 8200 and SL in draft-ietf-6man-segment-routing-header.

In RFC 8200, a node receives a packet that satisfies the following conditions:

- IPv6 Destination Address is local to the node
- Packet contains a Routing Extension Header
- Routing Extension Header SL value is equal to 0

The correct behavior is to skip over the Routing Extension Header and process the next header. The Routing Extension Header has already been completely processed by upstream nodes. In fact it doesn't even matter if the node recognizes the Routing Extension Type. The node will skip over it, regardless of its type.

In draft-ietf-6man-segment-routing-header, a node receives a packet that satisfies the same conditions.

The required behavior is to process the instruction in Segment List [0]. When I has done this, the Routing Extension Header will be completely processed. The node better recognize the SRH, because skipping the instruction might be dangerous.

The difference between SL in RFC 8200 and SL in draft-ietf-6man-segment-routing is subtle, but significant.

                                                                         Ron

> From: Darren Dukes (ddukes) <[email-masked]>
> Sent: Thursday, April 5, 2018 3:39 PM
> Cc: stefano previdi <[email-masked]>; IPv6 List <[email-masked]>; Bob
> Hinden <[email-masked]>
> Your analysis of SL is not correct.  Both 2460, 8200 and SRH say the same thing
> for SL==0 but you’re getting stuck on what 'the index, in the Segment List, of
> the next segment to inspect’ means.
> 
> 
> 
> For example between I1 and I2, the next segment to inspect is I2, the SL==2
> which is the index in Segment List of I2.
> 
> The same is true for I3 to D where SL==0, the next segment to inspect is D,
> but the SRH need not be processed because SL==0.
> 
> 
> 
> Section 4.1 of SRH shows this quite clearly in its description of the END
> function where SL is decremented then the Segment at SRH[SL] is used to
> update the Destination Address.
> 
> > I'm glad you asked this question. RFC 8200 and draft-ietf-6man-segment-
> routing-header define Segments Left (SL) differently. The difference is a bit
> subtle and took me a few readings to catch.
> 
> >
> 
> > "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."
> 
> >
> 
> > Therefore, if a packet arrives at a node and the following conditions are
> true, the node skips over the Routing Extension Header and processes the
> next header:
> 
> >
> 
> > In RFC 2460, Routing Extension Type RH0 was compliant with this behavior.
> The description of RHO (RFC 2460, Section 4.4) explains how RH0 used to
> process SL, offering pseudocode and an example. Between the publication
> of RFC 2460 and RFC 8200, RHO was deprecated for other reasons. Therefore,
> the detailed example of SL handling was not brought forward into RFC 8200.
> 
> >
> 
> > If Segments Left is zero, the node must ignore the Routing header and
> > If Segments Left is non-zero, the node must discard the packet and  send
> > This is because an SL value of 0 means that the Routing Extension Header
> has already been completely processed by upstream nodes. Even if the node
> recognized the Routing Type, it still would skip over it.
> 
> >
> 
> > "Defined in [RFC8200], it contains the index, in the Segment List, of the
> next segment to inspect.  Segments Left  is decremented at each segment.
> 
> >
> 
> > - If the node does recognize SRH and the segment requires decapsulation
> and forwarding, are Extension Headers that follow SRH (e.g. Fragment,
> Destination Options) ignored?
> 
> >
> 
> >                                                             Ron
> 
> >
> 
> >
> 
> >>> In the SRH, SL == 0 indicates that one more segment needs to be
> 
> >> processed.
> 
> >>
> 
> >>
> 
> >> Can you point me the text in draft-ietf-6man-segment-routing-header
> that
> 
> >> states that ?
> 
> >>
> 
> >> draft-ietf-6man-segment-routing-header does not modify the semantic
> of
> 
> >> “Segments Left”.
> 
> >>
> 
> > Administrative Requests:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=WmPR-
> DmQkiyFhWqdRohhiCg015eX46xGJmHofETXsM0&s=7bmAIXTGfcwjaJMMnP
> w7zYDgOQmzyIQ66CYofnt72Dw&e=
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 5 Apr 2018 22:38:29 +0000

See inline.

On Apr 5, 2018, at 5:06 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Darren,

Agreed

The required behavior is to process the instruction in Segment List [0].

You are still incorrect here, this doesn’t match the text in the draft. You certainly don’t match the END processing in Section 4.1.

The required behavior is to process the instruction in the DA (which happens to be the same as Segment List[0] when SL=0)
We always process the instruction in the DA as mentioned in Section 4.1.
The Segment List is used to put the next instruction in the destination address and forward.  That’s it.

Darren

When I has done this, the Routing Extension Header will be completely processed. The node better recognize the SRH, because skipping the instruction might be dangerous.

                                                                        Ron

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, April 5, 2018 3:39 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: stefano previdi <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>; Bob
Hinden <[email-masked]<mailto:[email-masked]>>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-
header-11.txt>

Using the same example from 2460 section 4.4 but modifying for the
Segment List[] defined in SRH.

                                           Segment List[0] = D

                                           Segment List[1] = I3

                                           Segment List[2] = I2

                                           Segment List[3] = I1

                                           Segment List[0] = D

                                           Segment List[1] = I3

                                           Segment List[2] = I2

                                           Segment List[3] = I1

                                           Segment List[0] = D

                                           Segment List[1] = I3

                                           Segment List[2] = I2

                                           Segment List[3] = I1

                                           Segment List[0] = D

                                           Segment List[1] = I3

                                           Segment List[2] = I2

                                           Segment List[3] = I1

SL always points to the "next segment to inspect", that segment is also in the
Destination Address.

2.    decrement SL

8.  ELSE

7.    drop the packet

Darren

On Apr 5, 2018, at 2:44 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stephano,

But even though this example was not brought forward into RFC 8200, it
explains why RFC 8200 says:

By contrast, draft-ietf-6man-segment-routing header defines the
Segments Left as follows:

Therefore, if a packet arrives at a node and the following conditions are
true, the node processes Segment[0]:

This is different from the behavior described in RFC 8200 and 2460. It also
raises two questions:

- If the node doesn't recognize SRH, is it safe to ignore the SRH, as
recommended by RFC 8200

                                                           Ron

-----Original Message-----

From: stefano previdi <[email-masked]<mailto:[email-masked]>>

To: Ron Bonica <[email-masked]<mailto:[email-masked]>>

Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>

header-11.txt>

Ron,

on comment 5:

According to RFC 8200:

header with an unrecognized Routing Type value, the required behavior
of

proceed to process the next header in the packet, whose type is
identified

-  If Segments Left is non-zero, the node must discard the packet and
send

that the Routing Extension Header has been completely processed. It is
may

processed.

processed.

states that ?

“Segments Left”.

It does modify the way segment list is encoded (that’s one of the reason
it’s

a different routing header type) but not the "Segments Left” field
semantic.

s.

[email-masked]<mailto:[email-masked]>

Administrative Requests:

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 9 Apr 2018 06:41:12 +0000

Hi Joel, please see inline:

> On Mar 30, 2018, at 10:51 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> I do not think this document is ready to be sent to the IETF and IESG for final approval.
> There are several kinds of problems.
> 
> ECMP1: The document asserts that entropy information is put into the flow label.   I wish this worked.  I helped bring this idea forward years ago, independent of SRH.  Unfortunately, there are two related problems.  First, adoption appears to be low.  Second, and more important, there are reports from the field that doing thi actually breaks other things and cause packet re-ordering under some circumstances.  As a result, vendors are suggesting that people turn it off even when it is available.
> ECMP2: If, with suitable analysis, we decide that this is actually safe to do, then the document needs to include both that analysis and clearly spelled out requirements that operators MUST verify that all their routers support this behavior and that they have enabled this behavior before turning on SRv6 usage.
> 
> Structure: The text in section 2.3 says "It is assumed in this document that the SRH is added to the packet by its source".  This is at best disingenuous.  It is very clear that the value of this behavior lies primarily in use by the network, not by the packet sources.  Claiming otherwise results in a document with minimal utility.  Even this document itself disagrees with this assertion.  Tucked into the very next section is text saying that "outer header with an SRH applied to the incoming packet".  If this behavior were a clearly spelled out requirement, rather than a "typically" and if the text in 2.3 were replaced with something realistic, then the document would at least be itnernally consistent and match the expected usages.

2.3 is clear, a packet source can add an SRH.  Since a source is the node in the node that owns the source address of a packet.  The source may be a host or a node encapsulating an inner packet in an outer IPv6 header.  There is nothing disingenuous about that.

> 
> Edge filtering: The text on edge filtering does not actually state that prevention of packets with SRH and a current DA of an internal node is mandatory.  Unless it is clearly stated, the security considerations text as currently written is significantly weakened.  If it is mandatory, then again the deployment section needs to note that an operator needs to verify that all of his edge devices support such filtering and have it properly enabled in order to use SRv6.

Please look up infrastructure ACLs.  This filtering has been common practice for a very long time and I believe is quite obvious to anyone operating a network.

> 
> Edge Filtering and hybrids: Other documents have talked about allowing external packets with SRv6 entries pointing to internal nodes (which means the DA upon arrival at the operator edge will be an internal node as I understand it).  It the intention is to permit that with appropriate security, then the edge filtering requirements need to be clear about the requirements for cryptographic validation at the edge.

This document is not defining any of what you mention in this comment.

> 
> Yours,
> Joel
> 
> On 3/29/18 4:30 PM, Bob Hinden wrote:

---

From: stefano previdi <[email-masked]>
Date: Mon, 9 Apr 2018 10:09:06 +0200

Hi Ron,

> On Apr 5, 2018, at 8:44 PM, Ron Bonica <[email-masked]> wrote:
> 
> Hi Stephano,
> 

the same behavior happens into a SR node.

> In RFC 2460, Routing Extension Type RH0 was compliant with this behavior. The description of RHO (RFC 2460, Section 4.4) explains how RH0 used to process SL, offering pseudocode and an example. Bet…

ok. RFC2460 being obsoleted and RFC8200 not having any description, it looks to me the only reference where the processing of the routing header is explained is the SRH draft. 

Obviously, the processing of the routing header and the processing of an unrecognized routing header type didn’t change.

> This is because an SL value of 0 means that the Routing Extension Header has already been completely processed by upstream nodes. Even if the node recognized the Routing Type, it still would skip o…

correct. And note that by 
    “processing of the routing header” 
we intend 
    “update the DA with the next segment on the list”.

So, when SL==0 there’s nothing that needs to be processed in the header.

> - The SL value in the Routing Extension Header is equal to 0

SL==0 doesn’t imply any processing of the SRH. Both END and END.x functions starts with “IF SegmentsLeft > 0”.

> - If the node doesn't recognize SRH, is it safe to ignore the SRH, as recommended by RFC 8200

rfc8200 applies here. 

> - If the node does recognize SRH and the segment requires decapsulation and forwarding, are Extension Headers that follow SRH (e.g. Fragment, Destination Options) ignored?

rfc8200 applies here.

Thanks.
s.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Apr 2018 14:48:00 +1200

On 09/04/2018 20:09, stefano previdi wrote:
...
>> "Defined in [RFC8200], it contains the index, in the Segment List, of the next segment to inspect.  Segments Left  is decremented at each segment.

Maybe you should say:
 Segments Left is decremented at each segment after processing the segment list and
 before forwarding the packet.

> SL==0 doesn’t imply any processing of the SRH. Both END and END.x functions starts with “IF SegmentsLeft > 0”.

IMHO that needs to be stated normatively in the spec, even if it seems obvious.
The section you are referring to only says:
"In this section we review two functions that may be associated to a segment:"
and cites an informational reference (draft-ietf-spring-segment-routing).
So the junior programmer asked to actually write some network processor code
doesn't know that she MUST NOT process the SRH, because it's only a lower
case "may".

   Brian

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Apr 2018 19:34:24 +0000

Folks,

Inline.......

> From: Brian Carpenter <[email-masked]> On Behalf Of Brian E
> Carpenter
> Sent: Tuesday, April 10, 2018 10:48 PM
> To: stefano previdi <[email-masked]>; Ron Bonica
> <[email-masked]>
> Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
>  Segments Left is decremented at each segment after processing the
> segment list and  before forwarding the packet.

I don't think that this is always the intent. See Section 4.13 of draft-filsfils-spring-srv6-network-programming-04.

> > SL==0 doesn’t imply any processing of the SRH. Both END and END.x
> functions starts with “IF SegmentsLeft > 0”.
> 
> So the junior programmer asked to actually write some network processor
> code doesn't know that she MUST NOT process the SRH, because it's only a
> lower case "may".
> 
>    Brian

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Apr 2018 20:08:50 +0000

Stephano,

This entire conversation is muddied by that fact that a segment identifier is a 128-bit entity that represents either:

- An IPv6 interface (i.e., an attachment to a network link, as defined in [RFC 4291])
- A locator:instruction:parameter structure

When the Destination Address / Segment Identifier represents a locator:instruction:parameter structure:

- the locator (high-order bits) represent a node to which the packet should be delivered
- the instruction (low-order bits) represents how the packet should be processed once it arrives at that node
- the parameter (lowest-order bits)  constrains the instruction

As with any Routing Extension Header, we swap segment identifiers in and out of the Destination Address field of the basic IPv6 header.

So, when the packet arrives at a locator and SL==0, it is questionable as to whether the SRH has been completely processed. At very least, the node needs to execute the instruction that is encoded within the IP Destination Address and Segment List[0]. The node may even need to examine the SRH to execute that instruction.

I am pretty sure that the required procedures can be specified unambiguously. But since we are playing a little fast-and-loose with the semantics of an IP Destination Address, our specification needs to be extremely well crafted.

                                                       Ron

> Sent: Monday, April 9, 2018 4:09 AM
> ok. RFC2460 being obsoleted and RFC8200 not having any description, it looks
> to me the only reference where the processing of the routing header is
> explained is the SRH draft.
> 
> Obviously, the processing of the routing header and the processing of an
> unrecognized routing header type didn’t change.
> 
> 
> >> Subject: Re: 6man w.g. last call for
> >> <draft-ietf-6man-segment-routing- header-11.txt>
> >>
> >> Ron,
> >>
> >> on comment 5:
> >>
> >>
> >> of the node depends on the value of the Segments Left field, as follows:
> >>>
> >> identified by the Next Header field in the Routing header.
> >>>
> >> 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.
> >>>
> >> that states that ?
> >> of “Segments Left”.
> >> It does modify the way segment list is encoded (that’s one of the
> >> reason it’s a different routing header type) but not the "Segments Left”
> field semantic.
> >>
> >> s.
> >>
> >>
> >>
> >>
> >

---

From: stefano previdi <[email-masked]>
Date: Thu, 12 Apr 2018 15:58:57 +0200

Hi Ron,

> On Apr 11, 2018, at 10:08 PM, Ron Bonica <[email-masked]> wrote:
> 
> Stephano,
> 

> As with any Routing Extension Header, we swap segment identifiers in and out of the Destination Address field of the basic IPv6 header.

while I understand the difference, I don’t see how/when this can be a problem in between the SRH draft and rfc8200 especially now that rfc8200 only describes what a node must do when receiving an unrecognized routing header type.

> So, when the packet arrives at a locator and SL==0, it is questionable as to whether the SRH has been completely processed.

“processing an SRH” means:
. decrement segmentsLeft
. update DA with segmentList[segmentsLeft]

so, when a packet is received and if SL==0, there’s no processing of the SRH. 

Still the SRH may contain valuable data that the node may have some use of it, but the processing of the SRH does NOT happen when SL==0.

So, again, it’s perfectly normal to apply what rfc8200 mandates:
      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.

> At very least, the node needs to execute the instruction that is encoded within the IP Destination Address

correct.

> and Segment List[0].

of course, the whole segment list is still in the SRH (exactly the same for what rfc2460 expected) but this doesn’t mean the node has to process the SRH (i.e.: the node does NOT have to decrement segmentsLeft and does NOT have to update DA).

> The node may even need to examine the SRH to execute that instruction.
> 

Darren is working on a new text for the processing so hopefully we can nail this down.

Thanks.
s.

---

From: Ron Bonica <[email-masked]>
Date: Mon, 16 Apr 2018 13:31:13 +0000

Folks,

Before the last call ends, I would like to add two more comments:

1) The given that:

- the semantic of a SID is different from the semantic of an IPv6 Address,
- and that a SID can be copied into the Destination Address Field of IP Header
- and that the Destination Address Field of an IP Header can carry a SID, even if the packet does not contain an SRH

The document should consider the degree to which it extends the IPv6 Addressing Architecture. This discussion should include both topological instructions and service-based instructions.

2) In order to reduce the degree to which SRv6 extends the IPv6 Addressing Architecture, the document should represent service-based instructions as Destination Options

                                                                    Ron

---

From: "Voyer, Daniel" <[email-masked]>
Date: Mon, 16 Apr 2018 23:23:45 +0000

Hi Ron see [DV] inlines

On 2018-04-16, 9:31 AM, "ipv6 on behalf of Ron Bonica" <[email-masked] on behalf of [email-masked]> wrote:

    Folks,

    1) The given that:

    The document should consider the degree to which it extends the IPv6 Addressing Architecture. This discussion should include both topological instructions and service-based instructions.
[DV] In the context of SRv6, the SID is an IPv6 address.  As known, this IPv6 address is within a prefix owned by an operator or node.  The function of that address is entirely up to the implementation at the destination address.

Once again, it’s totally up to the application developers or operators to determine how they may or may not use the IPv6 addresses they own.  They may implement IP in IP tunneling, or some policy-based routing, or anything else on packets destined to that address.

I don’t see the need to bring other SID types into this draft.  This draft defines an SRH and has done a pretty decent job to date of doing that. It provides two examples of topological instructions.  The definition of other uses for SIDs is an application-based definition and does not fit into a draft defining how to carry and process SIDs in an SRH in general.

    2) In order to reduce the degree to which SRv6 extends the IPv6 Addressing Architecture, the document should represent service-based instructions as Destination Options
[DV] This seems to be another attempt to tell an operator what they may use an IPv6 address for.  You are or course free to put whatever you wish in a destination option and parse its TLVs.  As any other implementation is free to use IPv6 address they own for whatever purpose they choose.    

                                                                        Ron
Dan

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Apr 2018 16:21:12 +1200

On 17/04/2018 11:23, Voyer, Daniel wrote:
...
> [DV] This seems to be another attempt to tell an operator what they may use an IPv6 address for.  You are or course free to put whatever you wish in a destination option and parse its TLVs.  As any…

As a point of information, IPv6 prefixes are not owned. They were originally delegated
to IANA under the terms of RFC1881 (an IAB document): "Delegation of address space
by the IANA is not irrevocable." This doesn't in itself directly affect your point,
but IPv6 delegations are not transfers of ownership; they are more like leases.

As to whether address bits should be used for purposes other than addressing,
that's a whole other discussion. Personally I suggest keeping that discussion
out of the present draft, which means not duplicating material from
spring-srv6-network-programming. At the moment there seems to be quite a bit
of overlapping text, and that will cause problems later. I don't see
that any of that discussion is needed in the normative definition of
the SRH. Actually it makes it confusing for the reader - when I look again
at the description of the End or End.X functions, they really tie the
reader up in broader aspects of segment routing rather than help to
clarify the meaning of the header considered on its own. You could define
the meaning of "segments left" without mentioning the SRH Functions
concept at all.

(I may be slightly disagreeing with Ron here, but I think we should
keep the 6man document as simple as possible, with the details coming
along later in spring-srv6-network-programming.)

    Brian

---

From: "Stefano Previdi (IETF)" <[email-masked]>
Date: Tue, 17 Apr 2018 08:42:10 +0000

Brian,

I agree with you. The SRH draft is still focused to what it has been from
day one: the definition of the segment routing header in all its fields and
tlv's and with the basic algorithm describing what to do with the header.

Many of the ongoing discussions are related to the network programming and
header insertion drafts. I believe that these discussions should we moved
in their specific contexts.

Thanks.

s.

On Tue, Apr 17, 2018, 6:21 AM Brian E Carpenter <[email-masked]>
wrote:

> ....
> >     2) In order to reduce the degree to which SRv6 extends the IPv6
> Addressing Architecture, the document should represent service-based
> instructions as Destination Options
> > [DV] This seems to be another attempt to tell an operator what they may
> use an IPv6 address for.  You are or course free to put whatever you wish
> in a destination option and parse its TLVs.  As any other implementation is
> free to use IPv6 address they own for whatever purpose they choose.
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 23 Apr 2018 21:06:38 +0000

Hi Joel, this mail was captured as the following tracked issues:

#22<https://trac.ietf.org/trac/6man/ticket/22>, #23<https://trac.ietf.org/trac/6man/ticket/23>, #24<https://trac.ietf.org/trac/6man/ticket/24>, #25<https://trac.ietf.org/trac/6man/ticket/25>, #26<https://trac.ietf.org/trac/6man/ticket/26>

I’ve updated comments that all these as closed in revision 12 of the doc and some clarification in the thread.  Can you click on each and read the comments to each please, and respond to thi thread?

Thanks
  Darren

On Mar 30, 2018, at 10:51 AM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Apr 2018 06:59:34 -0400

The comment says taht there is nothing that needs to be done about this 
issue.

Yes, the document that the SRH is added by the "packet source".  Given 
that the text does in passing talk about adding the SRH at a domain edge 
for a packet from outside the domain, the usage of "packet source" is 
ambiguous.

I would prefer that the text was explicit that
a) a node originating an IPv6 packet and within an SRH domain by include 
an SRH.
2) an edge node for an SRH domain which is forwarding an IP packet and 
wishes to add an SRH shall encapsulate the packet, and add an IPv6 
header with an SRH.

Yours,
Joel

On 4/23/18 5:06 PM, Darren Dukes (ddukes) wrote:
> #22 <https://trac.ietf.org/trac/6man/ticket/22>, #23 
> <https://trac.ietf.org/trac/6man/ticket/23>, #24 
> <https://trac.ietf.org/trac/6man/ticket/24>, #25 
> <https://trac.ietf.org/trac/6man/ticket/25>, #26 
> <https://trac.ietf.org/trac/6man/ticket/26>
> 
> I’ve updated comments that all these as closed in revision 12 of the doc 
> and some clarification in the thread.  Can you click on each and read 
> the comments to each please, and respond to thi thread?
> 
> Thanks
>    Darren
> 
> 
> 
>> ECMP1: The document asserts that entropy information is put into the 
>> flow label.   I wish this worked.  I helped bring this idea forward 
>> years ago, independent of SRH.  Unfortunately, there are two related 
>> problems.  First, adoption appears to be low.  Second, and more 
>> important, there are reports from the field that doing thi actually 
>> breaks other things and cause packet re-ordering under some 
>> circumstances.  As a result, vendors are suggesting that people turn 
>> it off even when it is available.
>> ECMP2: If, with suitable analysis, we decide that this is actually 
>> safe to do, then the document needs to include both that analysis and 
>> clearly spelled out requirements that operators MUST verify that all 
>> their routers support this behavior and that they have enabled this 
>> behavior before turning on SRv6 usage.
>>
>> Structure: The text in section 2.3 says "It is assumed in this 
>> document that the SRH is added to the packet by its source".  This is 
>> at best disingenuous.  It is very clear that the value of this 
>> behavior lies primarily in use by the network, not by the packet 
>> sources.  Claiming otherwise results in a document with minimal 
>> utility.  Even this document itself disagrees with this assertion. 
>>  Tucked into the very next section is text saying that "outer header 
>> with an SRH applied to the incoming packet".  If this behavior were a 
>> clearly spelled out requirement, rather than a "typically" and if the 
>> text in 2.3 were replaced with something realistic, then the document 
>> would at least be itnernally consistent and match the expected usages.
>>
>> Edge filtering: The text on edge filtering does not actually state 
>> that prevention of packets with SRH and a current DA of an internal 
>> node is mandatory.  Unless it is clearly stated, the security 
>> considerations text as currently written is significantly weakened. 
>>  If it is mandatory, then again the deployment section needs to note 
>> that an operator needs to verify that all of his edge devices support 
>> such filtering and have it properly enabled in order to use SRv6.
>>
>> Edge Filtering and hybrids: Other documents have talked about allowing 
>> external packets with SRv6 entries pointing to internal nodes (which 
>> means the DA upon arrival at the operator edge will be an internal 
>> node as I understand it).  It the intention is to permit that with 
>> appropriate security, then the edge filtering requirements need to be 
>> clear about the requirements for cryptographic validation at the edge.
>>
>> Yours,
>> Joel
>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Apr 2018 07:01:29 -0400

Given taht deployment of an SRH domain requires that the filtering be 
enabled at all domain edges, that requirement should be explicitly 
stated either in the deployment section or in the security section.

Yours,
Joel

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 24 Apr 2018 15:11:15 +0000

Hi Joel, I added the work group to the CC list, I think it was missed in your original mail.

Though I met the requests for #22 and #23, I wanted to point out that section 5 fully defines “source node”:

      A host originating an IPv6 packet.

      An SR domain ingress router encapsulating a received packet in an
      outer IPv6 header followed by an SRH.

Here is rev 12 of the draft https://www.ietf.org/id/draft-ietf-6man-segment-routing-header-12.txt

Darren

On Apr 24, 2018, at 10:32 AM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

I tried to find rev 12 to read the actual text.  I relied on the summary you put in as a comment.

The texxt you quote does help with both this issue and the encapsulation issue.
I find the usage of "source node" awkward and likely to confuse readers, but I can not claim it is wrong.
Similarly, the second paragraph you quote does say that flow label ECMP support has to be fully deployed.  Again, it does so in a way that I fear will confuse readers, but I can not claim it is wrong.

Net: you have formally met request.

Yours,
Joel

On 4/24/18 10:24 AM, Darren Dukes (ddukes) wrote:
Hi Joel, did you read the ECMP section or revision 12?  This is pretty clear of what the source node must do when encapsulating a packet in an outer IPv6 header.
5.4. Load Balancing and ECMP
   Within an SR domain, an SR source node encapsulates a packet in an
   outer IPv6 header for transport to an endpoint.  The SR source node
   MUST impose a Flow Label computed based on the inner packet.  The
   computation of the flow label is as recommended in [RFC6438] for the
   sending TEP.
   At any transit node within an SR domain, the flow label MUST be used
   as defined in [RFC6438] to calculate the ECMP hash toward the
   destination address.
On Apr 24, 2018, at 6:55 AM, Joel M. Halpern <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

The comment does not seem to resolve the4 issue raised (and captured in the ticket).

The basic issue is that if flow label ECMP is not being used by the network, then the routers in the network will not be able to perform ECMP.  This will result in some form of problem (whether congestion, packet drops due to processing failure, or other misbehavior depends upon the exact equipment.)

The comment for ticket #23 seems to say that this is addressed by pointing at the RFC about flow label ECMP.  It is good that the RFC is referenced explicitly.  From what is there, this needs to be augmented with text noting that this needs to be implemented and enabled on the network in order for SRH to be used.

Yours,
Joel

On 4/23/18 5:06 PM, Darren Dukes (ddukes) wrote:
Hi Joel, this mail was captured as the following tracked issues:
#22 <https://trac.ietf.org/trac/6man/ticket/22>, #23 <https://trac.ietf.org/trac/6man/ticket/23>, #24 <https://trac.ietf.org/trac/6man/ticket/24>, #25 <https://trac.ietf.org/trac/6man/ticket/25>, #26 <https://trac.ietf.org/trac/6man/ticket/26>
I’ve updated comments that all these as closed in revision 12 of the doc and some clarification in the thread.  Can you click on each and read the comments to each please, and respond to thi thread?
Thanks
  Darren
On Mar 30, 2018, at 10:51 AM, Joel M. Halpern <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Yours,
Joel

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Apr 2018 11:15:16 -0400

Thank you.  I do not know why when I went there earlier the datatracker 
did not offer me -12.  So it goes.

That text in section 5 is what I was looking for.  It seems quite clear 
and addresses what I asked for.  I am sorry I missed it.

Yours,
Joel

On 4/24/18 11:11 AM, Darren Dukes (ddukes) wrote:
> Here is rev 12 of the draft 
> https://www.ietf.org/id/draft-ietf-6man-segment-routing-header-12.txt
> 
> Darren
> 
>> I find the usage of "source node" awkward and likely to confuse 
>> readers, but I can not claim it is wrong.
>> Similarly, the second paragraph you quote does say that flow label 
>> ECMP support has to be fully deployed.  Again, it does so in a way 
>> that I fear will confuse readers, but I can not claim it is wrong.
>>
>>> Hi Joel, did you read the ECMP section or revision 12?  This is 
>>> pretty clear of what the source node must do when encapsulating a 
>>> packet in an outer IPv6 header.
>>>> On Apr 24, 2018, at 6:55 AM, Joel M. Halpern <[email-masked] 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>
>>>> The basic issue is that if flow label ECMP is not being used by the 
>>>> network, then the routers in the network will not be able to perform 
>>>> ECMP.  This will result in some form of problem (whether congestion, 
>>>> packet drops due to processing failure, or other misbehavior depends 
>>>> upon the exact equipment.)
>>>>
>>>> The comment for ticket #23 seems to say that this is addressed by 
>>>> pointing at the RFC about flow label ECMP.  It is good that the RFC 
>>>> is referenced explicitly.  From what is there, this needs to be 
>>>> augmented with text noting that this needs to be implemented and 
>>>> enabled on the network in order for SRH to be used.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>>> I’ve updated comments that all these as closed in revision 12 of 
>>>>> the doc and some clarification in the thread.  Can you click on 
>>>>> each and read the comments to each please, and respond to thi thread?
>>>>> Thanks
>>>>>   Darren
>>>>>> On Mar 30, 2018, at 10:51 AM, Joel M. Halpern <[email-masked] 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> ECMP1: The document asserts that entropy information is put into 
>>>>>> the flow label.   I wish this worked.  I helped bring this idea 
>>>>>> forward years ago, independent of SRH.  Unfortunately, there are 
>>>>>> two related problems.  First, adoption appears to be low.  Second, 
>>>>>> and more important, there are reports from the field that doing 
>>>>>> thi actually breaks other things and cause packet re-ordering 
>>>>>> under some circumstances.  As a result, vendors are suggesting 
>>>>>> that people turn it off even when it is available.
>>>>>> safe to do, then the document needs to include both that analysis 
>>>>>> and clearly spelled out requirements that operators MUST verify 
>>>>>> that all their routers support this behavior and that they have 
>>>>>> enabled this behavior before turning on SRv6 usage.
>>>>>>
>>>>>> document that the SRH is added to the packet by its source".  This 
>>>>>> is at best disingenuous.  It is very clear that the value of this 
>>>>>>  Tucked into the very next section is text saying that "outer 
>>>>>> header with an SRH applied to the incoming packet".  If this 
>>>>>> behavior were a clearly spelled out requirement, rather than a 
>>>>>> "typically" and if the text in 2.3 were replaced with something 
>>>>>> realistic, then the document would at least be itnernally 
>>>>>> consistent and match the expected usages.
>>>>>>
>>>>>> that prevention of packets with SRH and a current DA of an 
>>>>>> internal node is mandatory.  Unless it is clearly stated, the 
>>>>>> security considerations text as currently written is significantly 
>>>>>> weakened.  If it is mandatory, then again the deployment section 
>>>>>> needs to note that an operator needs to verify that all of his 
>>>>>> edge devices support such filtering and have it properly enabled 
>>>>>> in order to use SRv6.
>>>>>>
>>>>>> Edge Filtering and hybrids: Other documents have talked about 
>>>>>> allowing external packets with SRv6 entries pointing to internal 
>>>>>> nodes (which means the DA upon arrival at the operator edge will 
>>>>>> be an internal node as I understand it).  It the intention is to 
>>>>>> permit that with appropriate security, then the edge filtering 
>>>>>> requirements need to be clear about the requirements for 
>>>>>> cryptographic validation at the edge.
>>>>>>
>>>>>> Yours,
>>>>>> Joel
>>>>>>
>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 24 Apr 2018 15:50:00 +0000

Thanks Joel.

Darren

> On Apr 24, 2018, at 11:15 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Thank you.  I do not know why when I went there earlier the datatracker did not offer me -12.  So it goes.
> 
> That text in section 5 is what I was looking for.  It seems quite clear and addresses what I asked for.  I am sorry I missed it.
> 
> Yours,
> Joel
> 
>>> On Apr 24, 2018, at 10:32 AM, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> On Apr 24, 2018, at 6:55 AM, Joel M. Halpern <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>> 
>>>>>>> On Mar 30, 2018, at 10:51 AM, Joel M. Halpern <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>> 
>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Apr 2018 13:06:23 -0400

The text change Darren provided points to a clear statement that 
addresses my concern.
At this point, to argue would be a matter of personal taste in document 
layout, and that is not legitimate.  I consider the problem resolved.

Yours,
Joel

On 4/24/18 11:51 AM, Darren Dukes (ddukes) wrote:
> Off list: Can you ack this issue is closed too?  Thanks.
> 
> Darren
> 
>> On Apr 24, 2018, at 6:59 AM, Joel M. Halpern <[email-masked]> wrote:
>>
>> The comment says taht there is nothing that needs to be done about this issue.
>>
>> Yes, the document that the SRH is added by the "packet source".  Given that the text does in passing talk about adding the SRH at a domain edge for a packet from outside the domain, the usage of "packet source" is ambiguous.
>>
>> a) a node originating an IPv6 packet and within an SRH domain by include an SRH.
>> 2) an edge node for an SRH domain which is forwarding an IP packet and wishes to add an SRH shall encapsulate the packet, and add an IPv6 header with an SRH.
>>
>> Yours,
>> Joel
>>
>>>> On Mar 30, 2018, at 10:51 AM, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>>>>