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