Hi,
Please find my review comments for draft-ietf-dmm-srv6-mobile-uplane-00.
## Comments to Stateless Interworking
In general, I thought 5.4 and 6.3 could be combined or be more closer.
I think organization of the document would be changed a lot from various
feedback so just my 2 cents at this point.
> 5.4.1. End.TM:
>
> 1. IF NH=SRH & SL > 0 THEN
> 2. decrement SL
> 3. update the IPv6 DA with SRH[SL]
> 4. push header of TUN-PROTO with tunnel ID from S ;; Ref1
> 5. push outer IPv4 header with SA, DA from S
> 6. ELSE
> 7. Drop the packet
5.4.1 doesn't mention about PSP (pop SRH from packet) which is described
in 6.3.2.
Do you expect any case where PSP would not happen for End.TM operation?
If so, that means End.TM would be used in other situation than described
in 6.3.2, so might be more clear if you can describe that case as well.
> 5.4.2. T.Tmap: Transit behavior with tunnel decapsulation and mapping
>
> 4. insert the SRH (D, B; SL=1) ;; Ref2, Ref2bis
I assume D is end point node on public internet.
Since it's not defined, adding description what is D might make it more
clear.
> 6.3.2 Downlink: SRv6 to Legacy Access
> ...
> SID is bound to the next segment of S::1 , the L3-anchor node
> does T.Insert process for the receiving packet to push a SRH
> with SID list <B2::, S::1> with SL=1, where "B2" which encodes
Maybe <B2::, S::1> should be <B2, S::1> Since B2 is Stateless
Interworking SID Encoding and not prefix?
> The stateless interworking node of "B2" End.TM process for the
> receiving packet according to the SRH. The node decrement SL
> to 0, updates DA to "D::1" which the SL indicates, push IPv4
> and tunnel headers with IPv4 DA, SA and TUN-ID extracted from
> "B2", and forward the packet to the legacy network.
Since this is DL, shouldn't DA be "S::1" (MN) ?
My understanding is SA for DL is always D::1 which would not change
while travelling from L3 Anchor to B2.
> 6.3.2. Downlink: SRv6 to Legacy Access
>
> In case of an L2-anchor node receives a packet destine to SID
> "A2::B2" and the SID is bound to "B2", the L2-anchor node does
> End.B6 process for the receiving packet as same as previous
> section. The node updates DA to B2 and forward the packet.
I could not find description of case when L3-anchor add A2::B2 as DA.
Might be more clear if you can describe the format of A2::B2 and how to
generate B2 from A2::B2.
Also, it might be nice if you have matrix like below for 6.3 as similar
to the ones you have in 6.1 and 6.2.
+-----------------------------+--------+----------+
| User-plane Function | Uplink | Downlink |
+-----------------------------+--------+----------+
| stateless interworking node | T.Tmap | End.TM |
| L2-anchor | End.B6 | End.B6 |
| L3-anchor | End.T | T.Insert |
+-----------------------------+--------+----------+
## General Comments (not limited to stateless interworking)
1. Might overlap with comments from Charlie, but I also thought it was
difficult to find out where in the network S1, C1, A2::1, D::1, A1::1
etc. resides.
Diagram of overall network including above addresses with list of node
each address corresponds would be helpful.
2. Any reason Access Point UL and L3-anchor DL only use T.Insert and not
T.Encap?
Looks like it was intentionally removed in
draft-matsushima-spring-dmm-srv6-mobile-uplane-02, so sorry if it was
already discussed and clarified.
If there are any issue between Access Point and L3-anchor which router
reply ICMP, it would be destined to MN or End Point on public internet.
Since ICMP payload would have SRH which includes mobile network's
information, I was not sure if this is accepted for all operators.
3. It might be more clear to mention <S1, S2, S3> is a SID list where S1
is the first SID to visit and S3 is the last.
(Although it is mentioned in SRv6 Network Programming draft)
Thanks,
--
Kentaro Ebisawa @ Ponto Networks, Inc.
Work: <[email protected]> | Mailing Lists: <[email protected]>
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
