Hi Pascal, Assuming two 6BBR represent the same address, in the absence of primary/secondary concept, I see no issue in a node getting two NA or more (one per 6BBR) and selecting one o them. Or all of them, based on local policy (first one, higher mac, etc.). I actually see some advantage of this approach: the node receiving multiple NA from multiple 6BBR could replicate traffic to them to achieve some extra redundancy. On the other end, getting into the business of election to pick one 6BBR seems overkill, to say the least, and error prone. In short I concur with the proposal of dropping this primary/secondary concept. Eric
Many thanks Samita ! A comment was raised on the concept of primary and the authors would like to get A desirable feature is that an address can be proxied by more than one 6BBR. This provides load balancing and redundancy. The protocol is designed to recognize the situation and the 6BBRs do not fight with one another. Now, the question to the group is as follows: The draft has an optional support of primary whereby only one 6BBR will defend the address on the backbone. This avoids getting a proxied NA from more than one 6BBR when looking up a 6LN from the backbone. But then, the election of a primary is additional burden for the implementation and we are not 100% clear on what technique to use, and how efficient it could be. At worse, if the primary election fails and all think that another is primary, then the address will not be proxied. Currently we pick the highest address which seems to avoid that pitfall. There is a suggestion to use the first registration, but that may be hard to decide with certainty and race conditions may lead to the problem above. The Occam razor seems to indicate that we should not elect a primary and we should let all the 6BBRs with a same registration (same address, same TID and same ROVR) defend the address in parallel. What do people think? Pascal From: 6lo <[email protected]> On Behalf Of Chakrabarti, Samita Sent: jeudi 17 janvier 2019 00:32 To: [email protected] Subject: [6lo] WG Last Call: draft-ietf-6lo-backbone-router-10.txt draft-ietf-6lo-backbone-router version 10 has been published and the co-authors informed the chairs that it is now ready for WGLC . The working group LC starts on January 17, 2019 and ends on January 25, 2019. Please provide your comments and suggestions by January 25th for improvement of this document for the next step. Thanks, -Samita ---------- Forwarded message --------- From: <[email protected]<mailto:[email protected]>> Date: Wed, Jan 16, 2019 at 8:30 AM Subject: [E] [6lo] I-D Action: draft-ietf-6lo-backbone-router-10.txt To: <[email protected]<mailto:[email protected]>> Cc: <[email protected]<mailto:[email protected]>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes WG of the IETF. Title : IPv6 Backbone Router Authors : Pascal Thubert Charles E. Perkins Eric Levy-Abegnoli Filename : draft-ietf-6lo-backbone-router-10.txt Pages : 29 Date : 2019-01-16 Abstract: This document updates RFC 4861 and RFC 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called Backbone Routers. Backbone Routers are placed along the wireless edge of a Backbone, and federate multiple wireless links to form a single MultiLink Subnet. The IETF datatracker status page for this draft is: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2D6lo-2Dbackbone-2Drouter_&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=JaDw7ER1phATcBhGoszd29DcAXId_mR2BCGeDI_0ttE&s=GWKbMDabuwvcpugRfNrFqERsmUAwApI4iG84_5_uzfQ&e= There are also htmlized versions available at: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D6lo-2Dbackbone-2Drouter-2D10&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=JaDw7ER1phATcBhGoszd29DcAXId_mR2BCGeDI_0ttE&s=3N5L7W3Koq8vCf_hPAP2Csx-Pw0WHOGoDUxSYfRQeh8&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2D6lo-2Dbackbone-2Drouter-2D10&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=JaDw7ER1phATcBhGoszd29DcAXId_mR2BCGeDI_0ttE&s=4pYic66T8sdl6J0MHIiuNfsLprXq6V67uKiYVPT8HpY&e= A diff from the previous version is available at: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2D6lo-2Dbackbone-2Drouter-2D10&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=JaDw7ER1phATcBhGoszd29DcAXId_mR2BCGeDI_0ttE&s=v0JtuYSpw4LhaZOyZvVHMIwy3Ig0xJ7PZuieFmhCP_U&e= Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=JaDw7ER1phATcBhGoszd29DcAXId_mR2BCGeDI_0ttE&s=_502_Q_ZRV2gpti8C9-JxYWmY2x8cgvAQjclJWh24LE&e= _______________________________________________ 6lo mailing list [email protected]<mailto:[email protected]> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_6lo&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=JaDw7ER1phATcBhGoszd29DcAXId_mR2BCGeDI_0ttE&s=sPzuVAZdPg1MKnApmClhRVnWnXrtbhLwrUN5tlpxD5M&e=
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
