Re: review comments on draft-ietf-dmm-srv6-mobile-uplane-00

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