Re: Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02
Jouni Korhonen <[email protected]>
| Newsgroups | gmane.ietf.mip6 |
|---|---|
| Message-ID | <56609A22.7020103__45268.5592267246$1449171511$gmane$org@gmail.com> |
Behcet, 12/3/2015, 10:43 AM, Behcet Sarikaya kirjoitti: > Hi Jouni, > > On Wed, Dec 2, 2015 at 2:29 PM, Jouni Korhonen <[email protected]> wrote: >> Behcet, >> >> 12/2/2015, 11:02 AM, Behcet Sarikaya kirjoitti: >>> >>> Hi Jouni, >>> >>> >>> On Tue, Dec 1, 2015 at 6:41 PM, Jouni Korhonen <[email protected]> >>> wrote: >>>> >>>> As an individual contributor I support the adoption of this I-D. MCoA is >>>> a >>>> feature that we still lack.. >>>> >>> >>> Are you sure? >>> >>> MCoA is solved in Netext Flow Mobility draft, >>> >>> draft-ietf-netext-pmipv6-flowmob-14 >>> >>> is the latest draft. >> >> >> Sorry for my improper wording regarding which part of the MCoA I meant. I >> don't see how draft-ietf-netext-pmipv6-flowmob-14 would handle the case of >> registration when the Proxy-CoAs are from the same MAG. > > I wonder why would that be needed? > MN doesn't need it. > So this draft seems to be addressing a non-problem. I'll let the WG to determine whether the feature is needed or not. For me (as an individual contributor) the I-D gives a standard way to register multiple transport connections/tunnels between a MAG and a LMA, potentially over different technologies (wired, wireless, ..) on the transport network side without needing to rely on engineering solutions to achieve the same (yes - I could do a somewhat similar solution e.g. using MPLS but that would then be loaded with all kinds of assumptions that may or may not work in multi vendor and cross operator environment). - JOuni > > Regards, > > Behcet >> The netext draft >> specifically states Proxy-CoAs are from different MAGs. >> >> But it was a good thing you brought this up. The two I-Ds need to be in >> sync. >> >>> >>> BTW there was an issue in WG adoption call in IETF 93 in Yokohama. The >> >> >> IETF 94 I presume.. AFAIR we did not ask for adoption in IETF 93. >> >>> chair asked only those who accept. The chair unfortunately did not ask >>> those who oppose. >>> >>> As you know, if the chair wishes to ask a single question then the >>> right one is any opposes. >> >> >> Obviously you are right here but I cannot really comment on this what >> happened in Yokohama since I was not on site or not even participating >> remotely. >> >> Anyway, all adoption calls are confirmed on the mailing list and the "sense >> of the room" during the meeting merely serves as informative quidance for >> chairs. >> >> - Jouni >> >> >>> >>> Regards, >>> >>> Behcet >>>> >>>> The document itself still needs quite a bit of work. For example, I >>>> wonder >>>> if the caption for Figure 2 is correct. Also, Section 4.1. option fiels >>>> descriptions are somewhat broken it seems. And so on multiple small nits >>>> like unexpanded acronyms etc. However, these are mainly editorials. I >>>> have >>>> no problem with the technical solution. >>>> >>>> - Jouni >>>> >>>> >>>> >>>> 11/25/2015, 8:22 AM, Dapeng Liu kirjoitti: >>>>> >>>>> >>>>> Hello all, >>>>> >>>>> In IETF94, we initiated the call for adoption for the draft: >>>>> draft-seite-dmm-rg-multihoming-02 >>>>> <http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02>: >>>>> http://tools.ietf.org/html/draft-seite-dmm-rg-multihoming-02 >>>>> Seems have got sufficient support during the meeting. We'd like to >>>>> confirm the call for adoption in the mailing list for 2 weeks. >>>>> Please send your opinion and comments to the list before December 9. >>>>> >>>>> >>>>> Thanks, >>>>> ------ >>>>> Best Regards, >>>>> Dapeng&Jouni >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------ >>>>> Best Regards, >>>>> Dapeng Liu >>>>> >>>>> >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/dmm