Subject: Comments on draft-previdi-6man-segment-routing-header-05

From: Jen Linkova <[email-masked]>
Date: Mon, 23 Mar 2015 23:27:53 +0100

Hi Stefano,

Some comments on the current version of the SR v6 header.
1) (it's not directly about the header, it's more about how SR for v6
is supposed to work..)
Section 3.2. (Illustration) mentions as a requirement "The links AB
and CE cannot be used to transport the packet P.".
Let's imagine that *after* the SR header "{SD, SB, SS, SF, SE}" got
inserted and a packet sent to the network, the link F-E goes down. In
this case packets reach node F and then are sent back to C and from C
to E (over C-E link). So I'm not sure we can actually prohibit using a
particular link ("MUST NOT"), it's rather "SHOULD NOT" as it is still
possible that changes in network topology would result in packets
taking the 'prohibited' path for some time.

2) You define 3 SR header operations: PUSH/NEXT/CONTINUE/. What about
POP (removal of the header?). Shall it be defined as an operation?

3) Section 5.1. Segment Identifiers (SIDs) and SRGB
"Node SIDs are IPv6 addresses part of the SRGB (i.e.: routable
   addresses)."
I'd suggest to replace "routable addresses" with "addresses of global scope"

4) In the same section 5.1 you say: "Adjacency-SIDs are IPv6 addresses
which may not be part of the global IPv6 address space."
and then in 5.1.1:
""When SR is applied to IPv6, any SID is in a global IPv6 address and
   therefore, an Adj-SID has a global significance (i.e.: the IPv6
   address representing the SID is a global address)."

I found those two sentences confusing...Is SID always a v6 address of
global scope or it may not be?

5) (I think I made that comment before...) while the text is talking
about 4 possible policy elements, the picture shows only 3. IMHO it
would be nice to make the illustration consistent with the text....

BTW, I really like that the header format is now compatible with
RFC2460 - big improvement IMHO.

-- 
SY, Jen Linkova aka Furry

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2015 23:28:33 +0000

1. In section 3, the document has the following sentence:

    [Segments can be derived from different components: IGP, BGP, Services, Contexts, Locators, etc.]

   It would be good to specifically mention a static route in the above sentence. 

2. Along the lines that Jen is talking about for failure, it does make sense that this document adds use cases for how to handle failures which the document currently lacks.  What if a link is constantly going up and  down?  Does the packet keep going back to the sender path to back track and go another path and keep changing paths?  Isn't a delay then introduced in this flow processing and causes SLA metrics to not be met.  

3. What if the segment header increases the packet size to be greater than link MTU?  Is a message sent to the originator of the segment-header and is ICMPv6 MTU failure signaled?   

4. The document discusses IS-IS and OSPF which do support ipv6.   If RIPNg supported?

5. Would this document consider adding a segment type that is not an ipv6 address but instead an opaque quantity specified via a TLV format so that the same protocol can be used by another application with this  application-specific-segment-header?  Of course, other application functions would need definition as well.

Good work thus far.

Cheers,

Hemant

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 26 Mar 2015 20:55:10 +0000

Hi Jen,

many thanks for your comments, see below.

On Mar 23, 2015, at 11:27 PM, Jen Linkova <[email-masked]> wrote:
> to E (over C-E link).

just to be picky, what you describes happens AFTER the convergence is completed, not at the failure time. At failure time, the packet is simply dropped.

After convergence time (or at failure time if you have precomputed a ipfrr repair path), yes, you may use the undesired link.

What typically happens in TE networks is that explicit path are provisioned based on resource constraint and topology events that could affect the explicit path (what is the frr/fc strategy) so that when something fails, you do have protection and the ability to re-route the traffic from the origin to a new explicit (post-convergence) path.

> So I'm not sure we can actually prohibit using a

I agree, the requirement should be described as: 
. in this topology don't use this link.
. in case of problems such as link/node failures, do what the network has been configured for (fast convergence, fast re-route).

> POP (removal of the header?). Shall it be defined as an operation?

we may want to to add an operation to the header but note that PUSH, NEXT and CONTINUE are related to the segment list, not to the whole header.

In fact the header needs not to be removed (according to rfc2460 if segments left is 0 you just ignore the routing header) but still the cleanup bit is useful if we want to be transparent to the endpoints.

I'll add some text on this.

> I'd suggest to replace "routable addresses" with "addresses of global scope"

ok.

> global scope or it may not be?

well, first of all, I agree: the text is confusing and needs cleanup ;-)

next, nothing prevents the use of local addresses as adjacency identifiers. Note well that this doesn't mean that you make a local address global. You just advertise it (e.g.: in ISIS or OSPF) as Adj-SID, not as a route. 

By default, I'd expect the ipv6 address of the adjacency being a global address but maybe we should preserve the ability to use any address, in fact any 128bit identifier. Of course, it assumes that the packet first reaches the node (using a global address segment) and then, the next segment being inspected, you find a local identifier representing the link.

> would be nice to make the illustration consistent with the text....

yes. I have a new picture ready ;-)

> RFC2460 - big improvement IMHO.

indeed.

Thanks.
s.