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
