Subject: [MBONED] revisit mtrace2

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 19 Oct 2012 14:04:00 +0900 (JST)

Hi,

Due to the requests to improve the document quality of the mtrace2
draft, we took long time to revise the document.
We are almost ready to publish the revised document very soon.
But before posting it, I'd like to hear your opinions about the
following technical points.

1. mtrace2 client's location
   In the initial specification (-00), mtrace2 client host can be
   located anywhere. It means an mtrace2 client can initiate mtrace2
   query to foreign routers. But due to the concern of some security
   threats (e.g. DoS attacks), we decided that mtrace2 query could
   initiate only from adjacent hosts and didn't allow from foreign
   hosts.
   This limitation reduces the flexibility of the operation since it
   is impossible to expect that operators' hosts are always adjacent
   to all of their routers. But it'd be possible to support such
   situation if a multicast router can send mtrace2 query as an
   mtrace2 client.
   There was an agreement on this decision in a previous WG's meeting,
   and hence the current draft (-08) follows this decision.
   However, there were still some opinions that many operators set up
   central management nodes and these nodes should be enabled to send
   mtrace2 query to any routers in their network (without configuring
   special VPN or something).

   What is your opinion?

2. Mtrace2 Extended Query Block
   There was a proposal to add "Mtrace2 Extended Query Block" as seen
   in;
   http://tools.ietf.org/id/draft-hou-dp-mtrace-00.txt
   This draft should be discussed in detail after this mtrace2 base
   protocol is published as RFC.
   However, one contributor for this mtrace2 document suggests that
   the base spec should be extensible by proposing the "Mtrace2
   Extended Query Block", such as;

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |           Length              |      MBZ    |T|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Extended Query Type      |           Value ....          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The detail use case and spce how this block can be used should be
   described in the above dp-mtrace document, but adding this tlv
   format as part of the base spec may be accepted.

   What is your opinion?

If there is no concern, or if there is no strong negative opinion,
I'll do the following things.

For 1, I change back the mtrace2 client location policy to the one of
the initial spec. So, the revision (-09) won't deny foreign clients.
For 2, I add the above "Mtrace2 Extended Query Block" TLV definition
with simple explanation. (The detail spec won't be appeared into this
draft.)

I appreciate your comments.

Regards,
--
Hitoshi Asaeda