<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>This is mostly directed at Josh, as he is editing the IMC orange book, but sending it to the mailing list for feedback.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The basic syntax of the IMC scheme EID is fine the way it is documented in the orange book draft today, but for operational and interoperability reasons the Group ID and Service ID components will probably need a similar treatment to the IPN scheme Service ID [1] in order to separate code point ranges for different purposes.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Specific to the IMC group ID, I think there may be some benefit to having more than just “well known” and “private use” ranges in the same sense that IPv6 architecture [2] has some defined “scopes”. This is NOT (!) a recommendation to take those names or meanings or anything like that. Just that there may be some benefit within the IMC group ID code space to separate between “well-known to the world” and “well-known within my administrative domain” and “assigned within my mission for this video stream”. The reason being that all IMC group IDs will need to be distinguished and unique across a whole big overlay network.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I had some discussion with Scott Burleigh earlier about also enabling the concept of source-specific multipoint (SSM), which would require no signaling changes but would be present in the API between BPA and application. The reason for defining an SSM semantics would be for that last range of group IDs above, where the group doesn’t want to (or need to) be globally unique just unique per-Source Node ID. This would avoid needing an explosion of unique mission-specific private-use allocations to coordinate when there are many sources wanting to use multipoint messaging concurrently but each group member cares about only one source at a time (e.g. “stream the video from this camera on this console, other camera on the other console”). SSM also simplifies signaling needed to establish group membership with CGR multipoint routing without changing its fundamental behavior. This kind of logic agrees with the operational issues identified with IP multicast in [3]; again I know that multipoint messaging is a different mechanism than IP multicast but these same logical issues of needing to avoid destination EID collisions across a network will come up here just as well.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Any thoughts are welcome,<o:p></o:p></p><p class=MsoNormal>Brian S.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>[1] <a href="https://www.ietf.org/archive/id/draft-ietf-dtn-ipn-update-10.html#section-9.3">https://www.ietf.org/archive/id/draft-ietf-dtn-ipn-update-10.html#section-9.3</a><o:p></o:p></p><p class=MsoNormal>[2] <a href="https://www.rfc-editor.org/rfc/rfc4291.html#section-2.7">https://www.rfc-editor.org/rfc/rfc4291.html#section-2.7</a><o:p></o:p></p><p class=MsoNormal>[3] <a href="https://www.ietf.org/archive/id/draft-ietf-pim-multicast-lessons-learned-03.html">https://www.ietf.org/archive/id/draft-ietf-pim-multicast-lessons-learned-03.html</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>