Hi Satoru,
Thanks for the answers to my comments.
> It doesn’t intend that A2::B2 derives B2 but in this case where an
L2-anchor exists in between L3-anchor and stateless interworking
functions, the L2-anchor binds A2::B2 to B2. I think that some diagram
and clear notation would help to describe it.
In such case, maybe using B2 in both cases is part of confusion.
Using A2::B2' instead might help to clarify B2 in A2::B2 (L3=>L2) and B2
(L2=>stateless interworking function) is different.
Thanks,
--
Kentaro Ebisawa @ Ponto Networks, Inc.
Work: <[email protected]> | Mailing Lists: <[email protected]>
------ Original Message ------
From: "Satoru Matsushima" <[email protected]>
To: "Kentaro Ebisawa" <[email protected]>
Cc: "dmm" <[email protected]>
date: 2017/12/05 18:35:37
Subject: Re: review comments on draft-ietf-dmm-srv6-mobile-uplane-00
Hi Ebisawa-san,
Thank you for your review. That’s helpful. Please see my comments in
line:
[...]
## 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.
My intention was at first to introduce all user-plane functions followed
by use cases.
There’s space to improve document structure which I agree.
> 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.
Right. I agree that PSP should be expected in this case. Thanks.
> 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?
Yes, correct. I’ll do fix it with appropriate diagram which Charlie
pointed out.
> 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.
Yes, you’re right. Will fix it as well.
> 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.
It doesn’t intend that A2::B2 derives B2 but in this case where an
L2-anchor exists in between L3-anchor and stateless interworking
functions, the L2-anchor binds A2::B2 to B2. I think that some diagram
and clear notation would help to describe it.
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 |
+-----------------------------+--------+----------+
Yes, I agree.
Following generic comments will also be taken into account in a next
version. Thanks.
Cheers,
--satoru
## 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
