Subject: [DMM] review comments on draft-ietf-dmm-srv6-mobile-uplane-00

From: "Kentaro Ebisawa" <[email-masked]>
Date: Sat, 02 Dec 2017 04:37:05 +0000

Hi,

Please find my review comments for draft-ietf-dmm-srv6-mobile-uplane-00.

## 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.

 > 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.

 > 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?

 > 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.

 > 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.

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 |
+-----------------------------+--------+----------+

## 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-masked]> | Mailing Lists: <[email-masked]>

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 5 Dec 2017 18:35:37 +0900

Hi Ebisawa-san,

Thank you for your review. That’s helpful. Please see my comments in line:

> [...]

> 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 doesn't mention about PSP (pop SRH from packet) which is described in 6.3.2.
> 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.

> Since it's not defined, adding description what is D might make it more clear.
> 
> 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.

> 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.

> 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.
> 

Yes, I agree. 

Following generic comments will also be taken into account in a next version. Thanks.

Cheers,
--satoru

> 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.

---

From: "Kentaro Ebisawa" <[email-masked]>
Date: Wed, 06 Dec 2017 02:24:38 +0000

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,

------ Original Message ------
From: "Satoru Matsushima" <[email-masked]>
To: "Kentaro Ebisawa" <[email-masked]>
Cc: "dmm" <[email-masked]>
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 

>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.

>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.

>Interworking SID Encoding and not prefix?

Yes, correct. I’ll do fix it with appropriate diagram which Charlie 
pointed out.

>Might be more clear if you can describe the format of A2::B2 and how to 

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.

Yes, I agree.

Following generic comments will also be taken into account in a next 
version. Thanks.

Cheers,
--satoru

>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.