Alex,
I will update the line 04 as suggested to clarify that it refers to the outer
IPv6 header. Thank you.
More inline.
Happy Holidays,
Pablo.
-----Original Message-----
From: Alexandre Petrescu <alexandre.petre...@gmail.com>
Date: Thursday, 19 December 2019 at 14:33
To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>, "spring@ietf.org"
<spring@ietf.org>
Subject: Re: [spring] Question about SRv6 Insert function
Le 19/12/2019 à 12:52, Pablo Camarillo (pcamaril) a écrit :
> Hi Alex.
>
> Please see inline.
>
> Many thanks,
>
> Pablo.
>
> ------------------------------------------------------------------------
>
>
>
*From:*Alexandre Petrescu <alexandre.petre...@gmail.com> *Sent:*
> Monday, December 16, 2019 3:31 PM *To:* Pablo Camarillo (pcamaril)
> <pcama...@cisco.com>; i...@ietf.org <i...@ietf.org> *Subject:* Re:
> [spring] Question about SRv6 Insert function
>
> Hi, SPRINGers,
>
> This is my first post to this list.
>
> This is about draft-ietf-spring-srv6-network-programming-06 more
> precisely the T.Encaps section 5.2.
>
> Le 11/12/2019 à 21:05, Pablo Camarillo (pcamaril) a écrit :
>> Alex,
>>
>> The precise definition T.Encaps is done in section 5.1 [5.2 now] of
>> draft-ietf-spring-srv6-network-programming-06. If you have any
>> comment on such definition please let me know -on a separate thread
>> and directed to SPRING mailer-.
>
> Thank you for the reply.
>
> Please make the T.Encaps part of the draft easier for me to read,
> e.g.: -expand what it means 'S01'; is it 'Step 01', like in BASIC
> programming language?
>
> PC: Same format as in other documents (e.g. SRH).
What is the other document SRH?
PC: draft-ietf-6man-segment-routing-header-26
> -clarify that the original packet in transit is not modified upon
> transition (modulo the Hop Limit field and the Segments Left field if
> present); new packet is created to carry the original packet - yes.
>
> PC: I have added a paragraph in the latest version of the draft to
> capture your point. See rev07. Many thanks.
I think you mean that you added this paragraph:
> The T.Encaps received packet is encapsulated unmodified (with the
> exception of the TTL or Hop Limit that is decremented as described in
> [RFC2473]).
I think it is good to say the packet is encapsulated unmodified.
Indeed the Hop Limit is the sole exception. I think the TTL should not
be mentioned. (side note: each IPv4 occurence should be dropped from
everywhere in the document now :-)
> -clarify what it means 'a packet (A, S2)(S3, S2, S1; SL=1)'; because
> it is confusing in several ways; (A,S2) invites to think it is src
> and dst addresses, but their place is switched (the normal order is
> Source, Destination). S in 'S2' might mean a Source Address but
> also might mean a Segment ID, or a Destination address. Confusion
> should be avoided, at least in my mind.
>
> PC: This is explained in the terminology section of the draft (with
> a detailed example).
It is indeed in the terminology section.
It clarifies many things to me.
I am still left with the question: is a Segment Identifier an IPv6
address? (all the 128bits of it). I cant find an answer neither in
this I-D neither in its reference RFC8402 "Segment Routing" terminology
section.
PC: See the first paragraph of section 3.
This is important to know, because in below the text says a destination
address is an S1 (DA=S1) and it also says that S1 is part of a segment list.
In a destination address field one cant have something else than an IPv6
address. But a segment identifier could be something else than an IPv6
address, if so it wanted. (somewhere else people talk about 'locator'
being a 64bit value, I am not sure).
PC: Read section 3.1.
About my initial worry - now T.Encaps cahnged its name into H.Encaps, right?
PC: Yes.
It seems to not modify packets in transit, but to encapsulate them,
which is ok.
PC: Indeed.
> Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1;
> SL=1). B2 is neither a local address nor SID of N.
>
> N steers the transit packets P1 and P2 into an SR Policy with a
> Source Address T and a Segment list <S1, S2, S3>.
>
> The H.Encaps transit encapsulation behavior is defined as follows:
>
> S01. Push an IPv6 header with its own SRH (S3, S2, S1; SL=2)
> S02. Set outer IPv6 SA = T and outer IPv6 DA = S1
> S03. Set outer payload length, traffic class and flow label
> S04. Update the Next-Header value
'Update' or rather 'create'? I hope it is the next-header value of the
outer IPv6 header; this is the first time to put something inside, so it
is rather a creation.
'Updating' makes think that maybe the next header value of the inner
(original) packet is updated from value x to y.
Or?
> S05. Decrement inner Hop Limit or TTL
> S06. Submit the packet to the IPv6 module for transmission to S1
>
> After the H.Encaps behavior, P1 and P2 respectively look like:
>
> - (T, S1) (S3, S2, S1; SL=2) (A, B2)
>
> - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1)
It looks ok - the P1 and P2 packets have not been modified in transit,
but encapsulated.
I wonder though about the 1 value for SL (SL=1) in P2 original and P2
transited. I wonder whether it should be decremented or not. I think
it might complicated but I do not mind.
Alex
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
