Le 19/12/2019 à 12:52, Pablo Camarillo (pcamaril) a écrit :
Hi Alex.
Please see inline.
Many thanks,
Pablo.
------------------------------------------------------------------------
*From:*Alexandre Petrescu <[email protected]> *Sent:*
Monday, December 16, 2019 3:31 PM *To:* Pablo Camarillo (pcamaril)
<[email protected]>; [email protected] <[email protected]> *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?
-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.
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).
About my initial worry - now T.Encaps cahnged its name into H.Encaps, right?
It seems to not modify packets in transit, but to encapsulate them,
which is ok.
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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
