Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

Dear Sridhar,

It’s nice to see you in DMM list as well. :-)

> [...snip...]


> 1. Section 5.2.2 of the draft says,
> 
> UPF2_in : (Z,A)  -> UPF2 maps the flow w/
>SID list  
> 
> When the packet arrives to the UPF2, the UPF2 will map that
>   particular flow into a UE session.
> 
> Does this mean the UPF2 is aware of the gNB the UE is latched on and hence 
> after each mobility, the information regarding current gNB is signaled / 
> programmed till the UPF2 (which could be the PDU session anchor UPF)?

Right. It’s equivalent with GTP-U case where there’s no N9 along the path.
One significant difference between GTP-U and enhanced mode is that the packets 
of PDU sessions which belong to a same SR policy will use same set of SIDs in 
the header.


> 
> 2. For traditional mode (basic mode), could you please elaborate on the MTU 
> overhead being less than GTPU? GTPU encap MTU overhead = 20 octets outer IPv4 
> header + 8 octets UDP header + 12 octets GTPU header + Extension header for 
> QFI. SRv6 encap MTU overhead = 40 octets IPv6 header + EH for carrying QFI 
> (this part is not clear - see my next question). In your blog 
> https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/
>  I noticed in Fig.1 the MPLS / TE headers included in calculation. So does 
> the MTU overhead saving talked about for SRv6 assume that underlay TE 
> technologies are replaced? It is not clear from the draft. If there are any 
> other drafts that provide a clear calculation on the MTU savings, could you 
> please point to them?

I hope that the following spreadsheet helps for that purpose. I’ve updated it 
align to the latest draft after I shared it in last month. 

https://docs.google.com/spreadsheets/d/1Fx8ilE_bQPkhFBoSd-qRS5ok2IO1i0VZbmwzZJNVh0g/edit?usp=sharing

As the draft says that traditional mode is as same as existing user plane 
protocol, it is also equivalent in terms of overhead size.
You can find that both GTP-U and traditional mode of SRv6 cost 58 bytes as the 
overhead.


> 
> 3. How to encode QFI, RQI in SRv6 (both traditional mode and enhanced mode)? 
> In GTPU the QFI/RQI markings are carried in a GTPU extension header, defined 
> as a container. Please refer the following documents for details

Thank you for those latest references! Actually I was seeking them from last 
CT4 meeting folder. ;-)

And yes, we still leave it at this time since defining 3GPP specific extension 
headers and messages should be up to 3GPP decision. 
We don’t want to violate that responsibility. Nevertheless, in case that those 
GTP-U extension header and messages are carried as its encoding, TLV in SRH 
would work to do that with just one or few code points to 3GPP which looks not 
big deal. If you are interested, it would be nice if we can write a draft with 
that idea with you and John.

Cheers,
--satoru

> 
> Incoming LS from RAN3 to CT4: 
> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182214.zip
> 
> Corresponding agreed CR in CT4: 
> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182246.zip
> 
> LS out from CT4 to RAN3: 
> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182247.zip
> 
> Thanks
> Sridhar
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Tuesday, March 13, 2018 6:55 AM
> To: John Kaippallimalil 
> Cc: dmm 
> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> John,
> 
>> 2018/03/13 7:37、John Kaippallimalil のメール:
>> 
>> A few questions for clarification:
>> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push 
>> an SRH..."
>> In this case the outer IPv6 address representing a SID would contain a TEID.
>> So for 1000 PDU sessions - would there be as many IPv6 addresses 
>> (representing SIDs/TEID in the outer header)
> 
> Right. It is not limited but in a typical case given that a /64 per node for 
> the SID space which allows each node allocate a SID per session basis.
> 
> 
>> 
>> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on 
>> path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns 
>> - S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to chain 
>> functions along the path to UPF1,
>>  or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
>> upto the anchor UPF2. 
> 
> Please see the section 5.2.1 of packet flow on uplink.
> We assume that there’s no UPF1 along the path in the diagram.
> 
> 
>> 
>> 3.  Section 5.2, "The SR policy MAY include SIDs for traffic engineering and 
>> service chaining ..."
>> 3GPP service chaining is at N6 interface, but in this case, is the policy 
>> for traffic steering implemented at 

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Sridhar Bhaskaran]

Dear Satoru,

I am Sridhar Bhaskaran - 3GPP CT4 delegate. In addition to John's questions, I 
have few more questions for clarification.

1. Section 5.2.2 of the draft says,

UPF2_in : (Z,A)  -> UPF2 maps the flow w/
SID list  

When the packet arrives to the UPF2, the UPF2 will map that
   particular flow into a UE session.

Does this mean the UPF2 is aware of the gNB the UE is latched on and hence 
after each mobility, the information regarding current gNB is signaled / 
programmed till the UPF2 (which could be the PDU session anchor UPF)?

2. For traditional mode (basic mode), could you please elaborate on the MTU 
overhead being less than GTPU? GTPU encap MTU overhead = 20 octets outer IPv4 
header + 8 octets UDP header + 12 octets GTPU header + Extension header for 
QFI. SRv6 encap MTU overhead = 40 octets IPv6 header + EH for carrying QFI 
(this part is not clear - see my next question). In your blog 
https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/
 I noticed in Fig.1 the MPLS / TE headers included in calculation. So does the 
MTU overhead saving talked about for SRv6 assume that underlay TE technologies 
are replaced? It is not clear from the draft. If there are any other drafts 
that provide a clear calculation on the MTU savings, could you please point to 
them?

3. How to encode QFI, RQI in SRv6 (both traditional mode and enhanced mode)? In 
GTPU the QFI/RQI markings are carried in a GTPU extension header, defined as a 
container. Please refer the following documents for details

Incoming LS from RAN3 to CT4: 
http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182214.zip

Corresponding agreed CR in CT4: 
http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182246.zip

LS out from CT4 to RAN3: 
http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182247.zip
 
Thanks
Sridhar

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: Tuesday, March 13, 2018 6:55 AM
To: John Kaippallimalil 
Cc: dmm 
Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

John,

> 2018/03/13 7:37、John Kaippallimalil のメール:
> 
> A few questions for clarification:
> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push an 
> SRH..."
> In this case the outer IPv6 address representing a SID would contain a TEID.
> So for 1000 PDU sessions - would there be as many IPv6 addresses 
> (representing SIDs/TEID in the outer header)

Right. It is not limited but in a typical case given that a /64 per node for 
the SID space which allows each node allocate a SID per session basis.


> 
> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on 
> path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns - 
> S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to chain 
> functions along the path to UPF1,
>   or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
> upto the anchor UPF2. 

Please see the section 5.2.1 of packet flow on uplink.
We assume that there’s no UPF1 along the path in the diagram.


> 
> 3.  Section 5.2, "The SR policy MAY include SIDs for traffic engineering and 
> service chaining ..."
> 3GPP service chaining is at N6 interface, but in this case, is the policy for 
> traffic steering implemented at the N3  interface.
> Would PCF/SMF provision this at gNB.

When it comes to enhanced mode for control-plane side, it may literally be 
enhanced.
But at this revision of the draft, it is assumed that gNB is capable to resolve 
SR policy from remote endpoint address of tunnel to SIDs list while N2 is 
unchanged and kept as it is.

Cheers,
--satoru


> 
> Thanks,
> John
> 
> 
> 
> -Original Message-
> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
> Sent: Mittwoch, 7. März 2018 12:23
> To: Marco Liebsch
> Cc: dmm
> Subject: Re: [DMM] Fwd: I-D Action: 
> draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> Marco,
> 
>> 2018/03/07 18:41、Marco Liebsch のメール:
>> 
>> Satoru,
>> 
>> since I read this at different places, let me ask one clarifying question 
>> about the stateless motivation: 
>> 
>> I see that for SRv6 you may not need a state at the egress (at least 
>> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need 
>> a state at both edges of the communication since the DL egress serves as 
>> uplink ingress, correct?
> 
> 2x unidirectional tunnels to form bidirectional paths require 4 states in 
> total at both the ingress and egress.
> In SR case it requires just 2 states at the ingresses for both directions.
> 
> Cheers,
> --satoru
> 
> 
> 
>> 
>> marco
>> 
>> 
>> -Original Message-
>> From: dmm 

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Satoru Matsushima]

John,

> 2018/03/13 7:37、John Kaippallimalil のメール:
> 
> A few questions for clarification:
> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push an 
> SRH..."
> In this case the outer IPv6 address representing a SID would contain a TEID.
> So for 1000 PDU sessions - would there be as many IPv6 addresses 
> (representing SIDs/TEID in the outer header)

Right. It is not limited but in a typical case given that a /64 per node for 
the SID space which allows each node allocate a SID per session basis.


> 
> 2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on path (gNB 
> --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns - S1, C1)
> Would the SR path at gNB (uplink) be (a) the list of SIDs to chain functions 
> along the path to UPF1,
>   or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
> upto the anchor UPF2. 

Please see the section 5.2.1 of packet flow on uplink.
We assume that there’s no UPF1 along the path in the diagram.


> 
> 3.  Section 5.2, "The SR policy MAY include SIDs for traffic engineering and 
> service chaining ..."
> 3GPP service chaining is at N6 interface, but in this case, is the policy for 
> traffic steering implemented at the N3  interface.
> Would PCF/SMF provision this at gNB.

When it comes to enhanced mode for control-plane side, it may literally be 
enhanced.
But at this revision of the draft, it is assumed that gNB is capable to resolve 
SR policy from remote endpoint address of tunnel to SIDs list while N2 is 
unchanged and kept as it is.

Cheers,
--satoru


> 
> Thanks,
> John
> 
> 
> 
> -Original Message-
> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
> Sent: Mittwoch, 7. März 2018 12:23
> To: Marco Liebsch
> Cc: dmm
> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> Marco,
> 
>> 2018/03/07 18:41、Marco Liebsch のメール:
>> 
>> Satoru,
>> 
>> since I read this at different places, let me ask one clarifying question 
>> about the stateless motivation: 
>> 
>> I see that for SRv6 you may not need a state at the egress (at least 
>> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need a 
>> state at both edges of the communication since the DL egress serves as 
>> uplink ingress, correct?
> 
> 2x unidirectional tunnels to form bidirectional paths require 4 states in 
> total at both the ingress and egress.
> In SR case it requires just 2 states at the ingresses for both directions.
> 
> Cheers,
> --satoru
> 
> 
> 
>> 
>> marco
>> 
>> 
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
>> Sent: Dienstag, 6. März 2018 17:23
>> To: Tom Herbert
>> Cc: dmm
>> Subject: Re: [DMM] Fwd: I-D Action: 
>> draft-ietf-dmm-srv6-mobile-uplane-01.txt
>> 
>> Hello Tom,
>> 
 A Big progress is that the draft supports interworking with GTP over
 IPv6 in addition to GTP over IPv4.
 And we have made change SRv6 function to IPv6 encapsulation with SRH 
 instead of SRH insertion by default.
 
>>> 
>>> Hi Satoru,
>>> 
>>> If there are no intermediate hops od SIDs being set when 
>>> encapsulating would a SR header still be needed or could this just be 
>>> simple IP in IP encpasulation?  If is no SR header then it's possible 
>>> that ILA might then be used to completely eliminate the encapsulation 
>>> overhead.
>> 
>> I think you’re right. You would find that case in the draft as ‘Traditional 
>> Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA 
>> is also equivalent with that mode. In addition, this draft introduces 
>> ‘Enhance Mode’ to cover more advanced cases.
>> 
>> IMO SR is designed not to maintain path states except at an ingress node. So 
>> the packet need to preserve original DA in the header that keep the egress 
>> node in stateless. It would be great if ILA is designed in the similar 
>> concept as well.
>> 
>> If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
>> keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
>> choose which one need to be prioritized would depend on each deployment case 
>> in operators IMO.
>> 
>> Cheers,
>> --satoru
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[John Kaippallimalil]

A few questions for clarification:
1. Section 5.1.1, "..Since there is only one SID, there is no need to push an 
SRH..."
In this case the outer IPv6 address representing a SID would contain a TEID.
So for 1000 PDU sessions - would there be as many IPv6 addresses (representing 
SIDs/TEID in the outer header)

2.  Section 5.2 (& Figure 3), suppose there were more than 1 UPF on path (gNB 
--> UPF1 --> UPF2 as in the example in 5.1 but now with other fns - S1, C1)
Would the SR path at gNB (uplink) be (a) the list of SIDs to chain functions 
along the path to UPF1,
   or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. 
upto the anchor UPF2. 

3.  Section 5.2, "The SR policy MAY include SIDs for traffic engineering and 
service chaining ..."
3GPP service chaining is at N6 interface, but in this case, is the policy for 
traffic steering implemented at the N3  interface.
 Would PCF/SMF provision this at gNB.

Thanks,
John



-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com]
Sent: Mittwoch, 7. März 2018 12:23
To: Marco Liebsch
Cc: dmm
Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

Marco,

> 2018/03/07 18:41、Marco Liebsch のメール:
> 
> Satoru,
> 
> since I read this at different places, let me ask one clarifying question 
> about the stateless motivation: 
> 
> I see that for SRv6 you may not need a state at the egress (at least 
> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need a 
> state at both edges of the communication since the DL egress serves as uplink 
> ingress, correct?

2x unidirectional tunnels to form bidirectional paths require 4 states in total 
at both the ingress and egress.
In SR case it requires just 2 states at the ingresses for both directions.

Cheers,
--satoru



> 
> marco
> 
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima
> Sent: Dienstag, 6. März 2018 17:23
> To: Tom Herbert
> Cc: dmm
> Subject: Re: [DMM] Fwd: I-D Action: 
> draft-ietf-dmm-srv6-mobile-uplane-01.txt
> 
> Hello Tom,
> 
>>> A Big progress is that the draft supports interworking with GTP over
>>> IPv6 in addition to GTP over IPv4.
>>> And we have made change SRv6 function to IPv6 encapsulation with SRH 
>>> instead of SRH insertion by default.
>>> 
>> 
>> Hi Satoru,
>> 
>> If there are no intermediate hops od SIDs being set when 
>> encapsulating would a SR header still be needed or could this just be 
>> simple IP in IP encpasulation?  If is no SR header then it's possible 
>> that ILA might then be used to completely eliminate the encapsulation 
>> overhead.
> 
> I think you’re right. You would find that case in the draft as ‘Traditional 
> Mode’ which is equivalent with traditional GTP-U case. You seem you say ILA 
> is also equivalent with that mode. In addition, this draft introduces 
> ‘Enhance Mode’ to cover more advanced cases.
> 
> IMO SR is designed not to maintain path states except at an ingress node. So 
> the packet need to preserve original DA in the header that keep the egress 
> node in stateless. It would be great if ILA is designed in the similar 
> concept as well.
> 
> If it’s not, it looks a kind of tradeoff, between reducing the overhead and 
> keeping the statelessness. It’s not apple-to-apple comparison. To decide to 
> choose which one need to be prioritized would depend on each deployment case 
> in operators IMO.
> 
> Cheers,
> --satoru
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Carlos Jesús Bernardos Cano]

Hi Akbar,

Thanks for the review. Comments inline below.

On Mon, 2018-03-12 at 16:41 +, Rahman, Akbar wrote:
> Hi Carlos,
> 
> 
> Thanks for the updates.  I think the document is in good shape and
> should be adopted.
> 
> I did have some small suggestions though for the next revision:
> 
> 1) Abstract - Suggest to remove the last paragraph on "distributed
> logical interface" as it appears to be a detail and is not very clear
> anyways at this point in the document what it implies.  If you want
> to keep the paragraph it should be further clarified as it is not
> clear what "a software construct" implies?

[Carlos] OK, well clarify this further.

> 
> 2) Figures 2, 3, & 4  - Suggest to replace use of the "?" in the
> ASCII figure construction with another symbol (such as used in Figure
> 1).

[Carlos] This will be fixed in -02.

> 
> 3) Section 3.6 - Need to better clarify in the 1st paragraph text in
> which node the "software construct" of the DLIF is located.  And
> also, not clear currently why a node internal software construct
> needs to be discussed in a protocol document.  So probably just my
> lack of understanding but points to the section requiring further
> clarity.

[Carlos] Will clarify in -02.

Thanks!

Carlos

> 
> 
> Best Regards,
> 
> Akbar
> 
> 
> -Original Message-
> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
> Sent: Wednesday, March 7, 2018 10:21 AM
> To: c...@it.uc3m.es; dmm@ietf.org
> Subject: Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-
> 01.txt]
> 
> Thanks Carlos.
> 
> Folks - Please review the document and post your feedback.
> 
> https://tools.ietf.org/id/draft-bernardos-dmm-pmipv6-dlif-01.txt
> 
> 
> 
> At IETF100, we polled the WG feedback for adopting this document and
> there was consensus for adopting this document. However, we chose not
> to adopt the document as there were no recent discussions in the
> mailer on this document. We therefore request the WG for feedback in
> the mailer. We plan to issue an adoption call post IETF101, but we
> need some feedback and substantial comments.
> 
> 
> Dapeng & Sri
> 
> 
> 
> 
> On 3/6/18, 2:17 PM, "dmm on behalf of Carlos Jesús Bernardos Cano"
>  wrote:
> 
> > Hi,
> > 
> > We have submitted a revised version of our draft addressing the
> > comments we got in Singapore:
> > 
> > - Added some statements about which model from draft-ietf-dmm-
> > deployment-models our solution follows (addressing a comment
> > received
> > from Sri).
> > - Added some text relating to draft-ietf-dmm-ondemand-mobility
> > (addressing a comment received from Danny).
> > 
> > Additionally, we added some terminology from draft-ietf-dmm-
> > deployment-
> > models and other minor changes.
> > 
> > In Singapore we got quite good support of the document. I'd like to
> > request feedback/reviews from the WG.
> > 
> > Thanks!
> > 
> > Carlos
> 
> [Banner]
> This e-mail is intended only for the use of the individual or entity
> to which it is addressed, and may contain information that is
> privileged, confidential and/or otherwise protected from disclosure
> to anyone other than its intended recipient. Unintended transmission
> shall not constitute waiver of any privilege or confidentiality
> obligation. If you received this communication in error, please do
> not review, copy or distribute it, notify me immediately by email,
> and delete the original message and any attachments. Unless expressly
> stated in this e-mail, nothing in this message or any attachment
> should be construed as a digital or electronic signature.
> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Rahman, Akbar]

Hi Carlos,


Thanks for the updates.  I think the document is in good shape and should be 
adopted.  

I did have some small suggestions though for the next revision:

1) Abstract - Suggest to remove the last paragraph on "distributed logical 
interface" as it appears to be a detail and is not very clear anyways at this 
point in the document what it implies.  If you want to keep the paragraph it 
should be further clarified as it is not clear what "a software construct" 
implies?

2) Figures 2, 3, & 4  - Suggest to replace use of the "?" in the ASCII figure 
construction with another symbol (such as used in Figure 1).

3) Section 3.6 - Need to better clarify in the 1st paragraph text in which node 
the "software construct" of the DLIF is located.  And also, not clear currently 
why a node internal software construct needs to be discussed in a protocol 
document.  So probably just my lack of understanding but points to the section 
requiring further clarity.


Best Regards,

Akbar


-Original Message-
From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] 
Sent: Wednesday, March 7, 2018 10:21 AM
To: c...@it.uc3m.es; dmm@ietf.org
Subject: Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

Thanks Carlos.

Folks - Please review the document and post your feedback.

https://tools.ietf.org/id/draft-bernardos-dmm-pmipv6-dlif-01.txt



At IETF100, we polled the WG feedback for adopting this document and there was 
consensus for adopting this document. However, we chose not to adopt the 
document as there were no recent discussions in the mailer on this document. We 
therefore request the WG for feedback in the mailer. We plan to issue an 
adoption call post IETF101, but we need some feedback and substantial comments.


Dapeng & Sri




On 3/6/18, 2:17 PM, "dmm on behalf of Carlos Jesús Bernardos Cano"
 wrote:

>Hi,
>
>We have submitted a revised version of our draft addressing the 
>comments we got in Singapore:
>
>- Added some statements about which model from draft-ietf-dmm- 
>deployment-models our solution follows (addressing a comment received 
>from Sri).
>- Added some text relating to draft-ietf-dmm-ondemand-mobility 
>(addressing a comment received from Danny).
>
>Additionally, we added some terminology from draft-ietf-dmm-deployment- 
>models and other minor changes.
>
>In Singapore we got quite good support of the document. I'd like to 
>request feedback/reviews from the WG.
>
>Thanks!
>
>Carlos

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Carlos Jesús Bernardos Cano]

Hi Alex,

On Mon, 2018-03-12 at 11:06 +0100, Alexandre Petrescu wrote:
> 
> Le 12/03/2018 à 00:58, Carlos Jesús Bernardos Cano a écrit :
> [...]
> > > However, I have difficulty to grasp the term 'distributed
> > > logical 
> > > interface'.  It sounds as if the same interface name, e.g.
> > > 'mn1mar1', was present on both MAAR1 and MAAR2.  In reality, only
> > > the triplet 'MAC address', 'link-local address' and the 'global
> > > prefix' are same on MAAR1 and MAAR2 interfaces.  These latter are
> > > called differently, though: 'mn1mar1' and 'mn1mar2'.
> > 
> > [Carlos] The triplet are the same, but we also use the same name of
> > the interface in the diagrams (in the system, the name of the
> > interface does not matter, could be called in anyway, the important
> > point is the triplet you mentioned). 'mn1mar1' refers to the
> > logical
> > interface (i.e., triplet) exposed by MAAR1 to MN1 for the prefix
> > anchored by MAAR1 to MN1. 'mn1mar2' refers to the logical interface
> > (i.e., triplet) exposed by MAAR2 to MN1 for the prefix anchored by
> > MAAR2 to MN1. If the MN is using addresses from both the prefixes
> > anchored at MAAR1 and MAAR2, while the MN is attached to MAAR2,
> > 'mn1mar1' and 'mn1mar2' logical interfaces will be configured at
> > MAAR2.
> > 
> > > 
> > > Maybe the DLIF could be named 'mn1marx'.  But I dont think you 
> > > ifconfig 'mn1marx' whereas I am almost sure you do ifconfig
> > > mn1mar1
> > > and ifconfig mn1mar2.
> > 
> > [Carlos] Please check the previous and let me know if you agree.
> 
> Yes, I checked and I agree as long as DLIF is a concept, not one
> interface.

[Carlos] OK.

> 
> [...]
> 
> > > > Prefix Length
> > > > 
> > > > 8-bit unsigned integer indicating the prefix length of the
> > > > IPv6 
> > > > prefix contained in the option.
> > > 
> > > This 'Prefix Length' variable appears several times in the
> > > message 
> > > formats, yet all the examples of prefixes shown in the draft are
> > > of length precisely 64.  I do not understand why.
> > > 
> > > In order to illustrate that is true variable, can we have one of
> > > the examples that says '63' instead of '64'?
> > > 
> > > Otherwise, it may sound little logical to keep that as variable.
> > > Just use /64s everywhere and dont transmit Prefix Length in no
> > > message.
> > 
> > [Carlos] We include the Prefix Length option as in the HNP option
> > of 
> > RFC 5213 and the MNP option of RFC3963. But we foresee that this
> > value will be equal to 64 in most cases, as the prefix length in
> > IPv6
> > is typically 64-bits. Do you think we should also have examples
> > with
> > other prefix lengths?
> 
> I think other-than-64 prefix lengths should be feasible.
> 
> For RFC3963: the prefix length is variable in order to accommodate 
> mobile routers.
> 
> For RFC5213: why is there a variable prefix  length if this value is 
> foreseen to be equal to 64 in most cases?  What is the particular
> case 
> where that prefix length is not 64?

[Carlos] I think it was put there to be flexible and allow for other
cases in the future. We can document in our draft that other prefix
lengths are possible.

Thanks,

Carlos

> 
> Alex

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-01.txt]

[Alexandre Petrescu]

Le 12/03/2018 à 00:58, Carlos Jesús Bernardos Cano a écrit :
[...]
However, I have difficulty to grasp the term 'distributed logical 
interface'.  It sounds as if the same interface name, e.g.

'mn1mar1', was present on both MAAR1 and MAAR2.  In reality, only
the triplet 'MAC address', 'link-local address' and the 'global
prefix' are same on MAAR1 and MAAR2 interfaces.  These latter are
called differently, though: 'mn1mar1' and 'mn1mar2'.


[Carlos] The triplet are the same, but we also use the same name of
the interface in the diagrams (in the system, the name of the
interface does not matter, could be called in anyway, the important
point is the triplet you mentioned). 'mn1mar1' refers to the logical
interface (i.e., triplet) exposed by MAAR1 to MN1 for the prefix
anchored by MAAR1 to MN1. 'mn1mar2' refers to the logical interface
(i.e., triplet) exposed by MAAR2 to MN1 for the prefix anchored by
MAAR2 to MN1. If the MN is using addresses from both the prefixes
anchored at MAAR1 and MAAR2, while the MN is attached to MAAR2,
'mn1mar1' and 'mn1mar2' logical interfaces will be configured at
MAAR2.



Maybe the DLIF could be named 'mn1marx'.  But I dont think you 
ifconfig 'mn1marx' whereas I am almost sure you do ifconfig mn1mar1

and ifconfig mn1mar2.


[Carlos] Please check the previous and let me know if you agree.


Yes, I checked and I agree as long as DLIF is a concept, not one interface.

[...]


Prefix Length

8-bit unsigned integer indicating the prefix length of the IPv6 
prefix contained in the option.


This 'Prefix Length' variable appears several times in the message 
formats, yet all the examples of prefixes shown in the draft are

of length precisely 64.  I do not understand why.

In order to illustrate that is true variable, can we have one of
the examples that says '63' instead of '64'?

Otherwise, it may sound little logical to keep that as variable.
Just use /64s everywhere and dont transmit Prefix Length in no
message.


[Carlos] We include the Prefix Length option as in the HNP option of 
RFC 5213 and the MNP option of RFC3963. But we foresee that this

value will be equal to 64 in most cases, as the prefix length in IPv6
is typically 64-bits. Do you think we should also have examples with
other prefix lengths?


I think other-than-64 prefix lengths should be feasible.

For RFC3963: the prefix length is variable in order to accommodate 
mobile routers.


For RFC5213: why is there a variable prefix  length if this value is 
foreseen to be equal to 64 in most cases?  What is the particular case 
where that prefix length is not 64?


Alex

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm