Re: [DMM] IETF#90 DMM agenda update
On 7/23/14 10:49 AM, Behcet Sarikaya wrote: > On Wed, Jul 23, 2014 at 9:36 AM, Brian Haberman > wrote: >> >> >> On 7/23/14 10:16 AM, Behcet Sarikaya wrote: >>> So my question is what guarantees that is the DT is going to produce >>> the right solution and why repeat the history again? >>> >> >> Who said that *if* a DT is formed that its output is considered special? >> >> http://www.ietf.org/iesg/statement/design-team.html >> > > My point is that at this time in dmm I can not see any justification > for forming a design team to develop a solution or parts of a > solution. Jouni pointed out that the DT approach is just an option. > We already have solutions and it seems like at least one of them is > implemented. I don't think it is reasonable to expect any deployment > now. > In view of this I am unable to see the need for some many items in the > proposed charter. > > Regards, > > Behcet >> >> ___ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
On Wed, Jul 23, 2014 at 9:36 AM, Brian Haberman wrote: > > > On 7/23/14 10:16 AM, Behcet Sarikaya wrote: >> So my question is what guarantees that is the DT is going to produce >> the right solution and why repeat the history again? >> > > Who said that *if* a DT is formed that its output is considered special? > > http://www.ietf.org/iesg/statement/design-team.html > My point is that at this time in dmm I can not see any justification for forming a design team to develop a solution or parts of a solution. We already have solutions and it seems like at least one of them is implemented. I don't think it is reasonable to expect any deployment now. In view of this I am unable to see the need for some many items in the proposed charter. Regards, Behcet > > ___ > 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] IETF#90 DMM agenda update
On 7/23/14 10:16 AM, Behcet Sarikaya wrote: > So my question is what guarantees that is the DT is going to produce > the right solution and why repeat the history again? > Who said that *if* a DT is formed that its output is considered special? http://www.ietf.org/iesg/statement/design-team.html signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
Behcet, 7/23/2014 5:16 PM, Behcet Sarikaya kirjoitti: Hi Jouni, On Tue, Jul 22, 2014 at 9:49 AM, Jouni Korhonen wrote: Folks, meetings and setting up small groups (or design teams) to work on the ^^^ Design teams? Exact form is still to be decided. - Jouni ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
Hi Jouni, On Tue, Jul 22, 2014 at 9:49 AM, Jouni Korhonen wrote: > Folks, > > The agenda has been slightly updated (shuffling around the slots and > arranging more time to the charter/next steps discussion). Some presenters > are affected slightly (-5 minutes). see > http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm > > Regarding the re-chartering and the next steps. We have a tight deadline to > meet if we want to ship the new charter text to the next IESG telechat. > Brian will reveal the gory details of the expected re-chartering process and > timelines. > > We are also supposed to come up (again) with a rought agreement of the > deployment architecture(s) that DMM "functional elements" map into. This > will be discussed as a part of the re-chartering slot and recapping the > discussions we had earlier. > > We are also supposed to come up with a rough agreement how to progress from > now on. This could mean (note the conditionality here) a series of interim > meetings and setting up small groups (or design teams) to work on the > initial set of the solution space drafts. We need to step out of the > "progress every second IETF meeting" mode ;) Design teams? Do you know about netlmm experience? I looked at netlmm WG pages on tools.ietf.org. DT had a draft: http://tools.ietf.org/html/draft-giaretta-netlmm-dt-protocol-02 Please look at this protocol and compare with RFC 5213 which was the final product of netlmm. Some of you may remember, PMIPv6 proposal came in from nowhere and in a historic WG meeting that proposal took over. So my question is what guarantees that is the DT is going to produce the right solution and why repeat the history again? Regards, Behcet > > Also keep in mind that the start of the new work poses some serialization > whether we want or now: first stabilize charter & reach rough consensus on > the deployment models/functional elements. These can be done in parallel. > Note that rough consensus does not mean a ready spec or spec at all. Second > execute with the solutions space.. the deployment models work might benefit > from having a slight heads up before other drafts. These can be done in > parallel, though. As a reminder, the charter may change on the route before > it gets approved but we can do the opportunistic thing and start working as > if the charter were already "approved" when the WG ships it. > > - Jouni & Dapeng > > ___ > 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] IETF#90 DMM agenda update
So, what is your point ? Can we elevate the discussion to some decent levels and focus on technicals ? What we are discussing is an architectural approach that addresses DMM Requirements; This is what we discussed with number of people and have agreements. Now we are discussing with a larger group. Like any other other proposal, this does not have a WG status and is only a proposal. Nothing in the process requires I-D for discussion. I've done many such presentations prior to publishing -00 version. Sri On 7/23/14 6:40 AM, "Behcet Sarikaya" wrote: >I am not against any work which is based on an existing draft. I spoke >against having a long presentation and there is no draft. > >Another point here is, yesterday I discussed with Marco on this. Any >architecture and so called deployment proposal has a sense of solution >in it. I don't buy the argument that the architecture is generic and >that the deployment is generic. >At this point in time there is no such thing. Such proposals represent >the authors solution approach.They are reading other solution >proposals and they don't like some aspects in those solution drafts >and they want to present some alternative approaches. > >So, as I said before, Marco, Sri, Pierrick, if there are any others, >are free to write drafts making it clear that in the draft they are >talking about their own solution. There is nothing wrong with it. > >I hope this makes my point clear. > >Regards, > >Behcet > >On Wed, Jul 23, 2014 at 4:36 AM, wrote: >> Thanks Pierrick for the pointer! >> And FWIW also Marcos draft-liebsch-dmm-framework-03 addresses >>deployment and architecture aspects for evaluating various approaches >> BR >> Dirk >> -Original Message- >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of >>pierrick.se...@orange.com >> Sent: Mittwoch, 23. Juli 2014 10:13 >> To: sarik...@ieee.org; Sri Gundavelli (sgundave) >> Cc: dmm@ietf.org >> Subject: Re: [DMM] IETF#90 DMM agenda update >> >> >> >>>-Message d'origine- >>>De : dmm [mailto:dmm-boun...@ietf.org] De la part de Behcet Sarikaya >>>Envoyé : mardi 22 juillet 2014 19:04 À : Sri Gundavelli (sgundave) Cc : >>>dmm@ietf.org Objet : Re: [DMM] IETF#90 DMM agenda update >>> >>>On Tue, Jul 22, 2014 at 12:00 PM, Sri Gundavelli (sgundave) >>> wrote: >>>> I think you are mixing the topics here. >>> >>>I am not sure who? >>>How can you talk about deployment without having a solution? >>>Deployment where? >>> >>>> >>>> Any case, I don't have plans to write one .. >>> >>>I know that and that's why I kept asking, just in case you might change >>>your mind. >>> >>>Maybe you can write a draft evaluating existing proposals from your >>>"architecture" and your "deployment" point of view. >>> >> >> Worth to be considered IMHO: draft-liu-dmm-deployment-scenario >> >>>Behcet >>> >>>> >>>> >>>> Sri >>>> >>>> >>>> >>>> On 7/22/14 9:56 AM, "Behcet Sarikaya" wrote: >>>> >>>>>You are talking about Gateway Initiated DS-Lite (RFC 6674). >>>>> >>>>>That is a solution based on DS-Lite, i.e. a variation of DS-Lite or >>>>>RFC 6333. >>>>> >>>>>Again, my plea to you, please come up with your draft and let WG see >>>>>what you propose. >>>>> >>>>>That is the right way to go. >>>>> >>>>>Behcet >>>> >>> >>>___ >>>dmm mailing list >>>dmm@ietf.org >>>https://www.ietf.org/mailman/listinfo/dmm >> >> >>_ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>exploites ou copies sans autorisation. Si vous avez recu ce message par >>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les >>pieces jointes. Les messages electroniques etant susceptibles >>d'alteration, Orange decline toute responsabilite si ce message a ete >>altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >>information that may be protected by law; they should not be >>distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >>delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >>been modified, changed or falsified. >> Thank you. >> >> ___ >> 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] IETF#90 DMM agenda update
I am not against any work which is based on an existing draft. I spoke against having a long presentation and there is no draft. Another point here is, yesterday I discussed with Marco on this. Any architecture and so called deployment proposal has a sense of solution in it. I don't buy the argument that the architecture is generic and that the deployment is generic. At this point in time there is no such thing. Such proposals represent the authors solution approach.They are reading other solution proposals and they don't like some aspects in those solution drafts and they want to present some alternative approaches. So, as I said before, Marco, Sri, Pierrick, if there are any others, are free to write drafts making it clear that in the draft they are talking about their own solution. There is nothing wrong with it. I hope this makes my point clear. Regards, Behcet On Wed, Jul 23, 2014 at 4:36 AM, wrote: > Thanks Pierrick for the pointer! > And FWIW also Marcos draft-liebsch-dmm-framework-03 addresses deployment and > architecture aspects for evaluating various approaches > BR > Dirk > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of pierrick.se...@orange.com > Sent: Mittwoch, 23. Juli 2014 10:13 > To: sarik...@ieee.org; Sri Gundavelli (sgundave) > Cc: dmm@ietf.org > Subject: Re: [DMM] IETF#90 DMM agenda update > > > >>-Message d'origine- >>De : dmm [mailto:dmm-boun...@ietf.org] De la part de Behcet Sarikaya >>Envoyé : mardi 22 juillet 2014 19:04 À : Sri Gundavelli (sgundave) Cc : >>dmm@ietf.org Objet : Re: [DMM] IETF#90 DMM agenda update >> >>On Tue, Jul 22, 2014 at 12:00 PM, Sri Gundavelli (sgundave) >> wrote: >>> I think you are mixing the topics here. >> >>I am not sure who? >>How can you talk about deployment without having a solution? >>Deployment where? >> >>> >>> Any case, I don't have plans to write one .. >> >>I know that and that's why I kept asking, just in case you might change >>your mind. >> >>Maybe you can write a draft evaluating existing proposals from your >>"architecture" and your "deployment" point of view. >> > > Worth to be considered IMHO: draft-liu-dmm-deployment-scenario > >>Behcet >> >>> >>> >>> Sri >>> >>> >>> >>> On 7/22/14 9:56 AM, "Behcet Sarikaya" wrote: >>> >>>>You are talking about Gateway Initiated DS-Lite (RFC 6674). >>>> >>>>That is a solution based on DS-Lite, i.e. a variation of DS-Lite or >>>>RFC 6333. >>>> >>>>Again, my plea to you, please come up with your draft and let WG see >>>>what you propose. >>>> >>>>That is the right way to go. >>>> >>>>Behcet >>> >> >>___ >>dmm mailing list >>dmm@ietf.org >>https://www.ietf.org/mailman/listinfo/dmm > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message par > erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > ___ > 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] IETF#90 DMM agenda update
Thanks Pierrick for the pointer! And FWIW also Marcos draft-liebsch-dmm-framework-03 addresses deployment and architecture aspects for evaluating various approaches BR Dirk -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of pierrick.se...@orange.com Sent: Mittwoch, 23. Juli 2014 10:13 To: sarik...@ieee.org; Sri Gundavelli (sgundave) Cc: dmm@ietf.org Subject: Re: [DMM] IETF#90 DMM agenda update >-Message d'origine- >De : dmm [mailto:dmm-boun...@ietf.org] De la part de Behcet Sarikaya >Envoyé : mardi 22 juillet 2014 19:04 À : Sri Gundavelli (sgundave) Cc : >dmm@ietf.org Objet : Re: [DMM] IETF#90 DMM agenda update > >On Tue, Jul 22, 2014 at 12:00 PM, Sri Gundavelli (sgundave) > wrote: >> I think you are mixing the topics here. > >I am not sure who? >How can you talk about deployment without having a solution? >Deployment where? > >> >> Any case, I don't have plans to write one .. > >I know that and that's why I kept asking, just in case you might change >your mind. > >Maybe you can write a draft evaluating existing proposals from your >"architecture" and your "deployment" point of view. > Worth to be considered IMHO: draft-liu-dmm-deployment-scenario >Behcet > >> >> >> Sri >> >> >> >> On 7/22/14 9:56 AM, "Behcet Sarikaya" wrote: >> >>>You are talking about Gateway Initiated DS-Lite (RFC 6674). >>> >>>That is a solution based on DS-Lite, i.e. a variation of DS-Lite or >>>RFC 6333. >>> >>>Again, my plea to you, please come up with your draft and let WG see >>>what you propose. >>> >>>That is the right way to go. >>> >>>Behcet >> > >___ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ 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] IETF#90 DMM agenda update
>-Message d'origine- >De : dmm [mailto:dmm-boun...@ietf.org] De la part de Behcet Sarikaya >Envoyé : mardi 22 juillet 2014 19:04 >À : Sri Gundavelli (sgundave) >Cc : dmm@ietf.org >Objet : Re: [DMM] IETF#90 DMM agenda update > >On Tue, Jul 22, 2014 at 12:00 PM, Sri Gundavelli (sgundave) > wrote: >> I think you are mixing the topics here. > >I am not sure who? >How can you talk about deployment without having a solution? >Deployment where? > >> >> Any case, I don't have plans to write one .. > >I know that and that's why I kept asking, just in case you might change your >mind. > >Maybe you can write a draft evaluating existing proposals from your >"architecture" and your "deployment" point of view. > Worth to be considered IMHO: draft-liu-dmm-deployment-scenario >Behcet > >> >> >> Sri >> >> >> >> On 7/22/14 9:56 AM, "Behcet Sarikaya" wrote: >> >>>You are talking about Gateway Initiated DS-Lite (RFC 6674). >>> >>>That is a solution based on DS-Lite, i.e. a variation of DS-Lite or >>>RFC 6333. >>> >>>Again, my plea to you, please come up with your draft and let WG see >>>what you propose. >>> >>>That is the right way to go. >>> >>>Behcet >> > >___ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
Exactly... this is why DMM call#5 was devoted to NG-POP... Moreover, we had a lot of discussions regarding architecture from the very beginning of DMM in order to justify the effort and I think these discussions should be captured... >-Message d'origine- >De : dmm [mailto:dmm-boun...@ietf.org] De la part de Sri Gundavelli >(sgundave) >Envoyé : mardi 22 juillet 2014 18:49 >À : sarik...@ieee.org >Cc : dmm@ietf.org >Objet : Re: [DMM] IETF#90 DMM agenda update > >Alternatively, you capture the deployment models and then identify the >solution gaps or solutions that meet the goals ... > >> Sorry, I am familiar with those areas, they are not in Intarea :-). > > >RFC-6674; A solution driven by a deployment requirement. > > >Sri > > >On 7/22/14 9:36 AM, "Behcet Sarikaya" wrote: > >>Hi Sri, >> >> >>On Tue, Jul 22, 2014 at 10:16 AM, Sri Gundavelli (sgundave) >> wrote: >>> Behcet, >>> >>> Check some of the documents in MPLS/Routing areas. >> >>Sorry, I am familiar with those areas, they are not in Intarea :-). >> >>> >>> DMM to most part is about deployment. Without bringing the deployment >>> aspects, documenting DMM solutions will be immature. >> >>I am looking at this Softwire document: >> >>http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-04 >> >>This document is looking into models on how MAP can be deployed on >>large-scale carrier networks. >> >>But the catch is that MAP which is the solution protocol is already >>defined in a different document by Softwire. >> >>So the deployment models IF NEEDED follows the solution selection process. >> >>May I suggest you to please come up with a draft including your ideas >>on the architecture and solution and have it discussed like any other >>protocol proposals? You may wish to add any deployment concerns there >>in your draft if you like. >> >>Also any architecture work will have implications on the solution and >>if they are done at the WG level that practically means that a lot of >>bias on the solutions which are already proposed will be imposed. I >>don't think that is what the WG wants to do. >> >>Regards, >> >>Behcet >> >> > >___ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
On Tue, Jul 22, 2014 at 12:00 PM, Sri Gundavelli (sgundave) wrote: > I think you are mixing the topics here. I am not sure who? How can you talk about deployment without having a solution? Deployment where? > > Any case, I don't have plans to write one .. I know that and that's why I kept asking, just in case you might change your mind. Maybe you can write a draft evaluating existing proposals from your "architecture" and your "deployment" point of view. Behcet > > > Sri > > > > On 7/22/14 9:56 AM, "Behcet Sarikaya" wrote: > >>You are talking about Gateway Initiated DS-Lite (RFC 6674). >> >>That is a solution based on DS-Lite, i.e. a variation of DS-Lite or RFC >>6333. >> >>Again, my plea to you, please come up with your draft and let WG see >>what you propose. >> >>That is the right way to go. >> >>Behcet > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
I think you are mixing the topics here. Any case, I don't have plans to write one .. Sri On 7/22/14 9:56 AM, "Behcet Sarikaya" wrote: >You are talking about Gateway Initiated DS-Lite (RFC 6674). > >That is a solution based on DS-Lite, i.e. a variation of DS-Lite or RFC >6333. > >Again, my plea to you, please come up with your draft and let WG see >what you propose. > >That is the right way to go. > >Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
You are talking about Gateway Initiated DS-Lite (RFC 6674). That is a solution based on DS-Lite, i.e. a variation of DS-Lite or RFC 6333. Again, my plea to you, please come up with your draft and let WG see what you propose. That is the right way to go. Behcet On Tue, Jul 22, 2014 at 11:48 AM, Sri Gundavelli (sgundave) wrote: > Alternatively, you capture the deployment models and then identify the > solution gaps or solutions that meet the goals ... > >> Sorry, I am familiar with those areas, they are not in Intarea :-). > > > RFC-6674; A solution driven by a deployment requirement. > > > Sri > > > On 7/22/14 9:36 AM, "Behcet Sarikaya" wrote: > >>Hi Sri, >> >> >>On Tue, Jul 22, 2014 at 10:16 AM, Sri Gundavelli (sgundave) >> wrote: >>> Behcet, >>> >>> Check some of the documents in MPLS/Routing areas. >> >>Sorry, I am familiar with those areas, they are not in Intarea :-). >> >>> >>> DMM to most part is about deployment. Without bringing the deployment >>> aspects, documenting DMM solutions will be immature. >> >>I am looking at this Softwire document: >> >>http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-04 >> >>This document is looking into models on how MAP can be deployed on >>large-scale carrier networks. >> >>But the catch is that MAP which is the solution protocol is already >>defined in a different document by Softwire. >> >>So the deployment models IF NEEDED follows the solution selection process. >> >>May I suggest you to please come up with a draft including your ideas >>on the architecture and solution and have it discussed like any other >>protocol proposals? You may wish to add any deployment concerns there >>in your draft if you like. >> >>Also any architecture work will have implications on the solution and >>if they are done at the WG level that practically means that a lot of >>bias on the solutions which are already proposed will be imposed. I >>don't think that is what the WG wants to do. >> >>Regards, >> >>Behcet >> >> > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
Alternatively, you capture the deployment models and then identify the solution gaps or solutions that meet the goals ... > Sorry, I am familiar with those areas, they are not in Intarea :-). RFC-6674; A solution driven by a deployment requirement. Sri On 7/22/14 9:36 AM, "Behcet Sarikaya" wrote: >Hi Sri, > > >On Tue, Jul 22, 2014 at 10:16 AM, Sri Gundavelli (sgundave) > wrote: >> Behcet, >> >> Check some of the documents in MPLS/Routing areas. > >Sorry, I am familiar with those areas, they are not in Intarea :-). > >> >> DMM to most part is about deployment. Without bringing the deployment >> aspects, documenting DMM solutions will be immature. > >I am looking at this Softwire document: > >http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-04 > >This document is looking into models on how MAP can be deployed on >large-scale carrier networks. > >But the catch is that MAP which is the solution protocol is already >defined in a different document by Softwire. > >So the deployment models IF NEEDED follows the solution selection process. > >May I suggest you to please come up with a draft including your ideas >on the architecture and solution and have it discussed like any other >protocol proposals? You may wish to add any deployment concerns there >in your draft if you like. > >Also any architecture work will have implications on the solution and >if they are done at the WG level that practically means that a lot of >bias on the solutions which are already proposed will be imposed. I >don't think that is what the WG wants to do. > >Regards, > >Behcet > > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
Hi Sri, On Tue, Jul 22, 2014 at 10:16 AM, Sri Gundavelli (sgundave) wrote: > Behcet, > > Check some of the documents in MPLS/Routing areas. Sorry, I am familiar with those areas, they are not in Intarea :-). > > DMM to most part is about deployment. Without bringing the deployment > aspects, documenting DMM solutions will be immature. I am looking at this Softwire document: http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-04 This document is looking into models on how MAP can be deployed on large-scale carrier networks. But the catch is that MAP which is the solution protocol is already defined in a different document by Softwire. So the deployment models IF NEEDED follows the solution selection process. May I suggest you to please come up with a draft including your ideas on the architecture and solution and have it discussed like any other protocol proposals? You may wish to add any deployment concerns there in your draft if you like. Also any architecture work will have implications on the solution and if they are done at the WG level that practically means that a lot of bias on the solutions which are already proposed will be imposed. I don't think that is what the WG wants to do. Regards, Behcet > > > Sri > > > On 7/22/14 8:08 AM, "Behcet Sarikaya" wrote: > >>Hi Brian, >> >> >>On Tue, Jul 22, 2014 at 9:58 AM, Brian Haberman >> wrote: >>> >>> >>> On 7/22/14 10:49 AM, Jouni Korhonen wrote: Folks, The agenda has been slightly updated (shuffling around the slots and arranging more time to the charter/next steps discussion). Some presenters are affected slightly (-5 minutes). see http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm Regarding the re-chartering and the next steps. We have a tight deadline to meet if we want to ship the new charter text to the next IESG telechat. Brian will reveal the gory details of the expected re-chartering process and timelines. We are also supposed to come up (again) with a rought agreement of the deployment architecture(s) that DMM "functional elements" map into. >> >>Sorry but I don't understand why we have to work on deployment >>architectures? >> >>I don't remember any such work before in IP mobility. Is there any RFC >>that can educate me on this? >> >>I understand that some architecture work is needed. As far as I know >>almost all solution drafts have an architecture. >>Wouldn't that be enough? >> >>Kind regards, >> >>Behcet >> >>>This will be discussed as a part of the re-chartering slot and recapping the discussions we had earlier. We are also supposed to come up with a rough agreement how to progress from now on. This could mean (note the conditionality here) a series of interim meetings and setting up small groups (or design teams) to work on the initial set of the solution space drafts. We need to step out of the "progress every second IETF meeting" mode ;) >>> >>> http://www.ietf.org/iesg/statement/interim-meetings.html >>> Also keep in mind that the start of the new work poses some serialization whether we want or now: first stabilize charter & reach rough consensus on the deployment models/functional elements. These can be done in parallel. Note that rough consensus does not mean a ready spec or spec at all. Second execute with the solutions space.. the deployment models work might benefit from having a slight heads up before other drafts. These can be done in parallel, though. As a reminder, the charter may change on the route before it gets approved but we can do the opportunistic thing and start working as if the charter were already "approved" when the WG ships it. - Jouni & Dapeng ___ 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 > ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
Behcet, Check some of the documents in MPLS/Routing areas. DMM to most part is about deployment. Without bringing the deployment aspects, documenting DMM solutions will be immature. Sri On 7/22/14 8:08 AM, "Behcet Sarikaya" wrote: >Hi Brian, > > >On Tue, Jul 22, 2014 at 9:58 AM, Brian Haberman > wrote: >> >> >> On 7/22/14 10:49 AM, Jouni Korhonen wrote: >>> Folks, >>> >>> The agenda has been slightly updated (shuffling around the slots and >>> arranging more time to the charter/next steps discussion). Some >>> presenters are affected slightly (-5 minutes). see >>> http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm >>> >>> Regarding the re-chartering and the next steps. We have a tight >>>deadline >>> to meet if we want to ship the new charter text to the next IESG >>> telechat. Brian will reveal the gory details of the expected >>> re-chartering process and timelines. >>> >>> We are also supposed to come up (again) with a rought agreement of the >>> deployment architecture(s) that DMM "functional elements" map into. > >Sorry but I don't understand why we have to work on deployment >architectures? > >I don't remember any such work before in IP mobility. Is there any RFC >that can educate me on this? > >I understand that some architecture work is needed. As far as I know >almost all solution drafts have an architecture. >Wouldn't that be enough? > >Kind regards, > >Behcet > >>This >>> will be discussed as a part of the re-chartering slot and recapping the >>> discussions we had earlier. >>> >>> We are also supposed to come up with a rough agreement how to progress >>> from now on. This could mean (note the conditionality here) a series of >>> interim meetings and setting up small groups (or design teams) to work >>> on the initial set of the solution space drafts. We need to step out of >>> the "progress every second IETF meeting" mode ;) >> >> http://www.ietf.org/iesg/statement/interim-meetings.html >> >>> >>> Also keep in mind that the start of the new work poses some >>> serialization whether we want or now: first stabilize charter & reach >>> rough consensus on the deployment models/functional elements. These can >>> be done in parallel. Note that rough consensus does not mean a ready >>> spec or spec at all. Second execute with the solutions space.. the >>> deployment models work might benefit from having a slight heads up >>> before other drafts. These can be done in parallel, though. As a >>> reminder, the charter may change on the route before it gets approved >>> but we can do the opportunistic thing and start working as if the >>> charter were already "approved" when the WG ships it. >>> >>> - Jouni & Dapeng >>> >>> ___ >>> 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
Hi Brian, On Tue, Jul 22, 2014 at 9:58 AM, Brian Haberman wrote: > > > On 7/22/14 10:49 AM, Jouni Korhonen wrote: >> Folks, >> >> The agenda has been slightly updated (shuffling around the slots and >> arranging more time to the charter/next steps discussion). Some >> presenters are affected slightly (-5 minutes). see >> http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm >> >> Regarding the re-chartering and the next steps. We have a tight deadline >> to meet if we want to ship the new charter text to the next IESG >> telechat. Brian will reveal the gory details of the expected >> re-chartering process and timelines. >> >> We are also supposed to come up (again) with a rought agreement of the >> deployment architecture(s) that DMM "functional elements" map into. Sorry but I don't understand why we have to work on deployment architectures? I don't remember any such work before in IP mobility. Is there any RFC that can educate me on this? I understand that some architecture work is needed. As far as I know almost all solution drafts have an architecture. Wouldn't that be enough? Kind regards, Behcet >This >> will be discussed as a part of the re-chartering slot and recapping the >> discussions we had earlier. >> >> We are also supposed to come up with a rough agreement how to progress >> from now on. This could mean (note the conditionality here) a series of >> interim meetings and setting up small groups (or design teams) to work >> on the initial set of the solution space drafts. We need to step out of >> the "progress every second IETF meeting" mode ;) > > http://www.ietf.org/iesg/statement/interim-meetings.html > >> >> Also keep in mind that the start of the new work poses some >> serialization whether we want or now: first stabilize charter & reach >> rough consensus on the deployment models/functional elements. These can >> be done in parallel. Note that rough consensus does not mean a ready >> spec or spec at all. Second execute with the solutions space.. the >> deployment models work might benefit from having a slight heads up >> before other drafts. These can be done in parallel, though. As a >> reminder, the charter may change on the route before it gets approved >> but we can do the opportunistic thing and start working as if the >> charter were already "approved" when the WG ships it. >> >> - Jouni & Dapeng >> >> ___ >> 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] IETF#90 DMM agenda update
On 7/22/14 10:49 AM, Jouni Korhonen wrote: > Folks, > > The agenda has been slightly updated (shuffling around the slots and > arranging more time to the charter/next steps discussion). Some > presenters are affected slightly (-5 minutes). see > http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm > > Regarding the re-chartering and the next steps. We have a tight deadline > to meet if we want to ship the new charter text to the next IESG > telechat. Brian will reveal the gory details of the expected > re-chartering process and timelines. > > We are also supposed to come up (again) with a rought agreement of the > deployment architecture(s) that DMM "functional elements" map into. This > will be discussed as a part of the re-chartering slot and recapping the > discussions we had earlier. > > We are also supposed to come up with a rough agreement how to progress > from now on. This could mean (note the conditionality here) a series of > interim meetings and setting up small groups (or design teams) to work > on the initial set of the solution space drafts. We need to step out of > the "progress every second IETF meeting" mode ;) http://www.ietf.org/iesg/statement/interim-meetings.html > > Also keep in mind that the start of the new work poses some > serialization whether we want or now: first stabilize charter & reach > rough consensus on the deployment models/functional elements. These can > be done in parallel. Note that rough consensus does not mean a ready > spec or spec at all. Second execute with the solutions space.. the > deployment models work might benefit from having a slight heads up > before other drafts. These can be done in parallel, though. As a > reminder, the charter may change on the route before it gets approved > but we can do the opportunistic thing and start working as if the > charter were already "approved" when the WG ships it. > > - Jouni & Dapeng > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
