Re: [DMM] SRv6 for Mobile User-Plane
Hi Tom, I believe you are referring to section 4 of RFC8200 where it states: "Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet’s delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." We copy SID[SL] in to DA as we pass through different segments along the path. EH manipulation is allowed as long as we do it at nodes identified by the DA (In SR case this node owns the SID[SL] of course). Am I missing anything? Arashmid -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert Sent: 26 February 2018 15:24 To: Pablo Camarillo (pcamaril) Cc: satoru.matsush...@g.softbank.co.jp; cf(mailer list) ; Miya Kohno (mkohno) ; dmm@ietf.org; Voyer, Daniel Subject: Re: [DMM] SRv6 for Mobile User-Plane On Mon, Feb 26, 2018 at 12:05 PM, Pablo Camarillo (pcamaril) wrote: > Hello authors, DMM, > > > > I have reviewed your I-D on SRv6 for mobile user-plane and I would > like to make some proposals. I have already discussed and brainstormed > the details with some of the authors of the draft and they agree to > this changes, however I would like to get the WG feedback on it. > > > > Thank you, > > Pablo. > > > > I believe its straightforward to support IPv4 UE traffic by doing SRv6 > with T.Encaps behavior. Hence, I think this should be documented in the draft. > > The encapsulation behavior should be the default one, both for IPv4 > and IPv6 UE traffic. However, a specific provider is allowed to do SRH > insertion within a controlled domain > [draft-voyer-6man-extension-header-insertion-02] > for UE IPv6 traffic. Pablo, That draft received substantial pushback on 6man list. EH insertion is not allowed by RFC8200 and a host of points were raised why it shouldn't be allowed. The authors have not responded to this feedback yet. Also, IMO, the argument that it's okay to do this within a controlled domain is weak, such an argument could be used to pretty much justify anything one might do with protocols. Tom > > Also, in order to reduce overhead at the UPFs when using > encapsulation, I would replace the End.B6 function for a new End.MAP function. > > For example, if we consider the following topology: > > UEgNBUPF1UPF2 > > > > Then the uplink packet flow for the basic mode would look like this: > > UE_out: (A, Z) > > gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps > > UPF1_out: (gNB, U2::1) (A, Z) -> End.MAP > > UPF2_out: (A, Z) -> End.DT > > > > The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID. > > > > Notice that using encapsulation, if you compare it with today > user-plane using IPv6/GTP, the result is that SRv6 is just adding 40B > of overhead (IPv6 header), while GTP over IPv6 is using 56B (IPv6, UDP, GTP). > > > > === > > > > With respect to the aggregation mode, aside from using the > encapsulation mode as described before, I would also like to add a > note on the I-D on the fact that we can support the aggregation mode > without changes in the N2 > interface: > > The current I-D for aggregation mode assumes that the gNB (uplink) has > knowledge of an SR policy that contains all the SIDs belonging to TE, > NFV and so on. Even though the I-D does not describe how the gNB is > retrieving this information, I would like to make a statement on the > fact that there are two alternatives: > > A. The N2 interface is modified in order to signal a SID list to the gNB. > > B. The N2 interface is not modified. In this case, we signal through > the N2 interface an SRv6 BindingSID, that the gNB is going to resolve > into a SID list via an SDN controller either using PCEP, reverse DNS lookup > or LISP. > > > > I’m aware that the I-D focuses on the user-plane, however I believe > it’s important to state this alternatives since it simplifies the > adoption and reduces impact in the existing mobile architectures > (without going into the details on the mechanisms for each one of the > alternatives of LISP, PCEP, reverse DNS-lookup). > > > > === > > > > On the other hand, the current I-D proposes a mechanism for stateless > interworking with legacy access networks that doesn’t support SRv6 > (SGW and/or eNB). This mechanism presented in the I-D is limited to > IPv4/GTP legacy networks. I would like to propose a mechanism to > support interworking with legacy gNBs that does not support SRv6 but do > support IPv6/GTP. > > The main benefit comes from the fact that we can leverage an SRv6 > BindingSID to have remote classification and steering of the UE > traffic over an SR policy [draft-filsfils-spring-segment-routing-policy]. > > > > In this scenario, I propose that we add the notion of an SR GW -as the > current stateless interworking node in the I-D-. This SR GW can be > either a software based platform -e.g. VPP- or any ex
[DMM] (no subject)
___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF101 - Call for agenda items
Sri: Can you include this in the agenda? Topic Name: Optimized Mobile User Plane Solutions for 5G Presenter Name: Kalyani Bogineni Time: 30 minutes Draft Reference: draft-bogineni-dmm-optimized-mobile-user-plane-solutions-xy.txt Kalyani -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Friday, February 23, 2018 7:44 PM To: dmm@ietf.org Subject: [E] Re: [DMM] IETF101 - Call for agenda items Gentle reminder. The DMM WG scheduled is to meet in London, on Tuesday; 15:50-18:20; Afternoon session II. https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_101_agenda.html&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=OTSVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs&s=lYub_Nr7BCAucf6sLruhiltVbjxQQqjGoQ5cBvaVxNY&e= Please send your proposals that you want to be included in the agenda. Sri On 2/7/18, 1:16 PM, "dmm on behalf of Sri Gundavelli (sgundave)" wrote: >The DMM working group is planning to meet in IETF 101, at London. If >you need a presentation slot, please send your request to the chairs >with the following information. > > >Topic Name: >Presenter Name: >Time: >Draft Reference: > > >Thanks! >Dapeng & Sri > > > >> > >___ >dmm mailing list >dmm@ietf.org >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm >an_listinfo_dmm&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ& >r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=OT >SVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs&s=aHD_lLO6FH_eeWxMo1COnoB44JL >m1w359nC6QQzWwBg&e= ___ dmm mailing list dmm@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dmm&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=OTSVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs&s=aHD_lLO6FH_eeWxMo1COnoB44JLm1w359nC6QQzWwBg&e= ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] SRv6 for Mobile User-Plane
On Tue, Feb 27, 2018 at 10:23 AM, Arashmid Akhavain wrote: > Hi Tom, > I believe you are referring to section 4 of RFC8200 where it states: > > "Extension headers (except for the Hop-by-Hop Options header) are not > processed, inserted, or deleted by any node along a packet’s delivery > path, until the packet reaches the node (or each of the set of nodes, > in the case of multicast) identified in the Destination Address field > of the IPv6 header." > > We copy SID[SL] in to DA as we pass through different segments along the path. > EH manipulation is allowed as long as we do it at nodes identified by the DA > (In SR case this node owns the SID[SL] of course). > Am I missing anything? > Arashmid, When the SR is present in a packet that behavior is correct and complies with RFC8200-- the SR EH is only processed by nodes that are identified in the destination address. The question is how did the SR EH get set in the packet in the first place. If a host sourced a packet with extension headers then it conforms to RFC8200. Also, if an intermediate device performs encapsulation, say IP in IP, and sets the EH in the outer header then that is also conforms to RFC8200 since the device is taking the role of host in sourcing an encapsulated packet. However, if an intermediate device inserts an extension header into an IPv6 packet without encapsulation that is where the problem is. I think Pablo's comment was that this should be allowed in controlled domains. Tom > Arashmid > > > > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > Sent: 26 February 2018 15:24 > To: Pablo Camarillo (pcamaril) > Cc: satoru.matsush...@g.softbank.co.jp; cf(mailer list) ; > Miya Kohno (mkohno) ; dmm@ietf.org; Voyer, Daniel > > Subject: Re: [DMM] SRv6 for Mobile User-Plane > > On Mon, Feb 26, 2018 at 12:05 PM, Pablo Camarillo (pcamaril) > wrote: >> Hello authors, DMM, >> >> >> >> I have reviewed your I-D on SRv6 for mobile user-plane and I would >> like to make some proposals. I have already discussed and brainstormed >> the details with some of the authors of the draft and they agree to >> this changes, however I would like to get the WG feedback on it. >> >> >> >> Thank you, >> >> Pablo. >> >> >> >> I believe its straightforward to support IPv4 UE traffic by doing SRv6 >> with T.Encaps behavior. Hence, I think this should be documented in the >> draft. >> >> The encapsulation behavior should be the default one, both for IPv4 >> and IPv6 UE traffic. However, a specific provider is allowed to do SRH >> insertion within a controlled domain >> [draft-voyer-6man-extension-header-insertion-02] >> for UE IPv6 traffic. > > Pablo, > > That draft received substantial pushback on 6man list. EH insertion is not > allowed by RFC8200 and a host of points were raised why it shouldn't be > allowed. The authors have not responded to this feedback yet. Also, IMO, the > argument that it's okay to do this within a controlled domain is weak, such > an argument could be used to pretty much justify anything one might do with > protocols. > > Tom > >> >> Also, in order to reduce overhead at the UPFs when using >> encapsulation, I would replace the End.B6 function for a new End.MAP >> function. >> >> For example, if we consider the following topology: >> >> UEgNBUPF1UPF2 >> >> >> >> Then the uplink packet flow for the basic mode would look like this: >> >> UE_out: (A, Z) >> >> gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps >> >> UPF1_out: (gNB, U2::1) (A, Z) -> End.MAP >> >> UPF2_out: (A, Z) -> End.DT >> >> >> >> The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID. >> >> >> >> Notice that using encapsulation, if you compare it with today >> user-plane using IPv6/GTP, the result is that SRv6 is just adding 40B >> of overhead (IPv6 header), while GTP over IPv6 is using 56B (IPv6, UDP, GTP). >> >> >> >> === >> >> >> >> With respect to the aggregation mode, aside from using the >> encapsulation mode as described before, I would also like to add a >> note on the I-D on the fact that we can support the aggregation mode >> without changes in the N2 >> interface: >> >> The current I-D for aggregation mode assumes that the gNB (uplink) has >> knowledge of an SR policy that contains all the SIDs belonging to TE, >> NFV and so on. Even though the I-D does not describe how the gNB is >> retrieving this information, I would like to make a statement on the >> fact that there are two alternatives: >> >> A. The N2 interface is modified in order to signal a SID list to the gNB. >> >> B. The N2 interface is not modified. In this case, we signal through >> the N2 interface an SRv6 BindingSID, that the gNB is going to resolve >> into a SID list via an SDN controller either using PCEP, reverse DNS lookup >> or LISP. >> >> >> >> I’m aware that the I-D focuses on the user-plane, however I believe >> it’s important to state this alternatives since it simplifies the >> adoption and reduces im
[DMM] dmm - Requested session has been scheduled for IETF 101
Dear Sri Gundavelli, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmm Session 1 (2:30:00) Tuesday, Afternoon Session II 1550-1820 Room Name: Palace C size: 50 - Request Information: - Working Group Name: Distributed Mobility Management Area Name: Internet Area Session Requester: Sri Gundavelli Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: ipwave Second Priority: lpwan Third Priority: intarea People who must be present: Sri Gundavelli Suresh Krishnan Dapeng Liu Resources Requested: Special Requests: Preferred day: Monday - ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF101 - Call for agenda items
Sri: Please add the following if Charlie has not already requested. Topic Name: FPC update Time: 30 minutes Draft Reference: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp.txt Lyle -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Friday, February 23, 2018 7:44 PM To: dmm@ietf.org Subject: [E] Re: [DMM] IETF101 - Call for agenda items Gentle reminder. The DMM WG scheduled is to meet in London, on Tuesday; 15:50-18:20; Afternoon session II. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_meeting_101_agenda.html%26d%3DDwICAg%26c%3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ%26r%3DIdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT%26m%3DOTSVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs%26s%3DlYub_Nr7BCAucf6sLruhiltVbjxQQqjGoQ5cBvaVxNY%26e&data=02%7C01%7Clyle.t.bertz%40sprint.com%7C99419711144e4acc0b7508d57e14bb6c%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636553549876619847&sdata=nZtS8fKZAogt5WDtoJE2x%2BSL687LS9uTQHcMzjqPEtU%3D&reserved=0= Please send your proposals that you want to be included in the agenda. Sri On 2/7/18, 1:16 PM, "dmm on behalf of Sri Gundavelli (sgundave)" wrote: >The DMM working group is planning to meet in IETF 101, at London. If >you need a presentation slot, please send your request to the chairs >with the following information. > > >Topic Name: >Presenter Name: >Time: >Draft Reference: > > >Thanks! >Dapeng & Sri > > > >> > >___ >dmm mailing list >dmm@ietf.org >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldef >ense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailm&data= >02%7C01%7Clyle.t.bertz%40sprint.com%7C99419711144e4acc0b7508d57e14bb6c% >7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636553549876619847&sdata=4 >h7eVUi%2BAn4st70TnM72Zus2yZzDa2zq%2Bmjsyl5pitk%3D&reserved=0 >an_listinfo_dmm&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ& >r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=OT >SVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs&s=aHD_lLO6FH_eeWxMo1COnoB44JL >m1w359nC6QQzWwBg&e= ___ dmm mailing list dmm@ietf.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_dmm%26d%3DDwICAg%26c%3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ%26r%3DIdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT%26m%3DOTSVgI3ozPhs0c_LOcx1PVChX2jyMh1y88CmUR34HQs%26s%3DaHD_lLO6FH_eeWxMo1COnoB44JLm1w359nC6QQzWwBg%26e&data=02%7C01%7Clyle.t.bertz%40sprint.com%7C99419711144e4acc0b7508d57e14bb6c%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636553549876619847&sdata=K7xP51wxvCzY%2BQHZxTCZr7yBQGHYyFnfr1RZD4W3XJ0%3D&reserved=0= ___ dmm mailing list dmm@ietf.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7Clyle.t.bertz%40sprint.com%7C99419711144e4acc0b7508d57e14bb6c%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636553549876629856&sdata=H0NCCFi7AlJJiFANpx3EgNipqqPsuAm4hHDkp76tE%2BU%3D&reserved=0 This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
