Loading ...
Sorry, an error occurred while loading the content.

347RE: [bacnet-ip-wg] New file uploaded to bacnet-ip-wg

Expand Messages
  • Isler, Bernhard
    Jan 9, 2013
    • 0 Attachment

      My replies below.

       

      Bernhard

       

       

      Bernhard Isler

      Siemens Switzerland Ltd
      Building Technologies Division

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Carl Neilson
      Sent: Wednesday, January 09, 2013 3:43 PM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: RE: [bacnet-ip-wg] New file uploaded to bacnet-ip-wg

       

       

      My opinion on some of the recent comments:

       

      BI-10: Akin to IPv4 sockets, if the implementation does not have information on which local IPv6 address the message was received on, the destination virtual address can be used to distinguish the target. It also allows for detection of problems with the address resolution (is this vmac even valid for the receiving device?)

      [BI] Agree with these use cases.

       

      BI-18: I disagree with the comment. In a forwarded packet, the original VMAC is from the “other” BBMD or foreign device, not from the device that generated the packet itself. In this way it differs from an Original-Unicast packet and thus the moniker ‘Original’ on the parameter provides clarity, as it did in IPv4.

      [BI] OK

       

      BI-20: This message is used when the application has an IPv6 address but does not have the associated virtual MAC address, such as would occur when a device is located via DNS.

      [BI] OK, Sounds to be a reasonable use case. Some respective language may help.

       

      BI-21: The parameter is provided for those implementations that cannot determine which local address a message is received on as it was in IPv4.

      [BI] Given the above use case, OK.

       

      BI-22: Yes.

       

      BI-24: I don’t believe that there is any case where the NPDU portion would be missing. This level of description is identical to what was present in the IPv4 case. What extra information is needed?

      [BI] Sorry, the comment is placed wrong, thanks to Word. The comment is on something missing after the parameter list. In other messages, there is usually some language talking about how and when the BVLC message is used.

       

      BI-32: The unassigned entries are not needed, but the reserved entry should be included for clarity.

      [BI] OK.

       

      BI-34: Is the address scope of the multi-cast address not defined in the address itself which is taken from the NP object? Also, requiring global scope on the multi-cast violates the position we have held that we cannot rely on global scope multi-casts working and that we need BBMDs (is it not the BBMD that takes a multi-cast and makes it “global” in scope?) If we do require something other than lin k-local, there is language that would need to be changed in the preceding paragraph indicating link-local as the minimum requirement.

      [BI] This is on the source address, which is not a multicast address. The problem here is that the message may be forwarded by a BBMD into some other scope. How would a response be returned to the original sender, if the sender used a limited scope source address whose scope is invalid at the responder? E.g. the sender selected a link-local scope source address, because the BBMD is on the local link. It appears to be default IPv6 stack behavior to select the smallest scope source address. The BBMD then forwards the request to some other BBMD on another link. On that link, the Original-Source-B-IPv6-Address is not valid and cannot be used to return a response! Given this, the source address must have some larger scope, to allow the responder to use the Original-Source-B-IPv6-Address. Or, the Original-Source-B-IPv6-Addressis not used by the responder and a VMAC resolution of the source VMAC is done before sending back a response.

       

      In the TODO list, we are missing:

      -          Fill in paragraphs on VMAC table 4.5.2 / 4.5.3

       

       

      Carl


      Carl Neilson

      Chair, ASHRAE SSPC 135 (aka The BACnet Committee)

      direct:   +1.604.575.5913

       

       

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
      Sent: Wednesday, January 09, 2013 7:49 AM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: [bacnet-ip-wg] New file uploaded to bacnet-ip-wg

       

       


      Hello,

      This email message is a notification to let you know that
      a file has been uploaded to the Files area of the bacnet-ip-wg
      group.

      File : /Add. AJ/Add-135-2010aj-APR3-Draft-11-BI.doc
      Uploaded by : bi71259 bernhard.isler@...>
      Description : Rev 11 Commented

      You can access this file at the URL:
      http://groups.yahoo.com/group/bacnet-ip-wg/files/Add.%20AJ/Add-135-2010aj-APR3-Draft-11-BI.doc

      To learn more about file sharing for your group, please visit:
      http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.html
      Regards,

      bi71259 bernhard.isler@...>


    • Show all 52 messages in this topic