From esko.dijk@philips.com Tue Dec 4 06:32:47 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801C521F8AD0 for ; Tue, 4 Dec 2012 06:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekXMsIqshOw7 for ; Tue, 4 Dec 2012 06:32:46 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 61B4F21F89DD for ; Tue, 4 Dec 2012 06:32:46 -0800 (PST) Received: from mail149-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Dec 2012 14:32:45 +0000 Received: from mail149-ch1 (localhost [127.0.0.1]) by mail149-ch1-R.bigfish.com (Postfix) with ESMTP id 5AE0A38014C; Tue, 4 Dec 2012 14:32:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zz217bI15d6O9251J542Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received: from mail149-ch1 (localhost.localdomain [127.0.0.1]) by mail149-ch1 (MessageSwitch) id 1354631563373705_3241; Tue, 4 Dec 2012 14:32:43 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail149-ch1.bigfish.com (Postfix) with ESMTP id 4F0F720071; Tue, 4 Dec 2012 14:32:43 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Dec 2012 14:32:40 +0000 Received: from 011-DB3MMR1-019.MGDPHG.emi.philips.com (10.128.28.106) by 011-DB3MMR1-011.MGDPHG.emi.philips.com (10.128.28.50) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 4 Dec 2012 14:32:38 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.225]) by 011-DB3MMR1-019.MGDPHG.emi.philips.com ([10.128.28.106]) with mapi id 14.02.0318.003; Tue, 4 Dec 2012 14:32:38 +0000 From: "Dijk, Esko" To: Michael Richardson , "roll@ietf.org" Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain Thread-Index: AQHNwkOFtl9ztYUSrkiATuslfJmcUZfpG0MQgAVVjYCAAmIfMIAAeegAgAADkUCAAbgKAIAVyJ4Q Date: Tue, 4 Dec 2012 14:32:37 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B3646A@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <50932647.3050509@exegin.com> <5094202F.4010805@exegin.com> <509C03C2.50809@exegin.com> <509C5F00.2050204@exegin.com> <109e9168af966b0ee543f13886fef7ef@xs4all.nl> <8796.1352758060@sandelman.ca> <895d55da5f389dc29760cd52aaf91d61@xs4all.nl> <031DD135F9160444ABBE3B0C36CED618B0C67D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <6733.1353180917@obiwan.sandelman.ca> <031DD135F9160444ABBE3B0C36CED618B1D844@011-DB3MPN2-083.MGDPHG.emi.philips.com> <21170.1353338118@obiwan.sandelman.ca> <031DD135F9160444ABBE3B0C36CED618B20638@011-DB3MPN2-083.MGDPHG.emi.philips.com> <22106.1353433382@obiwan.sandelman.ca> In-Reply-To: <22106.1353433382@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.140.132.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 14:32:47 -0000 Just to check our current understanding of scope: > How does a node determine what the scope of the MPL domain? >From the I-D -02, it is "multicast scope of the IPv6 Destination Address of= an MPL multicast packet". So it can be derived from the mcast address(es) = that MPL uses which are defined in application code or in a config file or = so. > Is this an intrinsic (provisioned) property of a node? - if encapsulation is used, I expect the outer IP address is configured in = the node (e.g. FF05::MPL) - if encapsulation is not used, the IP address where to send to or to recei= ve on would be set by the application code i.e. it's also configured on the= node (e.g. FF05::1234) >From the IP address(es) the MPL scope follows. Esko -----Original Message----- From: mcr@obiwan.sandelman.ca [mailto:mcr@obiwan.sandelman.ca] On Behalf Of= Michael Richardson Sent: Tuesday 20 November 2012 18:43 To: roll@ietf.org Cc: consultancy@vanderstok.org; Dijk, Esko Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of M= PL domain okay, so we have the example of 6 offices with a single 6LBR. They form a single PAN (PAN-ID is irrelevant). There is a need to multicas= t within each of the offices. How does a node determine what the scope of the MPL domain? Is this an intrinsic (provisioned) property of a node? Do we support non-convex MPL domains? -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From robert.cragie@gridmerge.com Tue Dec 4 06:39:44 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F19F21F8AF4 for ; Tue, 4 Dec 2012 06:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58svtSLimk3y for ; Tue, 4 Dec 2012 06:39:43 -0800 (PST) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1BB21F8AF1 for ; Tue, 4 Dec 2012 06:39:43 -0800 (PST) Received: from client-82-26-204-201.pete.adsl.virginmedia.com ([82.26.204.201] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1Tftes-00074I-Hf; Tue, 04 Dec 2012 14:39:38 +0000 Message-ID: <50BE0B9B.7050802@gridmerge.com> Date: Tue, 04 Dec 2012 14:41:31 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Richardson References: <50AD18CC.90907@gridmerge.com> <50AD7947.8050303@exegin.com> <50ADF8F6.5000405@gridmerge.com> <18725.1354304978@obiwan.sandelman.ca> In-Reply-To: <18725.1354304978@obiwan.sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060500010001010104000503" X-Authenticated-As: robert.cragie@gridmerge.com Cc: Roll WG , "Jonathan Hui \(johui\)" Subject: Re: [Roll] 'S' field in MPL Options X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 14:39:44 -0000 This is a cryptographically signed message in MIME format. --------------ms060500010001010104000503 Content-Type: multipart/alternative; boundary="------------080107030802080207020000" This is a multi-part message in MIME format. --------------080107030802080207020000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I agree we should keep the 'S' field as it gives more flexibility for=20 future versions. I'm not sure we reached a conclusion regarding the reserved bits and=20 version numbering. Here are the choices as I see them: 1) 5-bit version number: * Allocate all reserved bits to be a unsigned 5-bit version field: o V =3D Version. Set to 0. Must be received as 0. If received as 1 or higher, packet is discarded In future revisions, this allows: * Extension of the frame using TLV suboptions * Complete change to the option formatting if V is set to 1 or higher 2) n-bit (1 <=3D n <=3D 4) version number: * Allocate n reserved bits to be a unsigned n-bit version number: o V =3D Version. Set to 0. Must be received as 0. If received as 1 or higher, packet is discarded * Change behavior for remainder of reserved bits: o rsv =3D reserved. Set to 0. Ignored on receipt In future revisions, this allows: * Extension of the frame using TLV suboptions * Use of remainder of reserved bits * Complete change to the option formatting if V is set to 1 or higher 3) No version number: * Change behavior for reserved bits: o rsv =3D reserved. Set to 0. Ignored on receipt In future revisions, this allows: * Extension of the frame using TLV suboptions * Use of reserved bits In draft 02, it is most like (1), except the reserved bits are not=20 called a version number. My preference would be for (2), with n=3D1. Anyone else? Robert On 30/11/2012 7:49 PM, Michael Richardson wrote: >>>>>> "Robert" =3D=3D Robert Cragie writes= : > Robert> 2. Allow future revisions to change the format > > I suggest that we keep the S bit. We might introduce additional fixed > format items using additional reserved bits to flag that they are there= =2E > > If we run out of reserved bits, then that would be a reason to bump the= > version and go for a full subTLV format. Given that bytes are scarce, > this results in the most efficient packing for now. > > This is my suggestion. If you agree, then we should add this to issue = #108. > --------------080107030802080207020000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree we should keep the 'S' field as it gives more flexibility for future versions.

I'm not sure we reached a conclusion regarding the reserved bits and version numbering. Here are the choices as I see them:

1) 5-bit version number:
  • Allocate all reserved bits to be a unsigned 5-bit version field:
    • V =3D Version. Set to 0. Must be received as 0. If received a= s 1 or higher, packet is discarded
In future revisions, this allows:
  • Extension of the frame using TLV suboptions
  • Complete change to the option formatting if V is set to 1 or higher
2) n-bit (1 <=3D n <=3D 4) version number:
  • Allocate n reserved bits to be a unsigned n-bit version number:
    • V =3D Version. Set to 0. Must be received as 0. If received a= s 1 or higher, packet is discarded
  • Change behavior for remainder of reserved bits:
    • rsv =3D  reserved. Set to 0. Ignored on receipt
In future revisions, this allows:
  • Extension of the frame using TLV suboptions
  • Use of remainder of reserved bits
  • Complete change to the option formatting if V is set to 1 or higher
3) No version number:
  • Change behavior for reserved bits:
    • rsv =3D  reserved. Set to 0. Ignored on receipt
In future revisions, this allows:
  • Extension of the frame using TLV suboptions
  • Use of reserved bits
In draft 02, it is most like (1), except the reserved bits are not called a version number. My preference would be for (2), with n=3D1.<= br>
Anyone else?

Robert


On 30/11/2012 7:49 PM, Michael Richardson wrote:

      

        

          

            

              

                
"Robert" =3D=3D Robert Cragie <ro=
bert.cragie@gridmerge.com> writes:


              

            

          

        

      

      
    Robert> 2. Allow future revisions to change t=
he format

I suggest that we keep the S bit.  We might introduce additional fixed
format items using additional reserved bits to flag that they are there.

If we run out of reserved bits, then that would be a reason to bump the
version and go for a full subTLV format.  Given that bytes are scarce,
this results in the most efficient packing for now.

This is my suggestion.  If you agree, then we should add this to issue #1=
08.



    

    

  


--------------080107030802080207020000--

--------------ms060500010001010104000503
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5
MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG
NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS
BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw
FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l
cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp
bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp
ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe
WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+
J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs
R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx
8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU
ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j
BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx
vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME
BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v
Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt
YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j
cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty
b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav
kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9
8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy
MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG
1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/
8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ
BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMjEyMDQxNDQxMzFaMCMGCSqGSIb3DQEJBDEWBBTo3/nFkRi2hi2VdXSANLaBs6nbwTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p
dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m
MA0GCSqGSIb3DQEBAQUABIIBAHradvktyimPUVRqSVgqhYgrTQTvuH0j7j9mV+NlIJu/b0Tw
cpOM1LHkleHdkRldJnYr0DAV5lppxS7z8syqJfTNFaOG/LCL5cIrfI24tHwGmQKrbCznWxvy
abplwpHm8zPmZIC9c9Ge9APXBjL1nBUrauVpoVEk84iu4PZB8nQ6It/j8iNUZN6MutP/33BX
lYycu59ZOyANAQpvBo1cxky/3hYJ8r1U9N7OA8Ml8q79WhcfnVjss/WRoY2dAuwyDKTIt+AN
FQzAH7P09jHyBp6f/9Lt9Ho5P3Pa/LSudZHW0DoMHQ0qiWDrB/bxufN6H5y2vRR5N5o9JzOu
aInpJ0kAAAAAAAA=
--------------ms060500010001010104000503--

From adrian@olddog.co.uk  Wed Dec  5 06:21:19 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5361521F85C7 for ; Wed,  5 Dec 2012 06:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level: 
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x00Mtu1jylVM for ; Wed,  5 Dec 2012 06:21:18 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id E3D5221F8509 for ; Wed,  5 Dec 2012 06:21:17 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB5ELGpZ015694;  Wed, 5 Dec 2012 14:21:16 GMT
Received: from 950129200 (ixe-nat1.juniper.net [193.110.54.36]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB5ELFYU015680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Dec 2012 14:21:15 GMT
From: "Adrian Farrel" 
To: 
Date: Wed, 5 Dec 2012 14:21:12 -0000
Message-ID: <00e801cdd2f3$c7f96a70$57ec3f50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac3S87vxaEIaIZwkQPqDO1PSd9m7pg==
Content-Language: en-gb
Cc: roll@ietf.org
Subject: [Roll] AD review of draft-ietf-roll-p2p-rpl-14.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 14:21:19 -0000

Hi,

I have done my usual AD review of your document as part of processing
the publication request. This review should be considered alongside 
my review of draft-ietf-roll-p2p-measurement as the documents are 
closely linked.

I have a number of questions and minor issues that I would like to
resolve before advancing the documents. 

As usual, all of my comments are up for discussion, but I think that a
new revision will be needed, so I have moved the document into "Revised
I-D Needed" state in the data tracker and will wait for your emails 
and/or a new revision.

Many thanks for your work,
Adrian

---

I would like you to include some discussion of the "experiment". There
is a note in section 6.1 encouraging deployments to share their
experience of the default values, but that seems like the tip of the
iceberg. Section 9.2 might also usefully contain such a statement.

A way to approach this is to put a paragraph or two at the end of
Section 1 saying:

- This document is presented as an Experimental specification
  because...
- Reports of observations in implementation and deployment are
  encouraged in particular with respect to...
- It is anticipated that, if there is interest and positive reports
  of experimental research and deployments, this specification might
  be revised at some time in the future to progress it on to the
  Standards Track.

---

Some abbreviations will need to be spelled out:
DODAG
RPL

---

Section 1

   Also, the discovered routes may not
   be optimal.

I prefer s/may/might/

Similarly in Section 5

   Also, the discovered routes may not be the best available.

---

There are several mentions of the fact that this I-D allows discovery
of up to four Source Routes per Target. Should you include a comment
about why that limit is acceptable?

---

I am slightly worried by Section 5 saying

   The Target may
   remember the discovered route for use as a Source Route to reach the
   Origin.

Of course, this is true, but there is no evidence that the discovered
Origin-to-Target route can be reversed, so there is no evidence that the
discovered route will work as a Source Route to reach the Origin. I feel
that suggesting this option without qualifying it very heavily is rather
unwise.

Now 7.1 says

      *  The IPv6 addresses in the Address vector MUST be reachable in
         both Forward and Backward directions.  Reachability in the
         Backward direction allows a DRO message to use the route
         accumulated in the Address vector to travel from the Target to
         the Origin.

This would address my concern, but I don't see how a node filling an
address into the Address vector knows that that address is reachable in
the backward direction. That could, itself, be fixed if there is a
process that says a node receiving an Address vector MUST check the last
address in the list and drop the whole message if the address is not
reachable in the backward direction - ah, and there it is in Section
9.4.

So it is all a bit buried! Can you put in some forward pointers?

---

Starting at the top of Section 6 there are some rules about how messages
must be formed. E.g.:

   A P2P mode DIO
   MUST carry one and only one P2P Route Discovery Option

We need a statement (presumably a catch-all, and possibly a pointer to
6550) that tells an implementation what to do with a malformed message.
Some cases will be reject/discard, but I think some will be ignore. For
example, in Section 6.1:
   Version Number: MUST be set to zero
...can surely be safely ignored by the receiver.

And, a number of the fields if set wrongly will simply break things, but
it may be possible to protect against this by cross-checking with the
MOP.

At the end of 6.1, I do find...

   A router MUST discard a received P2P mode DIO if it violates any of
   the rules listed above.

...but it feels like this is intended to apply to the immediately-
preceding bullet list.

---

Section 6.1 has

   o  Mode of Operation (MOP): MUST be set to 4, corresponding to P2P
      Route Discovery mode.

I think this "4" needs to be replaced with "TBD1"

---

Section 7.1

      *  A router adding its address to the vector MUST ensure that its
         address does not already exist in the vector.

s/its address does/any of its addresses do/

---

Section 7.2 and 14.4

Why do you feel it necessary or good to create a new registry of payload
protocols?  Is the 5237 registry a problem for some reason?

Furthermore, why have you reserved 0xff for Private Use? Given that the
whole document is Experimental, this seems a bit extreme. Do you have
a specific motivation for this unusual assignment?

---

Section 8: Options

Since multiple options may be present, you need to describe any ordering
rules.

---

Section 13

Do you think you should advise applications sending data in the Data
Option to take their own precautions to:
a. secure against modification
b. encrypt
c. retransmit/acknowledge the data they are sending?



From adrian@olddog.co.uk  Wed Dec  5 06:22:55 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F3021F854C for ; Wed,  5 Dec 2012 06:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level: 
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Er4ZVj4okLP7 for ; Wed,  5 Dec 2012 06:22:54 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 45E1021F8BCF for ; Wed,  5 Dec 2012 06:22:54 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB5EMcSi021114;  Wed, 5 Dec 2012 14:22:38 GMT
Received: from 950129200 (ixe-nat1.juniper.net [193.110.54.36]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB5EMbCm021088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Dec 2012 14:22:38 GMT
From: "Adrian Farrel" 
To: 
Date: Wed, 5 Dec 2012 14:22:34 -0000
Message-ID: <00e901cdd2f3$f8ffc510$eaff4f30$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac3S8/HyJMdrLfCAR/22F9C78WVc/w==
Content-Language: en-gb
Cc: roll@ietf.org
Subject: [Roll] AD review of draft-ietf-roll-p2p-measurement-06
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 14:22:55 -0000

Hi,

I have done my usual AD review of your document as part of processing
the publication request. This review should be considered alongside 
my review of draft-ietf-roll-p2p-rpl as the documents are closely 
linked.

I have a number of questions and minor issues that I would like to
resolve before advancing the documents. 

As usual, all of my comments are up for discussion, but I think that a
new revision will be needed, so I have moved the document into "Revised
I-D Needed" state in the data tracker and will wait for your emails 
and/or a new revision.

Many thanks for your work,
Adrian


---

As with draft-ietf-roll-p2p-rpl, I would like some discussion in the
Introduction about why this Experimental and what you expect to
discover. I think the text is easier for this document...

   This document provides a mechanism that can be used to determine
   whether and how to establish a new point-to-point route in an LLN.
   This utility of the mechanism described in this document is, 
   therefore, dependent on the existence of a protocol mechanism for
   establishing P2P routes. [I-D.ietf-roll-p2p-rpl] is targeted at
   publication as an Experimental RFC for reasons described in that
   document. It makes sense, therefore, for this document also to be
   targeted as Experimental.

   As experience is gained using the mechanisms described in
   [I-D.ietf-roll-p2p-rpl] it is hoped that the mechanisms described in
   this document will also be used, and feedback will be provided to the
   ROLL working group on the utility and benefits of this document.

---

I think that "quality" is the wrong word. "Quality" is usually
associated with measures like packet loss, delay, and jitter. I don't
think you are measuring those things, and while I understand why you
say "quality of a route", I think you need some other phrase.

I think this more like...

  A Mechanism to Record the end-to-end Metrics of a Point-to-point
             Route in a Low Power and Lossy Network

In the Introduction, you have some nice words...

   to measure
   the aggregated values of the routing metrics along the existing
   route

---

Abstract

I'm confused :-)

The document title is very specific to P2P routes. But the Abstract 
(deliberately?) does not mention P2P. Section 1 seems to imply that I
could run the mechanisms on any route from origin to target to see if it
is good enough - and that would include routes created using normal RPL.
But section 2 explicitly constrains the mechanism to P2P routes.

Furthermore, the redefined terminology in 1.1 (see below for my 
objection to that!) seem to suggest measuring from an arbitrary origin
to an arbitrary target regardless of whether a P2P route exists.

Can you:
- unconfuse me
- make sure that the abstract and introduction explain the real
  situation
- make sure the document title is accurate
- make sure that the document is consistent
- be careful with terminology (just because you run the mechanism from
  A to B in a point-to-point sort of way, doesn't mean that there is a
  P2P route from A to B)

---

1.1                    

Did you really need to redefine these terms instead of use new terms for
new concepts? Given how close the two documents are, it's a shame to 
confuse things.

---

3.1

I was going to say...

   Seems like the H flag is not needed since leaving it clear is 
   semantically equivalent to setting RPLInstanceID=0b10000000

   Not very important, but you increase the chances of a malformed 
   message, and you use your last bit that could be reserved for 
   future use.

...but then I read the text lower down about how a transit router
can change the H flag under special circumstances. Now I am confused
because if the H flag setting is changed, surely the rule governing 
the RPLInstanceID is broken.

---

3.1

Some of the flag settings that have no meaning dependent on other
flag settings are described as "MUST be set to zero" which is fine.
But should you also say they should be ignored?

---

3.1

I found the description of what goes in the Metric Container Options
inadequate. There should at least be a forward pointer to some section
that describes how this piece of the MO object is constructed, but some 
text would help as well.

---

Section 4

   The Origin MUST discard the MO message if:

That reads a bit odd. Didn't the Origin just build the message? Why 
would it build a message and then discard it? Why not just not build a
bad message?

---

Section 5

   An Intermediate Router MUST discard the packet with no further
   processing if the received MO is not a Measurement Request.

For clarity and consistency with other paragraphs, can you add...

   i.e., if the T flag is not set to one.

---

Section 7

   The Origin MUST discard the packet with no further processing ...
   ... if the Origin has no
   recollection of sending a Measurement Request with the sequence
   number listed in the received MO.

Trying to decide why that is a "MUST".
I guess there are some security/bug considerations.
But are you unduly limiting the Origin implementation to be required to
keep track of the MOs that it sends?

---

Section 7

   The Origin MUST examine the routing metric objects inside the Metric
   Container options to evaluate the quality of the measured P2P route.
   If a routing metric object contains local metric values recorded by
   routers on the route, the Origin MUST aggregate these local values
   into an end-to-end value as per the aggregation rules for the metric.

That is going too far in the use of "MUST". The Origin can do anything 
it likes with the Measurement Reply including discard it, hash it and
use it as a random number, or process it according to policy! I think
what you need is...

   The Origin can use the routing metric objects inside the Metric
   Container to evaluate the metrics for the measured P2P route. If a
   routing metric object contains local metric values recorded by 
   routers on the route, the Origin can make use of these local values
   by aggregating them into an end-to-end metric according to the 
   aggregation rules for the specific metric. An Origin is then free to 
   interpret the metrics for the route according to its local policy.

---

Section 8

Question. Can I use this mechanism to find out stuff about the network
that should/would otherwise be private? And could I, as an outside node
do that?

For example, if I sit next to the network and ping every possible P2P 
route, can I find out which nodes are almost out of battery, and which
nodes are key nodes in the topology? Knowing this would help me attack
the network. What are the protections?


---

11.2
You have used [I-D.ietf-roll-p2p-rpl] as a normative reference (at 
least for the terminology).


From jvasseur@cisco.com  Thu Dec  6 07:27:49 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ABB21F85C7 for ; Thu,  6 Dec 2012 07:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtvisPJMxAWR for ; Thu,  6 Dec 2012 07:27:48 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9C21F859D for ; Thu,  6 Dec 2012 07:27:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7819; q=dns/txt; s=iport; t=1354807668; x=1356017268; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=abT7HGaAPh8VPyDZbkwfexe7pj7cDgYfC7ENmkCl3Cs=; b=cTVuuH2bTPrlx+xoUS7+Cx3vKcTMS3T0979u4KO//67MpYp+1iSiCSfu opyB48c6I9kFxnc1Gej8z/IVfL+1sJy5qoiL7xp7VrR2lwzA4aLcuVwHW kow5ppuZ/oqo8C8mQaM680PBgkEwopgmMPDFGDjfG03BQLol9RYUlytb8 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIW4wFCtJV2b/2dsb2JhbABEvikWc4IeAQEBAwEBAQE3MgILBQsCAQgiFBAnCyUCBA4FCIgCBgzCKwSMOQUXg0ZhA6ZKgnOCIg
X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="147101978"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 06 Dec 2012 15:27:47 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB6FRlV3000359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2012 15:27:47 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.204]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 09:27:47 -0600
From: "JP Vasseur (jvasseur)" 
To: "" 
Thread-Topic: [Roll] AD review of draft-ietf-roll-p2p-measurement-06
Thread-Index: AQHN08Y++FRW99v7tkWHC7Kkbt2jkw==
Date: Thu, 6 Dec 2012 15:27:46 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A77230C78E5@xmb-rcd-x02.cisco.com>
References: <00e901cdd2f3$f8ffc510$eaff4f30$@olddog.co.uk>
In-Reply-To: <00e901cdd2f3$f8ffc510$eaff4f30$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.144.49]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" 
Subject: Re: [Roll] AD review of draft-ietf-roll-p2p-measurement-06
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Dec 2012 15:27:49 -0000

Hi,

Thanks Adrian - I would agree to post a new revision addressing your commen=
t before IETF LC.

Thanks.

JP.

On Dec 5, 2012, at 3:22 PM, Adrian Farrel wrote:

> Hi,
>=20
> I have done my usual AD review of your document as part of processing
> the publication request. This review should be considered alongside=20
> my review of draft-ietf-roll-p2p-rpl as the documents are closely=20
> linked.
>=20
> I have a number of questions and minor issues that I would like to
> resolve before advancing the documents.=20
>=20
> As usual, all of my comments are up for discussion, but I think that a
> new revision will be needed, so I have moved the document into "Revised
> I-D Needed" state in the data tracker and will wait for your emails=20
> and/or a new revision.
>=20
> Many thanks for your work,
> Adrian
>=20
>=20
> ---
>=20
> As with draft-ietf-roll-p2p-rpl, I would like some discussion in the
> Introduction about why this Experimental and what you expect to
> discover. I think the text is easier for this document...
>=20
>   This document provides a mechanism that can be used to determine
>   whether and how to establish a new point-to-point route in an LLN.
>   This utility of the mechanism described in this document is,=20
>   therefore, dependent on the existence of a protocol mechanism for
>   establishing P2P routes. [I-D.ietf-roll-p2p-rpl] is targeted at
>   publication as an Experimental RFC for reasons described in that
>   document. It makes sense, therefore, for this document also to be
>   targeted as Experimental.
>=20
>   As experience is gained using the mechanisms described in
>   [I-D.ietf-roll-p2p-rpl] it is hoped that the mechanisms described in
>   this document will also be used, and feedback will be provided to the
>   ROLL working group on the utility and benefits of this document.
>=20
> ---
>=20
> I think that "quality" is the wrong word. "Quality" is usually
> associated with measures like packet loss, delay, and jitter. I don't
> think you are measuring those things, and while I understand why you
> say "quality of a route", I think you need some other phrase.
>=20
> I think this more like...
>=20
>  A Mechanism to Record the end-to-end Metrics of a Point-to-point
>             Route in a Low Power and Lossy Network
>=20
> In the Introduction, you have some nice words...
>=20
>   to measure
>   the aggregated values of the routing metrics along the existing
>   route
>=20
> ---
>=20
> Abstract
>=20
> I'm confused :-)
>=20
> The document title is very specific to P2P routes. But the Abstract=20
> (deliberately?) does not mention P2P. Section 1 seems to imply that I
> could run the mechanisms on any route from origin to target to see if it
> is good enough - and that would include routes created using normal RPL.
> But section 2 explicitly constrains the mechanism to P2P routes.
>=20
> Furthermore, the redefined terminology in 1.1 (see below for my=20
> objection to that!) seem to suggest measuring from an arbitrary origin
> to an arbitrary target regardless of whether a P2P route exists.
>=20
> Can you:
> - unconfuse me
> - make sure that the abstract and introduction explain the real
>  situation
> - make sure the document title is accurate
> - make sure that the document is consistent
> - be careful with terminology (just because you run the mechanism from
>  A to B in a point-to-point sort of way, doesn't mean that there is a
>  P2P route from A to B)
>=20
> ---
>=20
> 1.1                   =20
>=20
> Did you really need to redefine these terms instead of use new terms for
> new concepts? Given how close the two documents are, it's a shame to=20
> confuse things.
>=20
> ---
>=20
> 3.1
>=20
> I was going to say...
>=20
>   Seems like the H flag is not needed since leaving it clear is=20
>   semantically equivalent to setting RPLInstanceID=3D0b10000000
>=20
>   Not very important, but you increase the chances of a malformed=20
>   message, and you use your last bit that could be reserved for=20
>   future use.
>=20
> ...but then I read the text lower down about how a transit router
> can change the H flag under special circumstances. Now I am confused
> because if the H flag setting is changed, surely the rule governing=20
> the RPLInstanceID is broken.
>=20
> ---
>=20
> 3.1
>=20
> Some of the flag settings that have no meaning dependent on other
> flag settings are described as "MUST be set to zero" which is fine.
> But should you also say they should be ignored?
>=20
> ---
>=20
> 3.1
>=20
> I found the description of what goes in the Metric Container Options
> inadequate. There should at least be a forward pointer to some section
> that describes how this piece of the MO object is constructed, but some=20
> text would help as well.
>=20
> ---
>=20
> Section 4
>=20
>   The Origin MUST discard the MO message if:
>=20
> That reads a bit odd. Didn't the Origin just build the message? Why=20
> would it build a message and then discard it? Why not just not build a
> bad message?
>=20
> ---
>=20
> Section 5
>=20
>   An Intermediate Router MUST discard the packet with no further
>   processing if the received MO is not a Measurement Request.
>=20
> For clarity and consistency with other paragraphs, can you add...
>=20
>   i.e., if the T flag is not set to one.
>=20
> ---
>=20
> Section 7
>=20
>   The Origin MUST discard the packet with no further processing ...
>   ... if the Origin has no
>   recollection of sending a Measurement Request with the sequence
>   number listed in the received MO.
>=20
> Trying to decide why that is a "MUST".
> I guess there are some security/bug considerations.
> But are you unduly limiting the Origin implementation to be required to
> keep track of the MOs that it sends?
>=20
> ---
>=20
> Section 7
>=20
>   The Origin MUST examine the routing metric objects inside the Metric
>   Container options to evaluate the quality of the measured P2P route.
>   If a routing metric object contains local metric values recorded by
>   routers on the route, the Origin MUST aggregate these local values
>   into an end-to-end value as per the aggregation rules for the metric.
>=20
> That is going too far in the use of "MUST". The Origin can do anything=20
> it likes with the Measurement Reply including discard it, hash it and
> use it as a random number, or process it according to policy! I think
> what you need is...
>=20
>   The Origin can use the routing metric objects inside the Metric
>   Container to evaluate the metrics for the measured P2P route. If a
>   routing metric object contains local metric values recorded by=20
>   routers on the route, the Origin can make use of these local values
>   by aggregating them into an end-to-end metric according to the=20
>   aggregation rules for the specific metric. An Origin is then free to=20
>   interpret the metrics for the route according to its local policy.
>=20
> ---
>=20
> Section 8
>=20
> Question. Can I use this mechanism to find out stuff about the network
> that should/would otherwise be private? And could I, as an outside node
> do that?
>=20
> For example, if I sit next to the network and ping every possible P2P=20
> route, can I find out which nodes are almost out of battery, and which
> nodes are key nodes in the topology? Knowing this would help me attack
> the network. What are the protections?
>=20
>=20
> ---
>=20
> 11.2
> You have used [I-D.ietf-roll-p2p-rpl] as a normative reference (at=20
> least for the terminology).
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From jvasseur@cisco.com  Wed Dec 12 02:51:49 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D33921F8975 for ; Wed, 12 Dec 2012 02:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQt3SRUZLFN5 for ; Wed, 12 Dec 2012 02:51:48 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4742821F8973 for ; Wed, 12 Dec 2012 02:51:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3943; q=dns/txt; s=iport; t=1355309508; x=1356519108; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Wsle9AC6vYMomeJ95EWcN645YpZspR7IoiiJwnsbFx4=; b=PCI/J3xP+lEoecb0EB9Voxnkr/QAzTdKaM2UdJvs9nFChzqbkNK2ITLc FknFtwdn3Sfa9jwqvbuzxtq1WNAJSk2OQrdT/tU8xkO738Q7+rs3GtNap rh3VVAtSK0XJsKtbdw+zASqgxeVQskG1CJbsbnvt26veuQWEOg2kFSU9M E=;
X-IronPort-AV: E=Sophos;i="4.84,265,1355097600"; d="scan'208";a="152085461"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 12 Dec 2012 10:51:48 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBCApljM024262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 10:51:47 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 04:51:47 -0600
From: "JP Vasseur (jvasseur)" 
To: Abdussalam Baryun 
Thread-Topic: [Roll] Comments For ROLL terminology-06
Thread-Index: AQHN2FauUIhj9kFSW0eXRoENFKLwwg==
Date: Wed, 12 Dec 2012 10:51:47 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7723100376@xmb-rcd-x02.cisco.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.94.31]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: roll 
Subject: Re: [Roll] Comments For ROLL terminology-06
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Dec 2012 10:51:49 -0000

Hi,

And sorry for the delay -=20

On Aug 3, 2012, at 10:46 PM, Abdussalam Baryun wrote:

> Hi JP and All,
>=20
> I need your comments/feedback on the below, and want to know if there
> will be update to the expired document.
>=20
> Regards
> AB
>=20
> On 7/5/12, Abdussalam Baryun  wrote:
>> Hi Vasseur, and All,
>>=20
>> Comments:
>> +++++++++
>>=20
>> AB>general comment> ROLL is about routers/nodes/hosts Why not defined
>> :  Host, Node, Link, Interface
>>=20
>> In the body of draft-06:-
>>=20
>> Closed Loop Control: A process whereby a device controller controls
>> an actuator based on information sensed by one or more field devices.
>>=20
>> AB>suggest> replace [process] with [procedure]
>> AB>suggest> replace [information] with [input information]
>>=20
>> Downstream: Data direction traveling from outside of the LLN (e.g.
>> traffic coming from a LAN, WAN or the Internet) via a LBR.
>>=20

JP> Done, thanks.

>> AB> suggest> remove the example, because first, ROLL is inside LLN not
>> outside, and second, most of the data-traffic MAY go from the LLN to
>> the Internet/LBR. IMHO downstream is in the direction of the havier
>> unit-flow.

JP> Ah but =85 the direction where the traffic is heavier really depends. T=
here are applications/networks
where many packets travels upstream, few (but large) packets travel upstrea=
m; number of packets and
volume of traffic are thus different. Furthermore, upstream/downstream defi=
nition should stay agnostic to
the direction, otherwise this may lead to confusion and we need to keep it =
consistent with the RFCs.

>>=20
>> AB> please note that if we use word [data] is different than
>> [message]. While using [message] we may mean all traffic includes data
>> and control messages, so the use of downstream and upstream as in
>> draft-06 will be ok, but if we mention data-direction IMHO the use
>> downstream-upstream will be the other way around.
>>=20
>> AB> suggest> replace [data] with [message]
>>=20

JP> Kept "data" to be consistent with RFC and usual IETF terminology.

>> Field Device:
>>=20
>> AB> delete word> field
>>=20

JP> This is the terminology used in literature though ...

>> MP2P: Multipoint-to-Point is used to describe a particular traffic
>> pattern (e.g. MP2P flows collecting information from many nodes
>> flowing inwards towards a collecting sink or an LBR).
>>=20
>> AB>opinion> MP2P is not a traffic pattern it is a transmission method
>>=20

JP> Ah no no =85 not in this case and this was debated on the mailing for q=
uite some time. We are=20
referring in this case to the traffic pattern, not the protocol (see RFC 65=
50).

Many thanks for your review !

JP.

>> I am not sure if the draft covers all terms used in ROLL protocols, I
>> will check and post on the same thread after. Thanking you,
>>=20
>> Best Regards
>>=20
>> Abdussalam Baryun
>> University of glamorgan, UK
>> +++++++++++++++++++++++++++++++++++++++++++++++++
>> I may be wrong, or may be right, but it does not matter if we work toget=
her
>> as a group to discuss and resolve all issues. WGs are always right.
>> ************************************************************************=
*****
>> This email and any attachments are confidential to the intended recipien=
t
>> and may also be privileged. If you are not the intended recipient please
>> delete it from your system and notify the sender. The contents are compl=
y
>> to the IETF regulations, and WG procedures. You should not copy the
>> email nor use it for any other purpose, nor disclose, nor distribute its
>> contents to any other person.
>> ************************************************************************=
*****
>>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From internet-drafts@ietf.org  Wed Dec 12 02:54:51 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5069821F8982; Wed, 12 Dec 2012 02:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level: 
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PWqVvnB9ees; Wed, 12 Dec 2012 02:54:50 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB26621F8946; Wed, 12 Dec 2012 02:54:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.36
Message-ID: <20121212105450.3710.95801.idtracker@ietfa.amsl.com>
Date: Wed, 12 Dec 2012 02:54:50 -0800
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-terminology-07.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Dec 2012 10:54:51 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Over Low power and Lossy networks=
 Working Group of the IETF.

	Title           : Terminology in Low power And Lossy Networks
	Author(s)       : JP Vasseur
	Filename        : draft-ietf-roll-terminology-07.txt
	Pages           : 8
	Date            : 2012-12-12

Abstract:
   The documents defines a terminology for discussing routing
   requirements and solutions for networks referred to as Low power and
   Lossy Networks (LLN).  A LLN is typically composed of many embedded
   devices with limited power, memory, and processing resources
   interconnected by a variety of links.  There is a wide scope of
   application areas for LLNs, including industrial monitoring, building
   automation (e.g.  Heating, Ventilating, Air Conditioning, lighting,
   access control, fire), connected home, healthcare, environmental
   monitoring, urban sensor networks, energy management, assets
   tracking, refrigeration.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-terminology

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-terminology-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-terminology-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Wed Dec 12 02:58:03 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18E421F88F7; Wed, 12 Dec 2012 02:58:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level: 
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR97e7JLLu0O; Wed, 12 Dec 2012 02:58:02 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F4221F8533; Wed, 12 Dec 2012 02:58:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.36
Message-ID: <20121212105802.24775.15494.idtracker@ietfa.amsl.com>
Date: Wed, 12 Dec 2012 02:58:02 -0800
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-terminology-08.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Dec 2012 10:58:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Over Low power and Lossy networks=
 Working Group of the IETF.

	Title           : Terminology in Low power And Lossy Networks
	Author(s)       : JP Vasseur
	Filename        : draft-ietf-roll-terminology-08.txt
	Pages           : 8
	Date            : 2012-12-12

Abstract:
   The documents defines a terminology for discussing routing
   requirements and solutions for networks referred to as Low power and
   Lossy Networks (LLN).  A LLN is typically composed of many embedded
   devices with limited power, memory, and processing resources
   interconnected by a variety of links.  There is a wide scope of
   application areas for LLNs, including industrial monitoring, building
   automation (e.g.  Heating, Ventilating, Air Conditioning, lighting,
   access control, fire), connected home, healthcare, environmental
   monitoring, urban sensor networks, energy management, assets
   tracking, refrigeration.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-terminology

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-terminology-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-terminology-08


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From prvs=68608198d=mukul@uwm.edu  Wed Dec 12 08:18:11 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B2D21E804D for ; Wed, 12 Dec 2012 08:18:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQfvN82jNVvv for ; Wed, 12 Dec 2012 08:18:10 -0800 (PST)
Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id CA84721E804A for ; Wed, 12 Dec 2012 08:18:09 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAJ+tyFB/AAAB/2dsb2JhbAA7BAaGN7h0gxgjVhsaAg0ZAlkGEYgTDKpMiXyJBQSBIos6BRGDCYETA4hgjSmQSIMSIIEmPQ
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 4457E2A0F8F; Wed, 12 Dec 2012 10:18:08 -0600 (CST)
X-Virus-Scanned: amavisd-new at 
Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy24elT6Q3nc; Wed, 12 Dec 2012 10:18:08 -0600 (CST)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id F10AA2A0F9F; Wed, 12 Dec 2012 10:18:07 -0600 (CST)
Date: Wed, 12 Dec 2012 10:18:07 -0600 (CST)
From: Mukul Goyal 
To: adrian  
Message-ID: <287955328.88535.1355329087754.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <20121205130218.2838.4560.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: roll 
Subject: Re: [Roll] ID Tracker State Update Notice: 
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Dec 2012 16:18:12 -0000

Hi Adrian

I have updated p2p-rpl draft based on your comments. The updated draft can be found at:

https://pantherfile.uwm.edu/mukul/public/draft-ietf-roll-p2p-rpl-15.txt

Please let me know if the updated draft meets your concerns or if further modifications are required. Once, you have no concerns left, I will post the new version of the document.

Please see my response to your individual comments below.

Thanks
Mukul

---

[Adrian]
I would like you to include some discussion of the "experiment". There
is a note in section 6.1 encouraging deployments to share their
experience of the default values, but that seems like the tip of the
iceberg. Section 9.2 might also usefully contain such a statement.

[Mukul]

See the additional line towards the end of Section 9.2 (search for mods_1_)

[Adrian]

A way to approach this is to put a paragraph or two at the end of
Section 1 saying:

- This document is presented as an Experimental specification
  because...
- Reports of observations in implementation and deployment are
  encouraged in particular with respect to...
- It is anticipated that, if there is interest and positive reports
  of experimental research and deployments, this specification might
  be revised at some time in the future to progress it on to the
  Standards Track.

[Mukul]
See the new paragraph towards the end of Section 1 (search for mods_2_).

---
[Adrian]
Some abbreviations will need to be spelled out:
DODAG
RPL

[Mukul]

Done. Search for mods_3_ and mods_4_
---

[Adrian]
Section 1

   Also, the discovered routes may not
   be optimal.

I prefer s/may/might/

Similarly in Section 5

   Also, the discovered routes may not be the best available.

[Mukul]

Done. Search for mods_5_ and mods_6_.

---

[Adrian]
There are several mentions of the fact that this I-D allows discovery
of up to four Source Routes per Target. Should you include a comment
about why that limit is acceptable?

[Mukul]
Done. Search for mods_7_.

---
[Adrian]
I am slightly worried by Section 5 saying

   The Target may
   remember the discovered route for use as a Source Route to reach the
   Origin.

Of course, this is true, but there is no evidence that the discovered
Origin-to-Target route can be reversed, so there is no evidence that the
discovered route will work as a Source Route to reach the Origin. I feel
that suggesting this option without qualifying it very heavily is rather
unwise.

Now 7.1 says

      *  The IPv6 addresses in the Address vector MUST be reachable in
         both Forward and Backward directions.  Reachability in the
         Backward direction allows a DRO message to use the route
         accumulated in the Address vector to travel from the Target to
         the Origin.

This would address my concern, but I don't see how a node filling an
address into the Address vector knows that that address is reachable in
the backward direction. That could, itself, be fixed if there is a
process that says a node receiving an Address vector MUST check the last
address in the list and drop the whole message if the address is not
reachable in the backward direction - ah, and there it is in Section
9.4.

So it is all a bit buried! Can you put in some forward pointers?

[Mukul]
Done. Search for mods_8.

---

[Adrian]
Starting at the top of Section 6 there are some rules about how messages
must be formed. E.g.:

   A P2P mode DIO
   MUST carry one and only one P2P Route Discovery Option

We need a statement (presumably a catch-all, and possibly a pointer to
6550) that tells an implementation what to do with a malformed message.

[Mukul]
Done. Search for mods_9.

[Adrian]
Some cases will be reject/discard, but I think some will be ignore. For
example, in Section 6.1:
   Version Number: MUST be set to zero
...can surely be safely ignored by the receiver.

[Mukul]
Actually, we insist that version number be set to zero else DIO has to be discarded. RPL uses (RPLInstanceID, DODAGID, VersionNumber) tuple to uniquely identify a DODAG and we dont want to change that in P2P-RPL.

[Adrian]
And, a number of the fields if set wrongly will simply break things, but
it may be possible to protect against this by cross-checking with the
MOP.

At the end of 6.1, I do find...

   A router MUST discard a received P2P mode DIO if it violates any of
   the rules listed above.

...but it feels like this is intended to apply to the immediately-
preceding bullet list.

[Mukul]
Right, the document was not very clear regarding when should a received DIO be dropped. I have added text at a number of places explicitly requiring a received DIO/DRO message to be dropped if given conditions are not met. Please search for mods_10_ to see this text.
 
---
[Adrian]
Section 6.1 has

   o  Mode of Operation (MOP): MUST be set to 4, corresponding to P2P
      Route Discovery mode.

I think this "4" needs to be replaced with "TBD1"

[Mukul]
Yes. Done. Search for mods_11.
---
[Adrian]
Section 7.1

      *  A router adding its address to the vector MUST ensure that its
         address does not already exist in the vector.

s/its address does/any of its addresses do/

[Mukul]
Done. Search for mods_12_.
---
[Adrian]
Section 7.2 and 14.4

Why do you feel it necessary or good to create a new registry of payload
protocols?  Is the 5237 registry a problem for some reason?

Furthermore, why have you reserved 0xff for Private Use? Given that the
whole document is Experimental, this seems a bit extreme. Do you have
a specific motivation for this unusual assignment?

[Mukul]

We were using a new registry because this field was 4 bits earlier. Now that it is 8 bits now, we can use 5237 registry. The change has been made. Please search for mods_13_ to see the new text.

---

[Adrian]
Section 8: Options

Since multiple options may be present, you need to describe any ordering
rules.

[Mukul]
There are no ordering rules. RPL does not specify any ordering rules either.
---
[Adrian]
Section 13

Do you think you should advise applications sending data in the Data
Option to take their own precautions to:
a. secure against modification
b. encrypt
c. retransmit/acknowledge
the data they are sending?

[Mukul]
Since the Data Option is inside a DIO/DRO message, it has the same level of protection as the message it is inside. A deployment may use link layer security or RPL's security mechanisms to meet its needs regarding security. I have added text in the Security Section (Section 13) as well as in the section defining Data Option (Section 7.2) to make this clear. I have also added text to clarify that P2P-RPL does not guarantee successful delivery of the data contained in a Data Option. Please search for mods_14 to see this text.

In addition, I have made one more small modification (search for mods_15) to the document clarifying that a DRO MUST contain one and only one P2P-RDO.

Thanks
Mukul



From adrian@olddog.co.uk  Wed Dec 12 08:53:47 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160B421F8647 for ; Wed, 12 Dec 2012 08:53:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Level: 
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjW+kQQCxsyn for ; Wed, 12 Dec 2012 08:53:45 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 795B821F8626 for ; Wed, 12 Dec 2012 08:53:43 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBCGrelO021184;  Wed, 12 Dec 2012 16:53:41 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBCGrdkt021164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2012 16:53:40 GMT
From: "Adrian Farrel" 
To: "'Mukul Goyal'" 
References: <20121205130218.2838.4560.idtracker@ietfa.amsl.com> <287955328.88535.1355329087754.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <287955328.88535.1355329087754.JavaMail.root@mail17.pantherlink.uwm.edu>
Date: Wed, 12 Dec 2012 16:53:37 -0000
Message-ID: <099f01cdd889$3bf34410$b3d9cc30$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLyynlY+7D60oa39KNlSZmvaq7cUpXLexdA
Content-Language: en-gb
Cc: 'roll' 
Subject: Re: [Roll] ID Tracker State Update Notice: 
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Dec 2012 16:53:47 -0000

Mukul,

This looks good to me.
If you post the I-D I will start the IETF last call.

Many thanks for the answers to my comments and the work on the revision.
Adrian



From internet-drafts@ietf.org  Wed Dec 12 09:13:29 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE001F0CBE; Wed, 12 Dec 2012 09:13:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.533
X-Spam-Level: 
X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnHYzWMQxFSn; Wed, 12 Dec 2012 09:13:29 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7711F0CBD; Wed, 12 Dec 2012 09:13:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.36
Message-ID: <20121212171329.27245.99940.idtracker@ietfa.amsl.com>
Date: Wed, 12 Dec 2012 09:13:29 -0800
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-15.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Dec 2012 17:13:29 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Over Low power and Lossy networks=
 Working Group of the IETF.

	Title           : Reactive Discovery of Point-to-Point Routes in Low Power=
 and Lossy Networks
	Author(s)       : Mukul Goyal
                          Emmanuel Baccelli
                          Matthias Philipp
                          Anders Brandt
                          Jerald Martocci
	Filename        : draft-ietf-roll-p2p-rpl-15.txt
	Pages           : 35
	Date            : 2012-12-12

Abstract:
   This document specifies a point-to-point route discovery mechanism,
   complementary to the RPL core functionality.  This mechanism allows
   an IPv6 router to discover "on demand" routes to one or more IPv6
   routers in the LLN such that the discovered routes meet specified
   metrics constraints.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-15

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-rpl-15


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From iesg-secretary@ietf.org  Wed Dec 12 10:36:29 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDE71F0CD3; Wed, 12 Dec 2012 10:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.451
X-Spam-Level: 
X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7UEGXiSWaby; Wed, 12 Dec 2012 10:36:29 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170671F0CCB; Wed, 12 Dec 2012 10:36:29 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.36
Message-ID: <20121212183629.2809.99076.idtracker@ietfa.amsl.com>
Date: Wed, 12 Dec 2012 10:36:29 -0800
Cc: roll@ietf.org
Subject: [Roll] Last Call:  (Reactive Discovery of	Point-to-Point Routes in Low Power and Lossy Networks) to	Experimental RFC
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Dec 2012 18:36:29 -0000

The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
   Networks'
   as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document specifies a point-to-point route discovery mechanism,
   complementary to the RPL core functionality.  This mechanism allows
   an IPv6 router to discover "on demand" routes to one or more IPv6
   routers in the LLN such that the discovered routes meet specified
   metrics constraints.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ballot/


No IPR declarations have been submitted directly on this I-D.

From prvs=688ae4962=mukul@uwm.edu  Thu Dec 13 17:14:59 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D03D21F8ADA for ; Thu, 13 Dec 2012 17:14:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O7a72ROielI for ; Thu, 13 Dec 2012 17:14:58 -0800 (PST)
Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6D95021F888E for ; Thu, 13 Dec 2012 17:14:57 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0EAKF8ylB/AAAB/2dsb2JhbABFhji4UYMYI1YbGgINGQJZBogmqiSKAYkJgSKLUYMUgRMDiGCNKZBIgxKCAw
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 68891121DCC; Thu, 13 Dec 2012 19:14:56 -0600 (CST)
X-Virus-Scanned: amavisd-new at 
Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hazLB4Om+Vpe; Thu, 13 Dec 2012 19:14:56 -0600 (CST)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 38348121DF4; Thu, 13 Dec 2012 19:14:56 -0600 (CST)
Date: Thu, 13 Dec 2012 19:14:56 -0600 (CST)
From: Mukul Goyal 
To: adrian  
Message-ID: <789414096.115791.1355447696131.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <20121205130341.22852.76100.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: roll 
Subject: Re: [Roll] ID Tracker State Update Notice:	
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 01:14:59 -0000

Hi Adrian

I think this comment needs clarification. So, here it is!

[Adrian]
---

Abstract

I'm confused :-)

The document title is very specific to P2P routes. But the Abstract 
(deliberately?) does not mention P2P.

[Mukul]

Here is the current title: (I will modify it based on your comment on the meaning of the term "quality")

A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network

Here is the current abstract:

"This document specifies a mechanism that enables an RPL router to
   measure the quality of an existing route towards another RPL router
   in a low power and lossy network, thereby allowing the router to
   decide if it wants to initiate the discovery of a better route."

Now, what is a point-to-point (P2P) route? The draft is written assuming that a point-to-point route is a route from one RPL router to another RPL router. This route could be a pure source route or a hop-by-hop route along a DAG or a mixture (hop-by-hop till DAG's root and then source route there onwards). If we agree on this definition than there should not be any confusion. Do you want me to include this definition in the draft?
 
[Adrian]
 Section 1 seems to imply that I
could run the mechanisms on any route from origin to target to see if it
is good enough - and that would include routes created using normal RPL.

[Mukul]
Right.

[Adrian]
But section 2 explicitly constrains the mechanism to P2P routes.

[Mukul]
I think the following sentence offends you:

"The mechanism described in this document can be used by an Origin in
   an LLN to measure the aggregated values of some routing metrics along
   a P2P route to a Target within the LLN."

But I immediately clarify what I mean by a P2P route:

"Such a route could be a
   source route or a hop-by-hop route established using RPL [RFC6550] or
   P2P-RPL [I-D.ietf-roll-p2p-rpl]. "

I think I will replace the term "P2P" in the offending sentence to "existing". This should remove the confusion.

[Adrian]
Furthermore, the redefined terminology in 1.1 (see below for my 
objection to that!) seem to suggest measuring from an arbitrary origin
to an arbitrary target regardless of whether a P2P route exists.

[Mukul]
We can indeed use the specified mechanism to measure routing metric values along an existing route from any arbitrary origin (as long as it is an rpl router) to any arbitrary target (as long as it is an rpl router) within the same LLN. 

I think you are assuming that a P2P route is the one established using P2P-RPL. This is not the case. A P2P route is a route from one point (RPL router) to another (RPL router) and could have been established using RPL or P2P-RPL or any other routing protocol.

[Adrian]
Can you:
- unconfuse me

[Mukul]
I hope I just did!

[Adrian]
- make sure that the abstract and introduction explain the real
  situation
- make sure the document title is accurate
- make sure that the document is consistent
- be careful with terminology (just because you run the mechanism from
  A to B in a point-to-point sort of way, doesn't mean that there is a
  P2P route from A to B)

[Mukul]
Or may be there is another definition of "P2P route from A to B" that I am missing?
 
Thanks
Mukul


From trac+roll@trac.tools.ietf.org  Thu Dec 13 18:27:58 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30CB21F8C06 for ; Thu, 13 Dec 2012 18:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAITMC0tspAe for ; Thu, 13 Dec 2012 18:27:58 -0800 (PST)
Received: from gamay.tools.ietf.org (unknown [IPv6:2607:f170:8000:1500::de]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED8C21F8C05 for ; Thu, 13 Dec 2012 18:27:57 -0800 (PST)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TjL05-0002Sk-Im; Thu, 13 Dec 2012 21:27:46 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca
X-Trac-Project: roll
Date: Fri, 14 Dec 2012 02:27:45 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/107#comment:2
Message-ID: <073.5964827e95105ea1dd3ab0a0d64712e0@trac.tools.ietf.org>
References: <058.d8b807f46e7601c2df8bad69d7cb737b@trac.tools.ietf.org>
X-Trac-Ticket-ID: 107
In-Reply-To: <058.d8b807f46e7601c2df8bad69d7cb737b@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com
Resent-Message-Id: <20121214022758.4ED8C21F8C05@ietfa.amsl.com>
Resent-Date: Thu, 13 Dec 2012 18:27:57 -0800 (PST)
Resent-From: trac+roll@trac.tools.ietf.org
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #107: trickle-mcast: should multiple parameter sets be supported
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 02:27:58 -0000

#107: trickle-mcast: should multiple parameter sets be supported


Comment (by mcr@…):

 There is has been little discussion about this issue.
 My inclination is to not include multiple sets at this time.

-- 
----------------------------+----------------------------------------------
 Reporter:  mcr@…           |       Owner:  draft-ietf-roll-trickle-mcast@…
     Type:  enhancement     |      Status:  new
 Priority:  major           |   Milestone:
Component:  trickle-mcast   |     Version:
 Severity:  In WG Last      |  Resolution:
  Call                      |
 Keywords:                  |
----------------------------+----------------------------------------------

Ticket URL: 
roll 


From adrian@olddog.co.uk  Fri Dec 14 03:24:07 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD7F21F853D for ; Fri, 14 Dec 2012 03:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxV7SJsfwGsP for ; Fri, 14 Dec 2012 03:24:06 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id E3CEB21F853C for ; Fri, 14 Dec 2012 03:24:00 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBEBNvK3029926;  Fri, 14 Dec 2012 11:23:57 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBEBNu57029915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 11:23:56 GMT
From: "Adrian Farrel" 
To: "'Michael Richardson'" 
References: <30489.1355451277@obiwan.sandelman.ca>
In-Reply-To: <30489.1355451277@obiwan.sandelman.ca>
Date: Fri, 14 Dec 2012 11:23:54 -0000
Message-ID: <00b401cdd9ed$80ac6270$82052750$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKL3otY+tHaMq3yh8PLWOhpaapgn5acHVHA
Content-Language: en-gb
Cc: roll@ietf.org, draft-ietf-roll-trickle-mcast@tools.ietf.org
Subject: Re: [Roll] Request for IESG approval of early allocation for HBH code point
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 11:24:07 -0000

Thanks Michael,

This looks like a reasonable request to me. I have put it on the agenda for IESG
consideration at the next telechat on Thursday 20th.

If anyone has any issues of concerns please speak soon.

Adrian

> -----Original Message-----
> From: mcr@obiwan.sandelman.ca [mailto:mcr@obiwan.sandelman.ca] On Behalf
> Of Michael Richardson
> Sent: 14 December 2012 02:15
> To: Adrian Farrel
> Cc: roll@ietf.org; draft-ietf-roll-trickle-mcast@tools.ietf.org
> Subject: Request for IESG approval of early allocation for HBH code point
> 
> 
> Adrian,
> 
> The ROLL WG is in the process of finalizing the details of the
> draft-ietf-roll-trickle-mcast.   In this document there is an IANA
> request:
> 
>  8.  IANA Considerations
> 
>    The Trickle Multicast option requires an IPv6 Option Number.
> 
>    HEX         act  chg  rest
>    ---         ---  ---  -----
>      C          01    0  TBD
> 
>    The first two bits indicate that the IPv6 node MUST discard the
>    packet if it doesn't recognize the option type, and the third bit
>    indicates that the Option Data MUST NOT change en-route.
> 
> Implementers in the ZigBee IP need this value set sooner rather than
> later in order to do interoperability testing.
> 
> The need for the allocation will not change even if the precise layout
> of one or two bits in the option is not yet fully agreed to.
> 
> The registraty is at:
>     http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
> and is entitled "Destination Options and Hop-by-Hop Options".
> 
> The registry says:
>   Registration Procedures
>     IESG Approval, IETF Consensus or Standards Action
> 
> so while it does not support early approval, it does support IESG
> Approval.
> 
> We would therefore ask the IESG to please allocate this hop-by-hop
> option.
> 
> --
> Michael Richardson , Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/



From adrian@olddog.co.uk  Fri Dec 14 03:31:09 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD58221F857B for ; Fri, 14 Dec 2012 03:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.563
X-Spam-Level: 
X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4QTg8Y1REv6 for ; Fri, 14 Dec 2012 03:31:09 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id D8EC121F858C for ; Fri, 14 Dec 2012 03:31:08 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBEBV6iv003349;  Fri, 14 Dec 2012 11:31:07 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBEBV5Gw003317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 11:31:06 GMT
From: "Adrian Farrel" 
To: "'Mukul Goyal'" 
References: <20121205130341.22852.76100.idtracker@ietfa.amsl.com> <789414096.115791.1355447696131.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <789414096.115791.1355447696131.JavaMail.root@mail17.pantherlink.uwm.edu>
Date: Fri, 14 Dec 2012 11:31:03 -0000
Message-ID: <00c401cdd9ee$80c83260$82589720$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJGmD481w0jIuUDjM0quxi97XqkJZcmqxuw
Content-Language: en-gb
Cc: 'roll' 
Subject: Re: [Roll] ID Tracker State Update Notice:	
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 11:31:09 -0000

Hi Mukul,

My confusion (this time ;-) was caused by reviewing =
draft-ietf-roll-p2p-rpl immediately previous.

Reading that document, it became very clear in my head that there is a =
difference between "normal" operation of RPL and P2P-RPL. Therefore, it =
was completely clear [sic] to me that this I-D was for use in measuring =
routes in P2P-RPL.

Of course, now you point it out (and since I have had a little sleep) is =
it obvious that this I-D is about making measurements of the traffic =
path between a pair of nodes in a RPL-operated network.

Maybe my language in that last paragraph might help if you feel =
charitably inclined. But the whole thing, now it has penetrated the =
recesses of my cranium, does not require any further work.

Thanks,
Adrian

> -----Original Message-----
> From: Mukul Goyal [mailto:mukul@uwm.edu]
> Sent: 14 December 2012 01:15
> To: adrian
> Cc: roll
> Subject: Re: ID Tracker State Update Notice: =
 06.txt>
>=20
> Hi Adrian
>=20
> I think this comment needs clarification. So, here it is!
>=20
> [Adrian]
> ---
>=20
> Abstract
>=20
> I'm confused :-)
>=20
> The document title is very specific to P2P routes. But the Abstract
> (deliberately?) does not mention P2P.
>=20
> [Mukul]
>=20
> Here is the current title: (I will modify it based on your comment on =
the meaning
> of the term "quality")
>=20
> A Mechanism to Measure the Quality of a Point-to-point Route in a Low =
Power
> and Lossy Network
>=20
> Here is the current abstract:
>=20
> "This document specifies a mechanism that enables an RPL router to
>    measure the quality of an existing route towards another RPL router
>    in a low power and lossy network, thereby allowing the router to
>    decide if it wants to initiate the discovery of a better route."
>=20
> Now, what is a point-to-point (P2P) route? The draft is written =
assuming that a
> point-to-point route is a route from one RPL router to another RPL =
router. This
> route could be a pure source route or a hop-by-hop route along a DAG =
or a
> mixture (hop-by-hop till DAG's root and then source route there =
onwards). If we
> agree on this definition than there should not be any confusion. Do =
you want me
> to include this definition in the draft?
>=20
> [Adrian]
>  Section 1 seems to imply that I
> could run the mechanisms on any route from origin to target to see if =
it
> is good enough - and that would include routes created using normal =
RPL.
>=20
> [Mukul]
> Right.
>=20
> [Adrian]
> But section 2 explicitly constrains the mechanism to P2P routes.
>=20
> [Mukul]
> I think the following sentence offends you:
>=20
> "The mechanism described in this document can be used by an Origin in
>    an LLN to measure the aggregated values of some routing metrics =
along
>    a P2P route to a Target within the LLN."
>=20
> But I immediately clarify what I mean by a P2P route:
>=20
> "Such a route could be a
>    source route or a hop-by-hop route established using RPL [RFC6550] =
or
>    P2P-RPL [I-D.ietf-roll-p2p-rpl]. "
>=20
> I think I will replace the term "P2P" in the offending sentence to =
"existing". This
> should remove the confusion.
>=20
> [Adrian]
> Furthermore, the redefined terminology in 1.1 (see below for my
> objection to that!) seem to suggest measuring from an arbitrary origin
> to an arbitrary target regardless of whether a P2P route exists.
>=20
> [Mukul]
> We can indeed use the specified mechanism to measure routing metric =
values
> along an existing route from any arbitrary origin (as long as it is an =
rpl router) to
> any arbitrary target (as long as it is an rpl router) within the same =
LLN.
>=20
> I think you are assuming that a P2P route is the one established using =
P2P-RPL.
> This is not the case. A P2P route is a route from one point (RPL =
router) to another
> (RPL router) and could have been established using RPL or P2P-RPL or =
any other
> routing protocol.
>=20
> [Adrian]
> Can you:
> - unconfuse me
>=20
> [Mukul]
> I hope I just did!
>=20
> [Adrian]
> - make sure that the abstract and introduction explain the real
>   situation
> - make sure the document title is accurate
> - make sure that the document is consistent
> - be careful with terminology (just because you run the mechanism from
>   A to B in a point-to-point sort of way, doesn't mean that there is a
>   P2P route from A to B)
>=20
> [Mukul]
> Or may be there is another definition of "P2P route from A to B" that =
I am
> missing?
>=20
> Thanks
> Mukul


From esko.dijk@philips.com  Wed Dec 19 03:28:21 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292F021F894D for ; Wed, 19 Dec 2012 03:28:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS-2JcOdQl08 for ; Wed, 19 Dec 2012 03:28:20 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 796C821F87CB for ; Wed, 19 Dec 2012 03:28:20 -0800 (PST)
Received: from mail74-co9-R.bigfish.com (10.236.132.241) by CO9EHSOBE010.bigfish.com (10.236.130.73) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Dec 2012 11:28:18 +0000
Received: from mail74-co9 (localhost [127.0.0.1])	by mail74-co9-R.bigfish.com (Postfix) with ESMTP id 8F83526019D; Wed, 19 Dec 2012 11:28:18 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-SpamScore: -31
X-BigFish: VPS-31(zz217bI15d6O9251J542Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h)
Received: from mail74-co9 (localhost.localdomain [127.0.0.1]) by mail74-co9 (MessageSwitch) id 1355916497563697_3962; Wed, 19 Dec 2012 11:28:17 +0000 (UTC)
Received: from CO9EHSMHS016.bigfish.com (unknown [10.236.132.246])	by mail74-co9.bigfish.com (Postfix) with ESMTP id 874AA4E005B; Wed, 19 Dec 2012 11:28:17 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS016.bigfish.com (10.236.130.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Dec 2012 11:28:17 +0000
Received: from 011-DB3MMR1-017.MGDPHG.emi.philips.com (10.128.28.102) by 011-DB3MMR1-004.MGDPHG.emi.philips.com (10.128.28.54) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 19 Dec 2012 11:27:59 +0000
Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.225]) by 011-DB3MMR1-017.MGDPHG.emi.philips.com ([10.128.28.102]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 11:27:58 +0000
From: "Dijk, Esko" 
To: Michael Richardson , "roll@ietf.org" 
Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
Thread-Index: AQHNwkOFtl9ztYUSrkiATuslfJmcUZfpG0MQgAVVjYCAAmIfMIAAeegAgAADkUCAAbgKAIAVyJ4QgA7yDICABxtAUA==
Date: Wed, 19 Dec 2012 11:27:57 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618B394C6@011-DB3MPN2-082.MGDPHG.emi.philips.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <109e9168af966b0ee543f13886fef7ef@xs4all.nl> <8796.1352758060@sandelman.ca> <895d55da5f389dc29760cd52aaf91d61@xs4all.nl> <031DD135F9160444ABBE3B0C36CED618B0C67D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <6733.1353180917@obiwan.sandelman.ca> <031DD135F9160444ABBE3B0C36CED618B1D844@011-DB3MPN2-083.MGDPHG.emi.philips.com> <21170.1353338118@obiwan.sandelman.ca> <031DD135F9160444ABBE3B0C36CED618B20638@011-DB3MPN2-083.MGDPHG.emi.philips.com> <22106.1353433382@obiwan.sandelman.ca> <031DD135F9160444ABBE3B0C36CED618B3646A@011-DB3MPN2-082.MGDPHG. emi.phil ips.com> <2283.1355452589@obiwan.sandelman.ca>
In-Reply-To: <2283.1355452589@obiwan.sandelman.ca>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.138.224.32]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 11:28:21 -0000

> I asked a question, how does a node know if it should forward/rebroadcast=
 a packet in an identified MPL domain.

Ah, ok. Maybe both question and answer become easier once we have an update=
 of the I-D text? My simple view is:
For 'node' being an MPL forwarder, there's no decision to make: it will any=
way forward packets (with the MPL Option) on the same interface at which it=
 was received, following the MPL protocol. Only a single MPL domain is assi=
gned to any one network interface (assumption).

If an MPL forwarder wants to send/forward to other interfaces and/or into o=
ther MPL domains it knows, that's possible - but needs to be explicitly con=
figured/implemented on the forwarder. MPL states a forwarder MAY do this.

> ...how, when the MPL domain is less than the LLN, the packets are pruned =
to just the MPL domain.
The pruning happens automatically if there is only one MPL domain configure=
d within an LLN.
Specifically, the non-MPL-forwarders that are inside the LLN but outside th=
e MPL domain won't forward the packets by definition.

For other cases (i.e. 2 or more MPL domains within the subnet) I have the s=
ame question as you - it seems impossible to do the 'pruning' correctly bas=
ed on the current MPL -02 text, for unencapsulated multicast packets at lea=
st.

Esko

-----Original Message-----
From: mcr@obiwan.sandelman.ca [mailto:mcr@obiwan.sandelman.ca] On Behalf Of=
 Michael Richardson
Sent: Friday 14 December 2012 3:36
To: roll@ietf.org
Cc: Dijk, Esko; consultancy@vanderstok.org
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of M=
PL domain


Dijk, I do not feel that you understood the question.

>>>>> "Dijk," =3D=3D Dijk, Esko  writes:
    Dijk> Just to check our current understanding of scope:

    >> How does a node determine what the scope of the MPL domain?

    Dijk> From the I-D -02, it is "multicast scope of the IPv6
    Dijk> Destination Address of an MPL multicast packet". So it can be
    Dijk> derived from the mcast address(es) that MPL uses which are
    Dijk> defined in application code or in a config file or so.

You answered the question:
    "how does a node determine the MPL domain of a multicast packet"

I asked a question, how does a node know if it should forward/rebroadcast a=
 packet in an identified MPL domain.

    >> Is this an intrinsic (provisioned) property of a node?

    Dijk> - if encapsulation is used, I expect the outer IP address is
    Dijk> configured in the node (e.g. FF05::MPL)


    Dijk> - if encapsulation is not used, the IP address where to send
    Dijk> to or to receive on would be set by the application code
    Dijk> i.e. it's also configured on the node (e.g. FF05::1234)


I do not feel that I have a good understanding of how, when the MPL domain =
is less than the LLN, how the packets are pruned to just the MPL domain.


--
Michael Richardson , Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From adrian@olddog.co.uk  Thu Dec 20 13:38:59 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B690721F8623 for ; Thu, 20 Dec 2012 13:38:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKX6IdzqLcbl for ; Thu, 20 Dec 2012 13:38:59 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id CD18021F86CD for ; Thu, 20 Dec 2012 13:38:58 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBKLcvA5004380 for ; Thu, 20 Dec 2012 21:38:57 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBKLcuv9004368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Dec 2012 21:38:57 GMT
From: "Adrian Farrel" 
To: 
References: <20121220212915.29989.69859.idtracker@ietfa.amsl.com>
In-Reply-To: <20121220212915.29989.69859.idtracker@ietfa.amsl.com>
Date: Thu, 20 Dec 2012 21:38:53 -0000
Message-ID: <02f801cddefa$686656a0$393303e0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-language: en-gb
Thread-index: AQI4bKtYTEUxoZpUt6V4j7Lr60/PSJdNG2oA
Subject: [Roll] FW: IESG Approval of Code point Allocation
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 21:38:59 -0000

FYI

> -----Original Message-----
> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf =
Of IESG
> Secretary
> Sent: 20 December 2012 21:29
> To: iana@iana.org
> Cc: iesg@ietf.org
> Subject: IESG Approval of Code point Allocation
>=20
> IANA,
>=20
> The IESG has approved a code point allocation as below. Please =
allocate the code
> point.
>=20
> Best regards,
> IESG Secretary
>=20
> =3D=3D
>=20
> Registry:
> Internet Protocol Version 6 (IPv6) Parameters
>=20
> Sub-Registry:
>=20
> URL:
> =
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml#ipv6-=

> parameters-2
>=20
> Registration Procedures Allowed:
> IESG Approval, IETF Consensus or Standards Action
>=20
> Registration Procedures Used:
> IESG Approval
>=20
> Registration to Make:
> Hex value: TBD derived from the following (suggested value 0x4D)
> Binary value act: 01
> Binary value chg: 0
> Binary value rest: TBD (suggested value 01101)
> Description: Trickle Multicast Option
> Reference: draft-ietf-roll-trickle-mcast
>=20
> Additional notes:
> The Roll working group will update the I-D to specifically note this
> assignment so that the reference can be updated when the document is
> made into an RFC. Please also see Adrian Farrel's previous email with
> subject "Bug in registry for IPv6 Hop-by-Hop options."


From mcr@obiwan.sandelman.ca  Fri Dec 21 09:42:46 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5C921F86A1 for ; Fri, 21 Dec 2012 09:42:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKc7CUDMZutS for ; Fri, 21 Dec 2012 09:42:46 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 8914D21F8652 for ; Fri, 21 Dec 2012 09:42:46 -0800 (PST)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8340020170 for ; Fri, 21 Dec 2012 12:45:57 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id DFFC4636C4; Fri, 21 Dec 2012 12:42:06 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D19E5636C3 for ; Fri, 21 Dec 2012 12:42:06 -0500 (EST)
From: Michael Richardson 
To: roll@ietf.org
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Sender: mcr@obiwan.sandelman.ca
Subject: [Roll] start of Working Group Last Call (WGLC) on draft-ietf-roll-terminology
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 17:46:06 -0000

The document
  https://datatracker.ietf.org/doc/draft-ietf-roll-terminology

was always intended to be published as an Informational RFC along with
RFC6550, but it fell between the cracks.

This became obvious when other working groups tried to reference it.

I am starting a Working Group Last Call on this document.
We have had significant discussion of this document in 2010 and 2011.

Version 07 was posted, some minor revisions produced version 08.

Given that there are seasonal holidays starting, I am setting this
WGLC to end two weeks from Dec. 31, so for Monday 2013-01-14.

I do not believe that there is anything controversial about this document.

If you have comments on this document, please post them to this list.

-- 
Michael Richardson , Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


From mcr@sandelman.ca  Fri Dec 21 11:55:23 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B206521F8B0C for ; Fri, 21 Dec 2012 11:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMPpMXoGAhyS for ; Fri, 21 Dec 2012 11:55:23 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 1876421F8816 for ; Fri, 21 Dec 2012 11:55:23 -0800 (PST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C016F20170 for ; Fri, 21 Dec 2012 14:58:35 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id CADA7636C4; Fri, 21 Dec 2012 14:54:44 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B871F636BC for ; Fri, 21 Dec 2012 14:54:44 -0500 (EST)
From: Michael Richardson 
To: roll@ietf.org
In-Reply-To: <50A505AC.2000200@gridmerge.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org>  <50932647.3050509@exegin.com>  <5094202F.4010805@exegin.com>  <509C03C2.50809@exegin.com>  <509C5F00.2050204@exegin.com> <509D5AF5.4040304@exegin.com> <509DAFEF.5020504@exegin.com> <9143.1352758442@sandelman.ca> <50A382DA.9030706@gridmerge.com> <2150.1352927633@obiwan.sandelman.ca> <50A505AC.2000200@gridmerge.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 21 Dec 2012 14:54:44 -0500
Message-ID: <21507.1356119684@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 19:55:23 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


(It has come to my attention that additional spam filtering @ietf.org
was dropping many of my emails, this is a resend)

>>>>> "Robert" =3D=3D Robert Cragie  writes:
    Robert>  Almost there. In the case of forwarding using MPL
    Robert> domain (subnet-local) mc address, the inner packet is
    Robert> strictly tunnelled, i.e. there will be no hop count
    Robert> decrementing per hop. I discussed this offline with Jonathan

okay, and this is because the packet is in a tunnel, which is not
addressed to the "link", so in effect, it is not a local packet.

I can buy this, and so #3 does not decrement, while #4 does.

What is the use case for #3 and what is the use case for #4?
What I'm trying to get at here is: what is the argument to have both?

Who is going to need each one?

On 14/11/2012 9:13 PM, Michael Richardson wrote:
> Robert, has written 3 rules about when to encapsulate, and how to
> recognize the MPL domain.  With two options #3 and #4.
>
> the difference is  (#3):
>
>>     2. Outer header will have subnet-local mc address (e.g.
>>        FF03-based). This can be used to control propagation in
>>        conjunction with the MPL option.
> vs (#4)
>
> <    2. Outer header will have link-local mc address (e.g. FF02-based).
> <       This cannot be used to control propagation as it only goes one
> <       hop; the MPL option is used alone
>
> and as far as I can understand in both cases MPL forwarders will
> decapsulate and re-encapsulate, thus decrementing the inner TTL each
> time.   Or did I misunderstand here?





=2D-=20
Michael Richardson , Sandelman Software Works=20
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUAUNS+hIqHRg3pndX9AQL1swQAvvD2cQdYbh9UND27oOudEv7Xg0Ju0PjP
HAUorJl3TUAIrTLYvXrF18XruzuOWkHtxPToiWBzZxSLRbuILWEW4ynqgNhUofnx
lt8IkkTNZ5cwTomdOaWQ8JJJKkDj7l5hk69WUHsAMOvq1zgBoeRIJfiTgWpRkUaS
PKNiIbKHqYM=
=XiSn
-----END PGP SIGNATURE-----
--=-=-=--

From internet-drafts@ietf.org  Sun Dec 23 17:38:37 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BA721F882A; Sun, 23 Dec 2012 17:38:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juk7Hf+pEIo6; Sun, 23 Dec 2012 17:38:37 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3E221F88CF; Sun, 23 Dec 2012 17:38:36 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.37
Message-ID: <20121224013836.23894.72652.idtracker@ietfa.amsl.com>
Date: Sun, 23 Dec 2012 17:38:36 -0800
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-07.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Dec 2012 01:38:37 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Over Low power and Lossy networks=
 Working Group of the IETF.

	Title           : A Mechanism to Measure the Routing Metrics along a Point=
-to-point Route in a Low Power and Lossy Network
	Author(s)       : Mukul Goyal
                          Emmanuel Baccelli
                          Anders Brandt
                          Jerald Martocci
	Filename        : draft-ietf-roll-p2p-measurement-07.txt
	Pages           : 25
	Date            : 2012-12-23

Abstract:
   This document specifies a mechanism that enables an RPL router to
   measure the aggregated values of given routing metrics along an
   existing route towards another RPL router in a low power and lossy
   network, thereby allowing the router to decide if it wants to
   initiate the discovery of a better route.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-p2p-measurement-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-measurement-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From prvs=6982733d4=mukul@uwm.edu  Sun Dec 23 23:31:40 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34C021F88CF for ; Sun, 23 Dec 2012 23:31:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygm0rwHLzbeO for ; Sun, 23 Dec 2012 23:31:38 -0800 (PST)
Received: from ip3mta.uwm.edu (ip3mta.uwm.edu [129.89.7.192]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD6721F8846 for ; Sun, 23 Dec 2012 23:31:38 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0EAFAE2FB/AAAB/2dsb2JhbABEhjq3SIMYI0kNGxoCDRkCWQaIJqNCiHqJCYEiizoXgxSBEwOIYo0qkEiDE4ID
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id A55072E09FB; Mon, 24 Dec 2012 01:31:36 -0600 (CST)
X-Virus-Scanned: amavisd-new at 
Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6LacRnW65P7; Mon, 24 Dec 2012 01:31:36 -0600 (CST)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 2F9C02E09EB; Mon, 24 Dec 2012 01:31:36 -0600 (CST)
Date: Mon, 24 Dec 2012 01:31:36 -0600 (CST)
From: Mukul Goyal 
To: adrian  
Message-ID: <1880519187.229086.1356334295979.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <20121205130341.22852.76100.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: roll 
Subject: Re: [Roll] ID Tracker State Update Notice:	
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Dec 2012 07:31:40 -0000

Hi Adrian,

The new (07) version of the draft, modified based on your comments, has been posted. Please see my response to your comments below.

---------------------------------
[Adrian]

As with draft-ietf-roll-p2p-rpl, I would like some discussion in the
Introduction about why this Experimental and what you expect to
discover. I think the text is easier for this document...

   This document provides a mechanism that can be used to determine
   whether and how to establish a new point-to-point route in an LLN.
   This utility of the mechanism described in this document is, 
   therefore, dependent on the existence of a protocol mechanism for
   establishing P2P routes. [I-D.ietf-roll-p2p-rpl] is targeted at
   publication as an Experimental RFC for reasons described in that
   document. It makes sense, therefore, for this document also to be
   targeted as Experimental.

   As experience is gained using the mechanisms described in
   [I-D.ietf-roll-p2p-rpl] it is hoped that the mechanisms described in
   this document will also be used, and feedback will be provided to the
   ROLL working group on the utility and benefits of this document.

[Mukul]

Done. See the new text towards the end of Section 1.
--------------------------------------------------------

[Adrian]
I think that "quality" is the wrong word. "Quality" is usually
associated with measures like packet loss, delay, and jitter. I don't
think you are measuring those things, and while I understand why you
say "quality of a route", I think you need some other phrase.

I think this more like...

  A Mechanism to Record the end-to-end Metrics of a Point-to-point
             Route in a Low Power and Lossy Network

In the Introduction, you have some nice words...

   to measure
   the aggregated values of the routing metrics along the existing
   route

[Mukul]

The title has been changed to meet your concern.

----------------------------------------------

[Adrian]
Abstract

I'm confused :-)

The document title is very specific to P2P routes. But the Abstract 
(deliberately?) does not mention P2P. Section 1 seems to imply that I
could run the mechanisms on any route from origin to target to see if it
is good enough - and that would include routes created using normal RPL.
But section 2 explicitly constrains the mechanism to P2P routes.

Furthermore, the redefined terminology in 1.1 (see below for my 
objection to that!) seem to suggest measuring from an arbitrary origin
to an arbitrary target regardless of whether a P2P route exists.

Can you:
- unconfuse me
- make sure that the abstract and introduction explain the real
  situation
- make sure the document title is accurate
- make sure that the document is consistent
- be careful with terminology (just because you run the mechanism from
  A to B in a point-to-point sort of way, doesn't mean that there is a
  P2P route from A to B)

[Mukul]
We have already resolved this issue.

------------------------------------------------------
[Adrian]
1.1                    

Did you really need to redefine these terms instead of use new terms for
new concepts? Given how close the two documents are, it's a shame to 
confuse things.

[Mukul]

The draft is not using the "Origin/Target" terms any more. See the new terminology in Section 1.1. In addition to defining new terms (Start Point, End Point and Intermediate Point), I have (re)defined two terms from p2p-rpl (Forward direction, Backward direction). These terms occur a few times in the draft.
------------------------------------------------
[Adrian]

3.1

I was going to say...

   Seems like the H flag is not needed since leaving it clear is 
   semantically equivalent to setting RPLInstanceID=0b10000000

   Not very important, but you increase the chances of a malformed 
   message, and you use your last bit that could be reserved for 
   future use.

...but then I read the text lower down about how a transit router
can change the H flag under special circumstances. Now I am confused
because if the H flag setting is changed, surely the rule governing 
the RPLInstanceID is broken.

[Mukul]
This was a bug in the previous version. The previous version required RPLInstanceID to be 0b10000000 if H = 0. But this causes RPLInstanceID (of a global non-storing DAG along which the Measurement Request had been traveling so far) to be lost whenever the root of this DAG switches the message to a Source Route towards the End Point. When this Measurement Request reaches the End Point, the End Point would not know which global DAG can be used to send Measurement Reply back to the Start Point. The new version corrects this bug. Now, the RPLInstanceID does not change even if the Measurement Request switches over to a Source Route. Now, only the H flag can correctly tell whether a Measurement Request is traveling over a Hop-by-hop Route or a Source Route.
------------------------------------------

[Adrian]
3.1

Some of the flag settings that have no meaning dependent on other
flag settings are described as "MUST be set to zero" which is fine.
But should you also say they should be ignored?

[Mukul]
I started taking care of this and ended up editing Sections on MO description (Section 3) and how to setup MO in various cases (Section 4) significantly. There is no semantic change in the contents (except for the correction of the bug involving RPLInstanceID value described previously). Hopefully the new sections are clearer than before. 

Section 5, detailing processing by an Intermediate Point, was edited to have same structure as Section 4. Additionally, I did one minor correction in Section 5:

"A router MUST discard a received MO with no further processing if the
   value in the Compr field inside the received message is "more than"
   what the router considers the length of the common prefix used in
   IPv6 addresses in the LLN to be.

Here "more than" was previously "not same as".

Section 6, detailing processing by the End Point, was also edited to make it clearer. 

-----------------------------------------

[Adrian]
3.1

I found the description of what goes in the Metric Container Options
inadequate. There should at least be a forward pointer to some section
that describes how this piece of the MO object is constructed, but some 
text would help as well.

[Mukul]
The Metric Container Option is described in RFC6550 whereas the routing metric objects are described in RFC6551. I have now included references to these two RFCs. Not sure if I should repeat what these RFCs describe. 
---------------------------------------------

[Adrian]
Section 4

   The Origin MUST discard the MO message if:

That reads a bit odd. Didn't the Origin just build the message? Why 
would it build a message and then discard it? Why not just not build a
bad message?

[Mukul]
Here the Start Point (Origin) discards the MO message because the next hop address has problems (it is either not on-link or not unicast or not in the same RPL domain). The Start Point may not know the next hop address ahead of time (e.g. when a hop-by-hop route is being measured). Or may be it knew the next hop address ahead of time (e.g. if a source route is being measured) but did not notice the problems this address has.
 
------------------------------------------------

[Adrian]

Section 5

   An Intermediate Router MUST discard the packet with no further
   processing if the received MO is not a Measurement Request.

For clarity and consistency with other paragraphs, can you add...

   i.e., if the T flag is not set to one.

[Mukul]
Done.
-------------------------------------------------------

[Adrian]
Section 7

   The Origin MUST discard the packet with no further processing ...
   ... if the Origin has no
   recollection of sending a Measurement Request with the sequence
   number listed in the received MO.

Trying to decide why that is a "MUST".
I guess there are some security/bug considerations.
But are you unduly limiting the Origin implementation to be required to
keep track of the MOs that it sends?

[Mukul]
I think the Start Point (previously Origin) does need to keep track of Measurement Requests it has sent. Otherwise, it becomes prone to attacks where a rogue node feeds it wrong information about the routing metric values along existing routes the Start Point uses.
-----------------------------------------------------

[Adrian]
Section 7

   The Origin MUST examine the routing metric objects inside the Metric
   Container options to evaluate the quality of the measured P2P route.
   If a routing metric object contains local metric values recorded by
   routers on the route, the Origin MUST aggregate these local values
   into an end-to-end value as per the aggregation rules for the metric.

That is going too far in the use of "MUST". The Origin can do anything 
it likes with the Measurement Reply including discard it, hash it and
use it as a random number, or process it according to policy! I think
what you need is...

   The Origin can use the routing metric objects inside the Metric
   Container to evaluate the metrics for the measured P2P route. If a
   routing metric object contains local metric values recorded by 
   routers on the route, the Origin can make use of these local values
   by aggregating them into an end-to-end metric according to the 
   aggregation rules for the specific metric. An Origin is then free to 
   interpret the metrics for the route according to its local policy.

[Mukul]

Done.
------------------------------------
[Adrian]

Section 8

Question. Can I use this mechanism to find out stuff about the network
that should/would otherwise be private? And could I, as an outside node
do that?

For example, if I sit next to the network and ping every possible P2P 
route, can I find out which nodes are almost out of battery, and which
nodes are key nodes in the topology? Knowing this would help me attack
the network. What are the protections?

[Mukul]

The Security Considerations now have some discussion about this. See the last paragraph in Section 8.

----------------------------------------

[Adrian]
11.2
You have used [I-D.ietf-roll-p2p-rpl] as a normative reference (at 
least for the terminology).

[Mukul]

I am no longer using Origin/Target terms. But now I have redefined two other terms from p2p-rpl: Forward direction and Backward direction. So, now this draft lists p2p-rpl as a normative reference.

------------------------------------------------

Thanks
Mukul