Subject: Re: [DMM] Going forward with the DMM work items

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 1 Oct 2014 14:50:37 -0500

The point is that the way the charter is being interpreted is
we don't need solutions and we won't care if there are some,

instead we will build the solution in five-six pieces from zero in DTs.

Behcet

On Mon, Sep 29, 2014 at 11:34 AM, Templin, Fred L
<[email-masked]> wrote:
> Hi Behcet,
>
>> -----Original Message-----
>> From: Behcet Sarikaya [mailto:[email-masked]]
>> Sent: Monday, September 29, 2014 8:50 AM
>> To: Templin, Fred L
>> Cc: Brian Haberman; [email-masked]
>> Subject: Re: [DMM] Going forward with the DMM work items
>>
>> Hi Fred,
>>
>>
>> On Fri, Sep 26, 2014 at 2:34 PM, Templin, Fred L
>> <[email-masked]> wrote:
>> > Hi Behcet,
>> >
>> >> -----Original Message-----
>> >> From: dmm [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
>> >> Sent: Friday, September 26, 2014 12:22 PM
>> >> To: Brian Haberman
>> >> Cc: [email-masked]
>> >> Subject: Re: [DMM] Going forward with the DMM work items
>> >>
>> >> Hi Brian,
>> >>
>> >> You deleted maybe by mistake the first three paragraphs of my previous mail.
>> >>
>> >> Let me add to those one more point:
>> >>
>> >> Previously mobility groups in IETF produced single protocols like
>> >> Mobile IP or Proxy Mobile IP.
>> >> These protocols have seen some operator adoption, of course not much but some.
>> >> This time we will be asking the operators to adopt exposing mobility
>> >> state protocol, enhanced mobility anchoring protocol and forwarding
>> >> path and signaling protocol (maybe forwarding path protocol and
>> >> signaling protocol)l.
>> >> And maybe deployment models protocol which was in the charter but
>> >> somehow got dropped.
>> >> How is that going to happen?
>>
>> Do you plan to divide your solution into
>>
>> exposing mobility state protocol,
>> enhanced mobility anchoring protocol.
>>  forwarding path protocol
>> signaling protocol ?
>>
>> That is the way things are going.
>
> All of these things I think have areas of overlap with aspects
> of the AERO proposal.
>
>> Otherwise you are off track.
>
> I think the best I can do is represent the AERO proposal and speak
> to the areas where there is overlap. I think we have already
> established that AERO solves the tunnel MTU problem and that has
> applicability outside of just AERO. I am also feeding some of my
> correspondent capability discovery ideas to Alper and that again
> has wider applicability. The AERO NBMA model is being discussed
> in relation to the MIP/PMIP point-to-point model. Signaling based
> on plain old DHCPv6 and IPv6ND instead of specialized Mobility
> Headers has also been discussed.
>
> So, maybe I'm not seeing the forest for the trees but if you
> think I am off track what am I supposed to do about it? Complain,
> or continue to conduct a productive investigation as I am already
> doing?
>
>> >> Anyway these are my concerns, I could not attend Interim call #2, I
>> >> believe many people could not including Jouni.
>> >
>> > Jouni was able to attend the call. I was on the call and asked the
>> > question as to whether non-MIPv6/PMIPv6 solutions could be considered
>> > and the answer I got (I think from Jouni) was "possibly".
>> >
>> >> People should speak up, otherwise it appears like it is only my issue.
>> >
>> > AERO is a solution alternative that I would like to see taken under
>> > wider consideration within this domain. I think that is starting to
>> > happen through some of the recent list discussions, so others on the
>> > list should now be coming aware of it. I also plan to attend IETF91
>> > where I would ask for another AERO presentation timeslot if it would
>> > please the wg and the chairs.
>> >
>> > So, it seems to me that I am already doing all I can. Do you think
>> > I should be doing more?
>>
>> I think you are trying to push your own solution
>
> I am conducting an investigation. Others have joined me in a friendly
> exchange of ideas. Is it the wrong approach?
>
>> and you think that you are effective in it.
>
> Which means that you think I am not effective in it?
>
>> I think DMM should see the big picture and everybody, including Ryuji,
>> Satoru and others should speak up.
>
> Sure, it would be good to hear from them. I have already specified
> a BGP-based distributed mobility management scheme in both the AERO
> spec and earlier in RFC6179. (I have read their draft; I have no way
> of knowing whether they have read my documents.)
>
> Thanks - Fred
> [email-masked]
>
>> Regards,
>>
>> Behcet
>>
>> >
>> > Thanks - Fred
>> > [email-masked]
>> >
>> >> Regards,
>> >>
>> >> Behcet
>> >>
>> >> On Fri, Sep 26, 2014 at 11:22 AM, Brian Haberman
>> >> <[email-masked]> wrote:
>> >> >
>> >> >
>> >> > On 9/26/14 11:14 AM, Behcet Sarikaya wrote:
>> >> >
>> >> >>
>> >> >> My question is we do that three four solution drafts and some of them
>> >> >> implemented.
>> >> >> What do we do with them?
>> >> >
>> >> > My expectation, as AD, is that the WG will assess the drafts presented
>> >> > by these teams for adoption.  People's opinion of those drafts should
>> >> > not be influenced by the fact they were written by a team.
>> >> >
>> >> >>
>> >> >> My advice to those colleagues wishing to lead the design teams is to
>> >> >> please come up with your own solution and get into the race with
>> >> >> others.
>> >> >
>> >> > Race?
>> >> >
>> >> >> How come they can get the hat of DT lead and produce something and get
>> >> >> priority over others who worked so hard?
>> >> >
>> >> > First of all, the chairs are well within their right to appoint DT
>> >> > leads.  They could have appointed all the other slots on the DT as well,
>> >> > but chose to ask for volunteers.
>> >> >
>> >> > I do not see anything in Jouni's note that indicates that a team's
>> >> > output gets any preferential treatment.  The rules of the IETF prevent that.
>> >> >
>> >> > To re-enforce Jouni's last sentence...
>> >> >
>> >> >>> These documents will be equivalent to any individual produced I-D, though.
>> >> >
>> >> > Regards,
>> >> > Brian
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > dmm mailing list
>> >> > [email-masked]
>> >> > https://www.ietf.org/mailman/listinfo/dmm
>> >> >
>> >>
>> >> _______________________________________________
>> >> dmm mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/dmm

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Oct 2014 20:59:20 +0000

Hi Behcet,

> Sent: Wednesday, October 01, 2014 12:51 PM
> To: Templin, Fred L
> Cc: [email-masked]

Yeah, I guess that would be a shame. If people took the time to truly understand
the AERO virtual link model and its applicability to Internet mobility  I don't think
there would be a rush to go off and do things in pieces.

But, I am socializing ideas and at least some people seem to be actively engaging
with me.  So, I'm not sure where complaining would help further the process.

Thanks - Fred

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 1 Oct 2014 17:17:51 -0500

> with me.  So, I'm not sure where complaining would help further the process.

Again I think you are not getting the point.

I am not sure if there is consensus on this interpretation?

I also have concerns on the division of mobile state, anchoring, etc.
in the charter.

I think that reflects the thinking from the solution drafts we had in 2012.
Now we are in 2014 and most of those solution drafts (including the
one I had) are no longer being pursued and the thinking has
considerably changed.
There are solutions that are completely network based and require no
mobility state tracking at the UE.
Also in anchoring things have changed.

So these are my concerns.

Behcet

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 3 Oct 2014 20:12:24 +0000

Hi Behcet,

> Sent: Wednesday, October 01, 2014 3:18 PM
> To: Templin, Fred L
> Cc: [email-masked]

OK, I guess the IESG is dwelling on this now as well.

> Also in anchoring things have changed.

You seem to like solutions, so why not have a look at AERO and see if you
can get behind it? AFAICT, it is now truly a comprehensive mobility solution
but if I am missing something please let me know.

Thanks - Fred

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 6 Oct 2014 13:19:53 +0900

Behcet, and all,

Maybe I can't attend next webex meeting tomorrow. So let me try to make
clear what I am thinking. Please correct me if I'm wrong to understand the
notion of the next DMM charter.

1. Forwarding path and signaling
 In fact, my proposal, stateless-uplan for vEPC (aka vEPC), to dmm is that
wherever mobility management located, existing user-plane control protocol
works fine for forwarding path management with some already proposed
extensions. The important thing is, BGP itself is not mobility management
protocol in the vEPC. The reason for this is because it enables stable
operation, maintained continuously for many advanced use cases, and most
scalable since it supports global Internet routing. But I think that BGP
does not suitable for mobility management. I understand that other people
may have their own choice, of course.

2. Enhanced mobility anchoring
 As you may know the vEPC has anycast discovery for EPC-E. It is not a
discovery mechanism actually. As the anycast address is assumed to be
informed from control-plane, which address should be chosen is a matter of
anchor selection policy or algorithm in the mobility management. So I know
that more intelligent anchor selection in the mobility management should be
considered to optimize the path. Anycast would be an operational choice
whether the informed address is assigned to single or multiple routers.

3. Mobility state exposure
Some people asked me to what entity discloses mobility info mapped into
routes. Yes, vEPC need that entity to achieve the architecture model. Now
that the draft has stated that it is a further study item. We have to study
common way to disclose mobility information regardless the type of mobility
management, which are MIP/PMIP or GTP-C whatever. It may need mobility
state exposure for not only mobile node, but also network node that the
charter has already mentioned.

I support these work items to moving forward. I've found some solutions in
the forwarding path and signaling. But AFAIK, couldn't see the solutions to
apply other two items, but it might be already there. I would like to see
solutions which are clarified into three work items and fill them. I would
be happy to contribute to make things progress.

Cheers,
--satoru

On Sat, Sep 27, 2014 at 12:14 AM, Behcet Sarikaya <[email-masked]>
wrote:

> Hi Jouni,
>
> I don't see anything in the charter regarding the design teams or
> "working teams". I also mentioned this in the list and there was no
> objection.
>
> On what basis you are forming the working teams?
>
> We currently have many solution drafts and I can not see any of them
> dividing the solution as exposing mobility state, enhanced mobility
> anchoring or forwarding path and signaling.
>
> These three items were mentioned by certain people which I believe do
> not constitute the consensus in DMM. Yes the charter had those but my
> interpretation was it was for the purpose of abstracting the solution
> into some pieces. I have never interpreted them to be the requirements
> to divide the final DMM protocol like this.
>
> On Fri, Sep 26, 2014 at 12:51 AM, Jouni Korhonen <[email-masked]>
> wrote:
> > Folks,
> >
> > In the interim call #2 we agreed to form "working teams". We got three
> > volunteers to run up those:
> >
> > o Alper will take care of coordinating "exposing mobility state.."
> > o Anthony will take care of coordinating "enhanced mobility anchoring.."
> > o Marco will take care of coordinating "forwarding path and signaling.."
> >
> > The above gentlement will arrange calls for brainstorming that are open
> for
> > everyone to participate. The process is open - about equivalent to a
> design
> > team, you just don't need to signup for one. Just keep in mind that it is
> > good to concentrate on a limited amount of work items.
> >
> > The working teams, if they so manage, will produce the solution I-D(s).
> > - Jouni & Dapeng

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 6 Oct 2014 15:50:40 +0000

Hi,

> Maybe I can't attend next webex meeting tomorrow.

That is too bad, because I will be briefing the AERO BGP routing system at the meeting tomorrow.

> So let me try to make clear what I am thinking. Please correct me if I'm wrong to understand the notion
> of the next DMM charter.

>  In fact, my proposal, stateless-uplan for vEPC (aka vEPC), to dmm is that wherever mobility management
>  located, existing user-plane control protocol works fine for forwarding path > management with some
> already proposed extensions. The important thing is, BGP itself is not mobility management protocol in
> the vEPC. The reason for this is because it enables stable operation, maintained continuously for many
> advanced use cases, and most scalable since it supports global Internet routing. But I think that BGP does
> not suitable for mobility management. I understand that other people may have their own choice, of course.

I read your proposal, but have not received any indication if you have read my AERO proposal yet. AERO uses
BGP in a way that was first specified by RFC6179 in 2011 and carried forward into draft-templin-ironbis and
draft-templin-aerolink. In AERO, BGP allows AERO Relays to  keep track of which AERO Client Prefixes (ACPs)
are associated with which AERO servers. But, only the Servers are exposed to localized ACP mobility events;
the BGP is only updated when an ACP moves to a new Server. This means that there will be very little churn
in the BGP routing system itself. So, the BGP is not directly exposed to localized mobility events.

> As you may know the vEPC has anycast discovery for EPC-E. It is not a discovery mechanism actually. As the
> anycast address is assumed to be informed from control-plane, which address should be chosen is a matter
> of anchor selection policy or algorithm in the mobility management. So I know that more intelligent anchor
> selection in the mobility management should be considered to optimize the path. Anycast would be an
> operational choice whether the informed address is assigned to single or multiple routers.

Anycast has been widely used in other router discovery solutions. Two cases are 6rd [RFC5969]
and 6to4 [RFC3068]. But, anycast has known operational problems in real networks, and in fact
has caused major headaches for 6to4 - even to the point that its deprecation is currently being
called for:

http://www.ietf.org/mail-archive/web/ipv6/current/msg21248.html
http://www.ietf.org/mail-archive/web/ipv6/current/msg21268.html

AERO Clients use DNS discovery to discover the address(es) of nearby Server(s) as the default 
means. Other solutions such as manual configuration, DHCP option, etc. are also possible. 

> Some people asked me to what entity discloses mobility info mapped into routes. Yes, vEPC need
> that entity to achieve the architecture model. Now that the draft has stated that it is a further study
> item. We have to study common way to disclose mobility information regardless the type of mobility
> management, which are MIP/PMIP or GTP-C whatever. It may need mobility state exposure for not
> only mobile node, but also network node that the charter has already mentioned.

It would be nice if you were to review the AERO architecture and explain to me the way in which
this requirement is or is not addressed already there. 

Thanks - Fred

From: dmm [mailto:[email-masked]] On Behalf Of Satoru Matsushima
Sent: Sunday, October 05, 2014 9:20 PM
To: [email-masked]
Cc: Dapeng Liu; [email-masked]
Subject: Re: [DMM] Going forward with the DMM work items

Behcet, and all,

Maybe I can't attend next webex meeting tomorrow. So let me try to make clear what I am thinking. Please correct me if I'm wrong to understand the notion of the next DMM charter.

1. Forwarding path and signaling
 In fact, my proposal, stateless-uplan for vEPC (aka vEPC), to dmm is that wherever mobility management located, existing user-plane control protocol works fine for forwarding path management with some already proposed extensions. The important thing is, BGP itself is not mobility management protocol in the vEPC. The reason for this is because it enables stable operation, maintained continuously for many advanced use cases, and most scalable since it supports global Internet routing. But I think that BGP does not suitable for mobility management. I understand that other people may have their own choice, of course. 

2. Enhanced mobility anchoring
 As you may know the vEPC has anycast discovery for EPC-E. It is not a discovery mechanism actually. As the anycast address is assumed to be informed from control-plane, which address should be chosen is a matter of anchor selection policy or algorithm in the mobility management. So I know that more intelligent anchor selection in the mobility management should be considered to optimize the path. Anycast would be an operational choice whether the informed address is assigned to single or multiple routers.

3. Mobility state exposure
Some people asked me to what entity discloses mobility info mapped into routes. Yes, vEPC need that entity to achieve the architecture model. Now that the draft has stated that it is a further study item. We have to study common way to disclose mobility information regardless the type of mobility management, which are MIP/PMIP or GTP-C whatever. It may need mobility state exposure for not only mobile node, but also network node that the charter has already mentioned.

I support these work items to moving forward. I've found some solutions in the forwarding path and signaling. But AFAIK, couldn't see the solutions to apply other two items, but it might be already there. I would like to see solutions which are clarified into three work items and fill them. I would be happy to contribute to make things progress.

Cheers,
--satoru

On Sat, Sep 27, 2014 at 12:14 AM, Behcet Sarikaya <[email-masked]> wrote:
Hi Jouni,

Regards,

Behcet

On Fri, Sep 26, 2014 at 12:51 AM, Jouni Korhonen <[email-masked]> wrote:
> The above gentlement will arrange calls for brainstorming that are open for
> everyone to participate. The process is open - about equivalent to a design

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 6 Oct 2014 15:33:38 -0500

Hi Satoru,

> may have their own choice, of course.

I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi
we proposed new approaches like SDN.

Having said that I don't think that the charter text on forwarding
path and signaling is talking about the same thing.

> whether the informed address is assigned to single or multiple routers.

In DMM fir WiFi we also adopted the anycast discovery, what is wrong with that?

Yes I agree, maybe other techniques like AAA can be worked out. Why
not do it as extensions?

> management, which are MIP/PMIP or GTP-C whatever. It may need mobility state
> exposure for not only mobile node, but also network node that the charter
> has already mentioned.

Really? My thinking was that vEPC does not need any involvement from
MN because the prefix assigned to MN does not change.

As I mentioned in my more recent mail, I think this item is based on
2102 solution proposals in which MN had to deal with many prefixes.

Can you clarify which network nodes need exposure to MN mobility
state? The ones on the path already know MN prefix, right?

> be happy to contribute to make things progress.
So you are saying that these three items gave you some good ideas to
think about on how you can improve your solution, vEPC.

You are indicating that there is a major solution proposal, i.e. vEPC
by you, but that can be improved here and there.

You are missing the point that such a view point is not yet agreed by the group.

Without such an agreement on the base, isn't it quite concerning what
the WT's or DT's will do?

My understanding is that the formation of WT's or DT's is another way
of saying that we don't like all those solutions out there, we will
design our own solutions to the above 3.

Regards,

Behcet

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 7 Oct 2014 16:31:11 +0900

Hi Behcet,

> we proposed new approaches like SDN.
Please don't get me wrong. My position hasn't been changed. BGP is used to
forwarding path management signaling.

In your draft, XMPP is the protocol that has same role of BGP. Good idea,
it is a pub-sub system as same as BGP. You may need to define data model
for dmm in i2rs, yang? I don't know which protocol will be adopted as i2rs
either xmpp, netconf, or forces.

I suppose that you might want to adopt end-system VPN (
https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its xml data
modeling. (actually it is BGP. :-) And, as you may know that there is a
draft which mentions about use case of BGP in i2rs. (
http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases)

> path and signaling is talking about the same thing.
Interesting. What do you expect for the charter text?
Why not you ask Marco, Anthony and Alper to explain their thought?

> In DMM fir WiFi we also adopted the anycast discovery, what is wrong with

How do you find the anycast address itself?

> Yes I agree, maybe other techniques like AAA can be worked out. Why
I suppose that it would be a part of enhanced anchoring work, isn't it?

> state? The ones on the path already know MN prefix, right?
Quite not. I meant disclosing mobility information to network node that
likes such as BGP speaker.

> think about on how you can improve your solution, vEPC.
In my view, the charter items work well to achieve vEPC architecture model,
yes.
More precisely, as the result of discussions which I had so far with many
dmm people, I have noticed some parts which the draft needs more work to
achieve the architecture model.

> You are missing the point that such a view point is not yet agreed by the

I know. So I am trying to express my thought, and then we can recognize
differences each other, and we can discuss. It's normal process in the ietf
I think.

> design our own solutions to the above 3.

I guess wg management, who are responsible to establish dmm standard,
expect standardizing dmm solution would be very hard work because they find
many variants for it. In that situation, it would be reasonable that they
appoint some persons to lead the work. I really appreciate those persons
who volunteer to take that role to out consolidated solution.

Cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 7 Oct 2014 18:33:57 +0900

Hi Fred,

> That is too bad, because I will be briefing the AERO BGP routing system at
Yes, sorry to say.

> localized mobility events.
I know you are the guy who invent ISATAP so I understand you may utilize
same mechanism. You and me look big-believer of BGP ecosystem. In my draft,
3gpp defined mobility management is assumed to exist so the mobility
management exports BGP mobility information into routing information. Do
you assume 3gpp or ietf mobility management protocol/system in your draft
as well?

 Anycast has been widely used in other router discovery solutions. Two
cases are 6rd [RFC5969]

> means. Other solutions such as manual configuration, DHCP option, etc. are

Yes, I know, there are many type of endpoint discovery. Do you clear any
patent which claim the right of dns based endpoint discovery?

> this requirement is or is not addressed already there.

Well, will do. I suppose today you provides explanation to extract aero
into three work items. Thats works a lot for me to help reviewing the aero.

Cheers,
--satoru

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 7 Oct 2014 16:22:39 +0000

Hi Satoru,

>> That is too bad, because I will be briefing the AERO BGP routing system at the meeting tomorrow.

OK. The talk generated quite a few questions, and was followed by a demo of emulated
network nodes running BGP and adding/withdrawing routes in response to emulated
Client/Server associations.

> I know you are the guy who invent ISATAP

That was a long time ago. :^}

> so I understand you may utilize same mechanism.

Not exactly the same mechanism, but yes the same NBMA tunnel virtual link model.
Once the virtual link is established, ordinary link-local services like DHCPv6 and IPv6
Neighbor Discovery (ND) can be used to manage Client/Server associations and Client
mobility events. There is no need for any other control message signaling protocols.

> You and me
> look big-believer of BGP ecosystem. In my draft, 3gpp defined mobility management is assumed to exist so
> the mobility management exports BGP mobility information into routing information. Do you assume 3gpp
> or ietf mobility management protocol/system in your draft as well?

My draft presents a method for managing Client mobility based on DHCPv6 and
IPv6 ND messaging in the same way that these functions would work on ordinary
links. But Client mobility does not get propagated up to the Server/Relay BGP
routing system unless the Client changes over to a new Server (which should
happen only very infrequently). That said, the AERO BGP routing system can
be used independently of the underlying Client mobility signaling - it is only
concerned with announcing and withdrawing routes via BGP updates. 

> Yes, I know, there are many type of endpoint discovery. Do you clear any patent which claim
> the right of dns based endpoint discovery?

There are no patents that I am aware of. The AERO DNS discovery exactly parallels the
discovery method used for ISATAP as found in widely deployed implementations.

> Well, will do. I suppose today you provides explanation to extract aero into three work items.
> Thats works a lot for me to help reviewing the aero.

I still don't feel like I fully understand the three work items, but it was said in the call
(maybe by Alper?) that the enhanced anchoring team would be a place to discuss. I
think we would find that AERO could also be discussed within the context of the
other two teams as well.

I think from my talk today people came away with a better understanding of the
overall AERO architecture even though the talk and demo focused specifically on
the BGP routing system. There was interest in having a more thorough discussion
on the list, and I will start a new thread on that soon.

Thanks - Fred

---

From: Satoru Matsushima [mailto:[email-masked]] 
Sent: Tuesday, October 07, 2014 2:34 AM
To: Templin, Fred L
Cc: [email-masked]; Dapeng Liu; [email-masked]
Subject: Re: [DMM] Going forward with the DMM work items

Hi Fred,

On Tue, Oct 7, 2014 at 12:50 AM, Templin, Fred L <[email-masked]> wrote:
Hi,

Yes, sorry to say.

I know you are the guy who invent ISATAP so I understand you may utilize same mechanism. You and me look big-believer of BGP ecosystem. In my draft, 3gpp defined mobility management is assumed to exist so the mobility management exports BGP mobility information into routing information. Do you assume 3gpp or ietf mobility management protocol/system in your draft as well?

Yes, I know, there are many type of endpoint discovery. Do you clear any patent which claim the right of dns based endpoint discovery?

Well, will do. I suppose today you provides explanation to extract aero into three work items. Thats works a lot for me to help reviewing the aero.

Cheers,
--satoru

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 7 Oct 2014 16:23:10 -0500

Hi Satoru,

Thank you for your comments on my draft, we will consider them in
revising it next time.

Let me say that I lived in Japan more than 7 years and I can probably
state that I am a bit familiar with the culture.
So my translation of your views is that these things happen in IETF
and we should live with them.

Yes, I agree that it happens but in IETF there is also freedom of
expression. We can and we should point the discrepancies and there is
nothing wrong to say that this (whatever it is) is wrong, people will
respect you more if you do that.

 Regards,

Behcet

On Tue, Oct 7, 2014 at 2:31 AM, Satoru Matsushima
<[email-masked]> wrote:
> In your draft, XMPP is the protocol that has same role of BGP. Good idea, it
> is a pub-sub system as same as BGP. You may need to define data model for
> dmm in i2rs, yang? I don't know which protocol will be adopted as i2rs
> I suppose that you might want to adopt end-system VPN
> (https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its xml data
> draft which mentions about use case of BGP in i2rs.
> (http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases)
>
>>
> I guess wg management, who are responsible to establish dmm standard, expect
> standardizing dmm solution would be very hard work because they find many
> variants for it. In that situation, it would be reasonable that they appoint
> some persons to lead the work. I really appreciate those persons who
> volunteer to take that role to out consolidated solution.
>
> Cheers,
> --satoru