Hi Kentaro, I've replied to your previous mail that I hope it would answer to your questions.
On Tue, Aug 29, 2017 at 12:44 AM, Kentaro Ebisawa <ebike...@gmail.com> wrote: > Hi, > > > Q2) Down Link packet (SRv6 to existing network) > > > When the endpoint receives packet and the active segment of the > > > packet indicates the SID, the endpoint pop the SRH of the SID, and > > ... > > > > IPv6 Src: Origin Host > > IPv6 Dst: SL[n] > > Segment Left = n > > SL[m] = Encoded SID > > SL[m+1] = Segment m+1 > > SL[n] = Segment n > > Actually I think this differs for T.Insert case, where MN user packet is > IPv6. > # Unless I missed description that Stateless Interworking will always use > encapsulation mode even if user packet is IPv6. In DL, Stateless Interworking uses encapsulation for original IPv6 packet with IPv4 and tunnel header. > > > IPv6 Src: Origin Host > IPv6 Dst: SL[n] > Segment Left = n > SL[0] = MN address > SL[1] = Encoded SID > SL[n] = Segment n > > As I mentioned in the previous mail, SL indicates SL[1] at the interworking node. > And interworking segment should behave like below. > > When the endpoint receives packet and the active segment of the > packet indicates the SID, the endpoint pop the SRH of the SID, > >> Set IPv6 destination address as SL[0] (MN's address), and > then the endpoint encaps the payload with the encoded information in > the SID which are tunnel identifier of tunnel header, source and > destination IPv4 address of IPv4 header described in Figure 3. > Right, it looks more precise description to it. Thanks! > > Maybe having example packet headers described for each cases > (encap/insert, User Packet = IPv4/IPv6) will help this makes more easier to > understand. > > Absolutely yes, it's helpful to understand. I'll update the I-D with that example in next revision. Thanks, --satoru
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
