[6lo] Re: Call for WG adoption of draft-iannone-6lo-nd-gaao-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Dear all,

I support this adoption because this solution provide proper extensibility to 
new abilities in 6lo ND.

Regards,
Guangpeng

From: Carles Gomez Montenegro 
Sent: Tuesday, September 3, 2024 1:59 PM
To: 6lo@ietf.org
Subject: [6lo] Call for WG adoption of draft-iannone-6lo-nd-gaao-03

Dear 6lo WG,

In IETF 120 (Vancouver), the authors of draft-iannone-6lo-nd-gaao-03 [1] 
requested WG adoption. There was good in-room consensus in favor of adoption 
[2].

This message initiates a call for WG adoption of draft-iannone-6lo-nd-gaao-03.
The call will end on the 17th of September, EOB.

Please state whether you are in favor of adopting this document.

Also, any comments you may have, and/or expressions of interest to review
the document, will be very much appreciated.

Thanks,

Shwetha and Carles

[1] https://datatracker.ietf.org/doc/draft-iannone-6lo-nd-gaao
[2] https://datatracker.ietf.org/doc/minutes-120-6lo

[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-green-avg-v1.png]

Libre de 
virus.www.avg.com


___
6lo mailing list -- 6lo@ietf.org
To unsubscribe send an email to 6lo-le...@ietf.org

Re: [6lo] Call for WG adoption of draft-li-6lo-path-aware-semantic-addressing-01

[Liguangpeng (Roc, Network Technology Laboratory)]

Dear 6lo WG,

I sincerely appreciate the help from 6lo community and present my support to 
the adoption of this draft. Welcome more experts help to review it and enhance 
its quality.

Kind Regards,
Guangpeng Li

From: 6lo <6lo-boun...@ietf.org> On Behalf Of Carles Gomez Montenegro
Sent: Wednesday, January 25, 2023 9:50 PM
To: 6lo@ietf.org
Subject: [6lo] Call for WG adoption of 
draft-li-6lo-path-aware-semantic-addressing-01

Dear 6lo WG,

As you may recall, the work formerly known as 'NSA' has been modified based on 
the feedback provided by the WG. The work has also been renamed as Path-Aware 
Semantic Addressing (PASA).

The initial version of the PASA draft was presented in IETF 115. The draft has 
been updated to address the comments received. After that, the authors have 
requested a call for adoption of the draft.

This message starts a call for WG adoption for
draft-li-6lo-path-aware-semantic-addressing-01.

(Link below:
https://datatracker.ietf.org/doc/html/draft-li-6lo-path-aware-semantic-addressing-01)

The call will end on the 8th of February 23:59 (UTC).

Please state whether you are in favor of adopting this document.

Also, any comments you may have, and/or expressions of interest to review
the document, will be very much appreciated.

Thanks,

Shwetha and Carles
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for 6lo wg adoption - draft-gomez-6lo-schc-15dot4

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi all,

I support the adoption of this work in 6lo and glad to see further coordination 
work with related WGs.

Regards,
Guangpeng Li

From: 6lo <6lo-boun...@ietf.org> On Behalf Of Shwetha
Sent: Wednesday, December 7, 2022 2:48 PM
To: 6lo@ietf.org
Cc: 6lo-cha...@ietf.org
Subject: [6lo] Call for 6lo wg adoption - draft-gomez-6lo-schc-15dot4

Dear 6lo wg,


As per discussion during IETF 115, this message initiates a 2 week 
call-for-adoption for: 
https://datatracker.ietf.org/doc/draft-gomez-6lo-schc-15dot4/

(currently at rev 5)

Please send your opinion (for or against) to the mailing list on adopting

this  document as a 6lo WG document.



This call for adoption will end at 00:00 UTC on December 21, 2022.



Thanks,

Shwetha (as Carles is the co-author of the draft)
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Hello Pascal,

We still believe NSA is IP address. For details, please see response inline.

Regards,
Guangpeng

> -Original Message-
> From: Pascal Thubert (pthubert) 
> Sent: Wednesday, August 24, 2022 1:17 PM
> To: Liguangpeng (Roc, Network Technology Laboratory)
> 
> Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of 
> draft-li-6lo-native-short-address-03
> 
> Hello Guangpeng
> 
> I tried and failed so far to convince you that NSA is not by nature an IP 
> address
> as we are used to. In my book it sits at L2 or L2.5 (with BIER and MPLS).
> 
> Consider this:
> 
> - if it was an IID how many devices max could there be in a subnet ?
> 
>  This is very limited not at all the traditional order of IPv6. Also it seems 
> to
> depend on the shape of the network. IP should not be impacted by L2
> considerations.
> 
NSA is not impacted by any L2 techniques. It works on various L2 wireline 
technologies. So far we designed allocation function base on the tree topology, 
which we believe can be applied to many scenarios.

> - NSA expresses a source route path not a destination.
> 
>  In that it is akin to an MPLS stack.
> 
NSA indeed encodes path information into the address which greatly reduce 
complexity of routing, hence an advantage of solution.

> - what if I swap the device at the end of the path?
> 
> Traditional IP expects that a device can retain its address even if it is 
> plugged on
> a different switch port.
> 
As long as the parent node stays the same, NSA can also retain the child's node 
address when it swaps.

> - what if there are multiple paths to the same device (again the point on
> redundancy)?
> 
We have two solutions illustrated in the reliability draft, please comment more 
on that.

> So if you told me that you are shooting for IP in IP and that NSA is for the
> destination in the outer header I’d be rather easy to convince. That would
> become another variation of an SRv6 compression technique. I’d then suggest
> you present it at spring.
> 
> If you told me it is a L2 or L2.5 mesh under technique I’d also listen 
> carefully.
> The debate would become whether 6lo is home for the work.
> 
> But sorry I cannot see that NSA matches an IP address. That would fuse the
> devices and the network together.
> 
> Regards,
> 
> Pascal
> 
> > Le 24 août 2022 à 06:36, Liguangpeng (Roc, Network Technology
> Laboratory)  a écrit :
> >
> > Hi Michael,
> >
> > That's great. Considering NSA lives with IPv6 space, there is very low
> probability for the new device cannot get an address. I think we are aligned
> with each other on supporting IPv6 in the first place.
> >
> > Cheers,
> > Guangpeng
> >
> >> -Original Message-
> >> From: Michael Richardson 
> >> Sent: Wednesday, August 24, 2022 12:00 AM
> >> To: Liguangpeng (Roc, Network Technology Laboratory)
> >> 
> >> Cc: 6lo <6lo@ietf.org>
> >> Subject: Re: [6lo] Call for WG adoption of
> >> draft-li-6lo-native-short-address-03
> >>
> >>
> >> "Liguangpeng (Roc, Network Technology Laboratory)" wrote:
> >>>>> No, as long as there is enough address for this new device.
> >>>>
> >>>> And if there isn't?
> >>
> >>> What happens if you want add the 256th device to a subnet with /24
> >> IPv4
> >>> address block?
> >>
> >> I was a fool to have no used IPv6 in the first place.
> >>
> >> --
> >> Michael Richardson. o O ( IPv6 IøT
> consulting )
> >>   Sandelman Software Works Inc, Ottawa and Worldwide
> >>
> >>
> >>
> >
> > ___
> > 6lo mailing list
> > 6lo@ietf.org
> > https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi Michael,

I am still not sure what's the concrete problem on wires cause by NSA. I saw 
tons of cables connect industry instrument to DCS (controllers used in process 
industry) in a chemical plant last week. I don't claim the NSA is suitable for 
that case, just show the most complexity of wiring I have ever seen in network 
till now. I am pleasure to discuss with you on this if you are interested. 
Maybe we should start private conversation or another thread in ML.

Thank you for providing extra information around.

Best Regards,
Guangpeng

> -Original Message-
> From: Michael Richardson 
> Sent: Wednesday, August 24, 2022 12:02 AM
> To: Liguangpeng (Roc, Network Technology Laboratory)
> 
> Cc: Pascal Thubert (pthubert) ; 6lo
> <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of 
> draft-li-6lo-native-short-address-03
> 
> 
> "Liguangpeng (Roc, Network Technology Laboratory)" wrote:
> mcr> no, what you suggest is weird.  More cables and more tangles.  (I
> mcr> still operate systems in cabinets in data centres)
> 
> > Are you still discussing about renumbering? A little confusing.
> 
> I'm saying that I have active, physical, hands-on experience with cabinets in
> data centers today.
> 
> I have doubts that I could wire NSA correctly, and I'm certain that I 
> wouldn't be
> able to get the people that do work for me to get it right.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi Michael,

That's great. Considering NSA lives with IPv6 space, there is very low 
probability for the new device cannot get an address. I think we are aligned 
with each other on supporting IPv6 in the first place.

Cheers,
Guangpeng

> -Original Message-
> From: Michael Richardson 
> Sent: Wednesday, August 24, 2022 12:00 AM
> To: Liguangpeng (Roc, Network Technology Laboratory)
> 
> Cc: 6lo <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of 
> draft-li-6lo-native-short-address-03
> 
> 
> "Liguangpeng (Roc, Network Technology Laboratory)" wrote:
> >> > No, as long as there is enough address for this new device.
> >>
> >> And if there isn't?
> 
> > What happens if you want add the 256th device to a subnet with /24
> IPv4
> > address block?
> 
> I was a fool to have no used IPv6 in the first place.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi Pascal,

There is really misunderstanding here. I'll add explanation inline.

Best Regards,
Guangpeng

> -Original Message-
> From: Pascal Thubert (pthubert) 
> Sent: Tuesday, August 23, 2022 3:15 PM
> To: Liguangpeng (Roc, Network Technology Laboratory)
> ; Pascal Thubert (pthubert) 
> Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> Subject: RE: [6lo] Call for WG adoption of 
> draft-li-6lo-native-short-address-03
> 
> Hello again Guangpeng
> 
> Seems that Michael and myself miss something in the address assignment then.
> Maybe some text will help the next readers avoid that misunderstanding.
> 
> Say you have this(fig 3 + some nodes)
> 
> 
> root   +--+
>  1 | append more bits to form
> |
>  O +   | brother's address
> |
>   /  |  \   \  +--+
>  /   |   \\
> /|\ \   \
>  +-+  /  | \  \   \
>  |forwarder| 10 /   11   110\   \  111 \ XXX
>  |node |  O -O   OO  O
>  +-+/ |\ \   | \  | \
>   /   | \  \ |  \ |  \
> / |  \\  O   OO   O
>   /   |\\
>   100/1010|   101   1011  +--+
> O O  O  O  |Prefix is '10'|
>/|/|+--+
>   / |   / |
>  O  O  O  O
>   1001 10011 10101 101011
> 
> 
> And you add a core switch attached to root (XXX in the picture). How would
> you name it? I guessed 1110 because that's what would happen if XXX was
> present at the very initial time.
Yes, correct. As per Figure 4 in the draft.

> But when XXX is finally installed, 111 must already have a child, otherwise 
> why
> should it be there? That child is already 1110, and then there's  etc...
111 is a leaf address, which mean there cannot be child address at any time. In 
other words, nodes (except root) with address ending with '1' must have no 
subtree. So 1110 is must not child of 111, it only can be child of '1'(the 
root). We gave concrete example in the draft to explain how figure 4's 
algorithm works. See Page 8-9.

> 
> So we have a collision for 1110. I (and I suspect Michael too) expected
> renumbering so you get the same addresses whether XXX is plugged at T=0 or
> later in the life of the network.
> If you have a different plan please document it.

As clarified as above, there wouldn't be collision any more.
> 
> Now, say that for operational issues you need to unplug 1011 from 10 and plug
> it to 11. Again, from my reading that's renumbering. What's the plan to avoid
> it?
> 
This is a reasonable case, but the target new parent is surely not 11. But it 
may be 110. We have moved solution of this case to another draft, see section 
3.2 in https://datatracker.ietf.org/doc/draft-li-nsa-reliability/ . We expect 
people to input concrete requirements that cause topology change and make the 
solution work for that.

> All the best,
> 
> Pascal
> 
> 
> 
> > -Original Message-
> > From: 6lo <6lo-boun...@ietf.org> On Behalf Of Liguangpeng (Roc,
> > Network Technology Laboratory)
> > Sent: lundi 22 août 2022 11:04
> > To: Pascal Thubert (pthubert) 
> > Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> > Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-
> > address-03
> >
> > Hello Pascal,
> >
> > Please see inline.
> >
> > Best Regards,
> > Guangpeng
> >
> > > -Original Message-
> > > From: Pascal Thubert (pthubert)
> > > 
> > > Sent: Monday, August 22, 2022 2:18 PM
> > > To: Liguangpeng (Roc, Network Technology Laboratory)
> > > 
> > > Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> > > Subject: Re: [6lo] Call for WG adoption of
> > > draft-li-6lo-native-short-address-03
> > >
> > > Hello Guangpeng
> > >
> > > If we take the DC sensors as use case and racks are organized in
> > > trees, and you add a new rack then there will be renumbering.
> >
> > No, it doesn't. Just attach this new rack to existing racks and don't
> > move existing racks to this new rack meanwhile. The latter action is
> > weird and superfluous.
> >
> > >
> >

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi Pascal, 

As you raised before, the redundancy in network is a significant case for the 
addressing to solve. That's why we wrote another separate draft to discuss this 
in IETF 114. Multiple L2 MAC addresses may be a solution, but I can not see the 
whole view of it now.

I also support a permanent address perspective. The NSA is only an alternative 
to 'freely assigned IPv6 and compression after assign'. Both freely assigned 
IPv6 and IPv6 derived from NSA can be permanent identifier for a node. The 
difference is routing like mechanisms are need for NSA only when the topology 
changes. Comparison to it, routing is necessary all the time for freely 
assigned IPv6.

So I'd like to think NSA is an option to optimize LOWPAN work, especially when 
the topology is relatively stable.

Cheers,
Guangpeng

> -Original Message-
> From: Pascal Thubert (pthubert) 
> Sent: Tuesday, August 23, 2022 4:34 AM
> To: Liguangpeng (Roc, Network Technology Laboratory)
> 
> Cc: Pascal Thubert (pthubert) ; Michael Richardson
> ; 6lo <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of 
> draft-li-6lo-native-short-address-03
> 
> You read me wrong Guangpeng.
> 
> I’m advocating for multiple NSA L2 addresses to reflect redundancy in the
> network.
> 
> And a single IP address that remains even if the network changes and maps all
> the MAC addresses.
> 
> The consequence is that the IP must not derive from MAC.
> 
> 
> Though I agree with Michael that privacy for Ring’s case may not be an issue,
> the device needs a permanent address and that cannot be one that depends
> on the current topology.
> 
> 
> Regards,
> 
> Pascal
> 
> > Le 22 août 2022 à 11:04, Liguangpeng (Roc, Network Technology
> Laboratory)  a écrit :
> >
> > Hello Pascal,
> >
> > Please see inline.
> >
> > Best Regards,
> > Guangpeng
> >
> >> -Original Message-
> >> From: Pascal Thubert (pthubert) 
> >> Sent: Monday, August 22, 2022 2:18 PM
> >> To: Liguangpeng (Roc, Network Technology Laboratory)
> >> 
> >> Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> >> Subject: Re: [6lo] Call for WG adoption of
> >> draft-li-6lo-native-short-address-03
> >>
> >> Hello Guangpeng
> >>
> >> If we take the DC sensors as use case and racks are organized in
> >> trees, and you add a new rack then there will be renumbering.
> >
> > No, it doesn't. Just attach this new rack to existing racks and don't move
> existing racks to this new rack meanwhile. The latter action is weird and
> superfluous.
> >
> >>
> >> This is why it’s safer to use this tech at L2. For the better and the
> >> worse IoT standards happen to use the IP address as a node ID. I was
> >> there when ISA 100 made that decision and I understand why. I see the
> >> same arguments applying in list constrained environments.
> >>
> >> Now say that NSA is an L2 address or an L2.5 address. You get
> >> redundancy by allowing a node to have more than one L2 address.
> >> Renumbering is OK by reassigning Mac/IP matches - though it has to be
> >> done carefully/transactional my as MACs are reassigned.
> >>
> > This is why the NSA mechanism try hard to avoid renumbering even sacrifice
> the applicability of basic mechanism in wireless network. Here, NSA is part of
> IPv6, hence it indeed a L3 address. So, I can not understand why NSA would
> map to multiple L2 addresses.
> >
> >> Do it at L3 and you’re screwed.
> >>
> > BTW, I think derive IPv6 from L2 is not a reliable assumption considering
> privacy issues and fake MAC problems. This is why we need develop a short L3
> address in 6lo.
> >>
> >> Regards,
> >>
> >> Pascal
> >>
> >>> Le 22 août 2022 à 04:37, Liguangpeng (Roc, Network Technology
> >> Laboratory)  a écrit :
> >>>
> >>> Hi Michael,
> >>>
> >>> Thanks for the clarification. Please see below:
> >>>> If I insert a new device in the tree, then all of the tree below
> >>>> that device has to renumber.
> >>> Technically saying, it may exist but it seems weird to insert a new
> >>> device in
> >> the middle of the tree. When a user wants a new device, a normal way
> >> is append them to the network at the end of an existing rank.
> >> Totally, you mentioned a topology change manually, for which we put a
> >> sentence in Section 9 of the draft to hightlight this consideration.
> >>>
> >>>> I also

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

> -Original Message-
> From: Michael Richardson 
> Sent: Monday, August 22, 2022 11:44 PM
> To: Liguangpeng (Roc, Network Technology Laboratory)
> 
> Cc: Pascal Thubert (pthubert) ; 6lo
> <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of 
> draft-li-6lo-native-short-address-03
> 
> 
> "Liguangpeng (Roc, Network Technology Laboratory)" wrote:
> >> -Original Message- From: Pascal Thubert (pthubert)
> >>  Sent: Monday, August 22,
> 2022
> >> 2:18 PM To: Liguangpeng (Roc, Network Technology Laboratory)
> >>  Cc: Michael Richardson
> >> ; 6lo <6lo@ietf.org> Subject: Re: [6lo] Call
> >> for WG adoption of draft-li-6lo-native-short-address-03
> >>
> >> Hello Guangpeng
> >>
> >> If we take the DC sensors as use case and racks are organized in
> >> trees, and you add a new rack then there will be renumbering.
> 
> > No, it doesn't. Just attach this new rack to existing racks and don't
> > move existing racks to this new rack meanwhile. The latter action is
> > weird and superfluous.
> 
> no, what you suggest is weird.
> More cables and more tangles.
> (I still operate systems in cabinets in data centres)
> 
Are you still discussing about renumbering? A little confusing.

> >> Do it at L3 and you’re screwed.
> >>
> > BTW, I think derive IPv6 from L2 is not a reliable assumption
> > considering privacy issues and fake MAC problems. This is why we need
> > develop a short L3 address in 6lo.
> 
> Given a wired situation of sensors in a data center, I have no privacy 
> concerns.
> If we are talking about 100baseT1, then I also have no concern with packet
> size.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

> -Original Message-
> From: Michael Richardson 
> Sent: Monday, August 22, 2022 11:41 PM
> To: Liguangpeng (Roc, Network Technology Laboratory)
> 
> Cc: 6lo <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of 
> draft-li-6lo-native-short-address-03
> 
> 
> "Liguangpeng (Roc, Network Technology Laboratory)" wrote:
> > Thanks for the clarification. Please see below:
> >> If I insert a new device in the tree, then all of the tree below that
> >> device has to renumber.
> 
> > Technically saying, it may exist but it seems weird to insert a new
> > device in the middle of the tree.
> 
> Let's say that I have a device with four physical ports.
> Port 3 is being used to speak to the rank-1.
> Port 2 and Port 4 are being used to speak to downstream systems.
> Port 1 is empty.  New device goes on port 1.
> 
> Isn't that a renumber too?
> Maybe there was a device on port 1 before, and it was removed.
> 
Which device is renumbered you think in this scenario? According to NSA, the 
new device may get a new address that is different from removed port1's device 
(considering the address of original port1's device may have not been release 
yet). 

> > When a user wants a new device, a
> > normal way is append them to the network at the end of an existing
> > rank.
> 
> This is going to be a total fail once remote hands are involved.
> The only use case we have so far is sensors in a data center
> 
The sensors in DC scenario just makes the use case clear and concrete. It 
represents a range of use cases.

> >> I also think that it can happen if I add a new device to an existing
> >> rank.
> 
> > No, as long as there is enough address for this new device.
> 
> And if there isn't?
> 
What happens if you want add the 256th device to a subnet with /24 IPv4 address 
block?
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Hello Pascal,

Please see inline.

Best Regards,
Guangpeng

> -Original Message-
> From: Pascal Thubert (pthubert) 
> Sent: Monday, August 22, 2022 2:18 PM
> To: Liguangpeng (Roc, Network Technology Laboratory)
> 
> Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of 
> draft-li-6lo-native-short-address-03
> 
> Hello Guangpeng
> 
> If we take the DC sensors as use case and racks are organized in trees, and 
> you
> add a new rack then there will be renumbering.

No, it doesn't. Just attach this new rack to existing racks and don't move 
existing racks to this new rack meanwhile. The latter action is weird and 
superfluous. 

> 
> This is why it’s safer to use this tech at L2. For the better and the worse 
> IoT
> standards happen to use the IP address as a node ID. I was there when ISA 100
> made that decision and I understand why. I see the same arguments applying
> in list constrained environments.
> 
> Now say that NSA is an L2 address or an L2.5 address. You get redundancy by
> allowing a node to have more than one L2 address. Renumbering is OK by
> reassigning Mac/IP matches - though it has to be done carefully/transactional
> my as MACs are reassigned.
> 
This is why the NSA mechanism try hard to avoid renumbering even sacrifice the 
applicability of basic mechanism in wireless network. Here, NSA is part of 
IPv6, hence it indeed a L3 address. So, I can not understand why NSA would map 
to multiple L2 addresses.

> Do it at L3 and you’re screwed.
> 
BTW, I think derive IPv6 from L2 is not a reliable assumption considering 
privacy issues and fake MAC problems. This is why we need develop a short L3 
address in 6lo.
> 
> Regards,
> 
> Pascal
> 
> > Le 22 août 2022 à 04:37, Liguangpeng (Roc, Network Technology
> Laboratory)  a écrit :
> >
> > Hi Michael,
> >
> > Thanks for the clarification. Please see below:
> >> If I insert a new device in the tree, then all of the tree below that
> >> device has to renumber.
> > Technically saying, it may exist but it seems weird to insert a new device 
> > in
> the middle of the tree. When a user wants a new device, a normal way is
> append them to the network at the end of an existing rank. Totally, you
> mentioned a topology change manually, for which we put a sentence in
> Section 9 of the draft to hightlight this consideration.
> >
> >> I also think that it can happen if I add a new device to an existing rank.
> > No, as long as there is enough address for this new device.
> >
> > Cheers,
> > Guangpeng
> >
> >> -Original Message-
> >> From: Michael Richardson 
> >> Sent: Monday, August 22, 2022 12:07 AM
> >> To: Liguangpeng (Roc, Network Technology Laboratory)
> >> 
> >> Cc: Alexander Pelov ; 6lo <6lo@ietf.org>
> >> Subject: Re: [6lo] Call for WG adoption of
> >> draft-li-6lo-native-short-address-03
> >>
> >>
> >> "Liguangpeng (Roc, Network Technology Laboratory)" wrote:
> >>> Thanks for share of Carpenter's draft. I fully agree with the
> >>> content of it after a quick read. I think it's for all adoption
> >>> process, not only for this adoption call. I believe 6lo Chairs'
> >>> professional actions.
> >>
> >>> About the technical related concern:
> >>>> One concern that I have with NSA is that I think the network can
> >>>> get renumbered whenever there are new devices.
> >>
> >>> Can you explain a little more on how this problem happens?
> >>
> >> If I insert a new device in the tree, then all of the tree below that
> >> device has to renumber.
> >> I also think that it can happen if I add a new device to an existing rank.
> >>
> >>
> >> --
> >> Michael Richardson. o O ( IPv6 IøT
> consulting )
> >>   Sandelman Software Works Inc, Ottawa and Worldwide
> >>
> >>
> >>
> >
> > ___
> > 6lo mailing list
> > 6lo@ietf.org
> > https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi Michael,

Thanks for the clarification. Please see below:
> If I insert a new device in the tree, then all of the tree below that device 
> has to
> renumber.
Technically saying, it may exist but it seems weird to insert a new device in 
the middle of the tree. When a user wants a new device, a normal way is append 
them to the network at the end of an existing rank. Totally, you mentioned a 
topology change manually, for which we put a sentence in Section 9 of the draft 
to hightlight this consideration.

> I also think that it can happen if I add a new device to an existing rank.
No, as long as there is enough address for this new device.

Cheers,
Guangpeng

> -Original Message-
> From: Michael Richardson 
> Sent: Monday, August 22, 2022 12:07 AM
> To: Liguangpeng (Roc, Network Technology Laboratory)
> 
> Cc: Alexander Pelov ; 6lo <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of 
> draft-li-6lo-native-short-address-03
> 
> 
> "Liguangpeng (Roc, Network Technology Laboratory)" wrote:
> > Thanks for share of Carpenter's draft. I fully agree with the content
> > of it after a quick read. I think it's for all adoption process, not
> > only for this adoption call. I believe 6lo Chairs' professional
> > actions.
> 
> > About the technical related concern:
> >> One concern that I have with NSA is that I think the network can get
> >> renumbered whenever there are new devices.
> 
> > Can you explain a little more on how this problem happens?
> 
> If I insert a new device in the tree, then all of the tree below that device 
> has to
> renumber.
> I also think that it can happen if I add a new device to an existing rank.
> 
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi Michael,

Thanks for share of Carpenter's draft. I fully agree with the content of it 
after a quick read. I think it's for all adoption process, not only for this 
adoption call. I believe 6lo Chairs' professional actions. 

About the technical related concern:
> One concern that I have with NSA is that I think the network can get
> renumbered whenever there are new devices.

Can you explain a little more on how this problem happens?

Cheers,
Guangpeng

> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Michael Richardson
> Sent: Sunday, August 21, 2022 4:14 AM
> To: Alexander Pelov ; 6lo <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of 
> draft-li-6lo-native-short-address-03
> 
> 
> Alexander Pelov  wrote:
> > I'd be happy to discuss specific scenarios/use-cases that come from a
> > real-world need.
> 
> > In any case, I think these are required before accepting the draft as a
> > WG item.
> 
> Well, there really aren't any formal requirements to adopt a draft as a WG
> item.  It's a decision reserved for the WG chairs to make in any way that
> they see fit. Typically, they observe a consensus that the WG wants to work on
> it.
> That means that the WG is willing to spend agenda time on the document.
> 
> But, over time the Adoption call has become overly bureaucratic due to the
> belief that documents that are adopted MUST be published.  This has
> resulted in the adoption call being overly litigated.
> 
> See https://datatracker.ietf.org/doc/draft-carpenter-gendispatch-rfc7221bis/
> for some opinions and of course RFC7221.
> 
> However, like you, I am not feeling very confident that there are real use 
> cases,
> and that this document it not simply the result of researchers who looked at
> RFC6550, did a page count and decided it must be hard and that it shouldn't
> be so difficult, so let's invent something new, even though we have no actual
> use case.
> That is the research institute way, where success is measured in papers
> published, rather than products shipped.
> 
> This is not the IETF way.  The IETF way is to see that there is a problem that
> can not be solved with existing technology, write a paper about the failures 
> of
> the existing things, having tried them, and then do some experiments to see
> what else could be done.  Write some (running) code, do experiments and
> then report on it in an attempt to get rough consensus.
> 
> I've actually seriously considered the datacenter situation.  It's a core use 
> for
> ANIMA's ACP.  I can unicast some presentations, but I'm not sure that I want
> the links public yet.
> 
> I like the idea of an incrementally deployable swarm of management devices
> powered by the network.  I have been thinking about how to do PoE in/out
> in a daisy chain/tree. I hadn't thought about using the 100baseT1 that the
> automotive industry likes.
> 
> One concern that I have with NSA is that I think the network can get
> renumbered whenever there are new devices.
> 
> --
> Michael Richardson. o O ( IPv6 IøT
> consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Dear Alexander,


I think the use case document in 6lo is adequate to record the scenarios. (see 
4.1 in https://datatracker.ietf.org/doc/draft-ietf-6lo-use-cases/ ) . For 
instance, the real world use case provided by Rong Long earlier in ML should be 
included by “Smart thermostats, air conditioning, and heat controls” item.



BTW, the NSA solution employs LOWPAN compression with some adaption due to 
adopting native short address. So some scenarios for 6lo are the target of NSA.



There should be more opportunities to discuss how NSA document works in real 
world after it’s adopted as WG item. After all,  who will care about an 
individual draft how to be used even it had been presented four times in IETF 
meeting, right? :-)

Cheers,
Alexander

From: Alexander Pelov 
Sent: Saturday, August 20, 2022 9:05 PM
To: Liguangpeng (Roc, Network Technology Laboratory) 
Cc: 6lo <6lo@ietf.org>; Luigi IANNONE 

Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Dear Guangpeng,

Thanks for your reply!

I'll start with what I wrote earlier - it is important to define which 
scenarios/use-cases are the goal of this draft, and what are the benefits for 
these scenarios/use-cases.

The analysis you provide is interesting, but I cannot really connect it to the 
real deployment that is expected.

I'd be happy to discuss specific scenarios/use-cases that come from a 
real-world need.

In any case, I think these are required before accepting the draft as a WG item.

Thanks Guangpeng for your mail!
Cheers,
Alexander



On Sat, Aug 20, 2022 at 4:00 AM Liguangpeng (Roc, Network Technology 
Laboratory) mailto:liguangp...@huawei.com>> wrote:
Hi Alexander,

Thank you for reviewing our draft so detailed, it’s indeed helpful. Above 
Luigi’s reply, just complement some points on technical section.

About the address length, I think you fully understand this draft, and you 
should know that the average length of all packets’ header is significant, but 
not the longest ones. To demonstrate the average length of this draft, I made a 
presentation during IETF 
113(https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-native-short-address-for-lln-expansion-demo-00
 ). Hope this helps to understand.


About the inefficiency in your raised counter examples, that may be issues in 
wireless network due to lack of management of topology. For most of wired 
networks, administrators can plan the topology in advance according to scale of 
network(here tree topology is best for NSA). Even if the line topology is 
employed, the NSA approach can adopt suitable allocation function to achieve 
efficiency. In the draft, we only give the default allocation function in order 
to make the draft clear. But we leave a sentence to state “The Allocation 
Function can be different from the one defined in Figure 4, but all nodes know 
which one to use by configuration.  The use of one and only one AF is allowed 
in an NSA domain.” If the line topology is important and you are interested in 
this part, I am pleasure to collaborate with you on a new separate draft to 
standardize new allocation function.



Cheers,

Guangpeng

From: 6lo <6lo-boun...@ietf.org<mailto:6lo-boun...@ietf.org>> On Behalf Of 
Luigi IANNONE
Sent: Saturday, August 20, 2022 4:10 AM
To: Alexander Pelov mailto:a...@ackl.io>>; marinos charalambides 
mailto:marino...@gmail.com>>
Cc: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Hi Alexander,

Thanks for your feedback. Please send us the tons of questions you have we will 
do our best to answer them.

In general I think that the concerns that you are expressing can be solved 
during the normal life cycle of a draft as a WG item.

A few more specific comments inline.

Ciao

Luigi

From: 6lo <6lo-boun...@ietf.org<mailto:6lo-boun...@ietf.org>> On Behalf Of 
Alexander Pelov
Sent: Friday, 19 August 2022 17:03
To: marinos charalambides mailto:marino...@gmail.com>>
Cc: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Dear all,

I have a lot of questions and some serious issues with the applicability and 
the general description of the solution.
So, there are two reasons for which I am against adoption of this document.

Justification and use-case
In terms of the positioning of this draft and justification of the work, both 
6LoWPAN and SCHC are cited. Yet, the only justification of why this new work 
was proposed is "there could be more simplified solutions".
I'd say that firstly there is no proof in the draft that the proposed solution 
is simpler. As far as I can understand the draft, it is heavily underspecified, 
so knowing its full complexity is difficult at that time. Plus, what is 
"simpler"?

[LI] I agree that the text is unclear and misleading. We will revise this

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi Alexander,

Thank you for reviewing our draft so detailed, it’s indeed helpful. Above 
Luigi’s reply, just complement some points on technical section.

About the address length, I think you fully understand this draft, and you 
should know that the average length of all packets’ header is significant, but 
not the longest ones. To demonstrate the average length of this draft, I made a 
presentation during IETF 
113(https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-native-short-address-for-lln-expansion-demo-00
 ). Hope this helps to understand.


About the inefficiency in your raised counter examples, that may be issues in 
wireless network due to lack of management of topology. For most of wired 
networks, administrators can plan the topology in advance according to scale of 
network(here tree topology is best for NSA). Even if the line topology is 
employed, the NSA approach can adopt suitable allocation function to achieve 
efficiency. In the draft, we only give the default allocation function in order 
to make the draft clear. But we leave a sentence to state “The Allocation 
Function can be different from the one defined in Figure 4, but all nodes know 
which one to use by configuration.  The use of one and only one AF is allowed 
in an NSA domain.” If the line topology is important and you are interested in 
this part, I am pleasure to collaborate with you on a new separate draft to 
standardize new allocation function.



Cheers,

Guangpeng

From: 6lo <6lo-boun...@ietf.org> On Behalf Of Luigi IANNONE
Sent: Saturday, August 20, 2022 4:10 AM
To: Alexander Pelov ; marinos charalambides 
Cc: 6lo@ietf.org
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Hi Alexander,

Thanks for your feedback. Please send us the tons of questions you have we will 
do our best to answer them.

In general I think that the concerns that you are expressing can be solved 
during the normal life cycle of a draft as a WG item.

A few more specific comments inline.

Ciao

Luigi

From: 6lo <6lo-boun...@ietf.org> On Behalf Of 
Alexander Pelov
Sent: Friday, 19 August 2022 17:03
To: marinos charalambides mailto:marino...@gmail.com>>
Cc: 6lo@ietf.org
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Dear all,

I have a lot of questions and some serious issues with the applicability and 
the general description of the solution.
So, there are two reasons for which I am against adoption of this document.

Justification and use-case
In terms of the positioning of this draft and justification of the work, both 
6LoWPAN and SCHC are cited. Yet, the only justification of why this new work 
was proposed is "there could be more simplified solutions".
I'd say that firstly there is no proof in the draft that the proposed solution 
is simpler. As far as I can understand the draft, it is heavily underspecified, 
so knowing its full complexity is difficult at that time. Plus, what is 
"simpler"?

[LI] I agree that the text is unclear and misleading. We will revise this part 
of the text making sure there is no benefits overclaiming.


Secondly, which are the use-cases and the justifications that cannot be met by 
the currently existing solutions? I have a difficulty with the notion of 
""topology is static, where nodes' location is fixed, and the connection 
between nodes is also rather stable.". PLC or wireless, the channel is 
fluctuating, conditions change, devices restart, or go offline.. Unless you 
have point-to-point links, in which case you rarely care about compression 
(unless in LPWANs where you have SCHC). The claim is that "generic IOT 
solutions" can be improved, but in this document there are no examples of what 
specific use-case would benefit, e.g. what size (number of nodes, size of the 
tree, etc.).

[LI] This thread contains a few emails referring to use-cases. Those might not 
be relevant to you, but they are for those who posted the emails.


Given that the draft deals heavily with forwarding as well, I think a 
comparison with RPL should also be provided, along with the expected gains. Why 
can't we have an Objective Function that defines Tree-like behavior, and let 
RPL solve the routing?

[LI] The document never claims that NSA solve problems that cannot be solved in 
other ways. Yes, you can do a lot of things with RPL. It does not mean that it 
has to remain the only solution given that IMO there are a few people here that 
are interested in this alternative solution.
As for the comparison with RPL, that is more of an academic approach that a 
real requirement for a draft.
(Your question is valid and hopefully, with a bit more time we will be able to 
publish an academic paper on the topic.)

Technical
On the technical side, I have a ton of questions and remarks,

[LI] Please send them to us.


but I'll start with the most obvious ones (please correct me if my 
understanding is wrong):
The 

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi Pascal and all,

As we know, the discussion of whether routing in LLN networks should run at 
Layer 2 or Layer 3 (network layer) has become a very sensitive issue for a  
long time. With the advent of multiple low-power link layer technologies, such 
as IEEE 802.15.4, Wi-Fi, and PLC, network layer routing is clearly required. 
However, the separation of mesh-under and route-over processes induces 
suboptimal routes and (L2 and L3) duplicated re-route overhead.

This draft’s topological addressing method can integrate address and route 
information into a single place. It will help to run IP layer on various link 
layer technologies and meanwhile avoid above duplicated re-route issues.

Thanks Pascal for continuous advices and comments. As author of this draft, I 
want to state support of this adoption.

Regards,
Guangpeng Li

From: 6lo <6lo-boun...@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, August 3, 2022 12:37 PM
To: Jing Wang 
Cc: Carles Gomez Montenegro ; 6lo <6lo@ietf.org>
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Hello Carles

I have reviewed the work carefully.

I believe that we can achieve short packets with 6lo and SCHC so that piece is 
not an essential progress. So 6lo as an INT areaWg does not need it.The 
essential progress is meshing without routing. It’s probably hard to justify it 
at the routing area though the authors could try.

My feeling is that the idea is interesting but has a very narrow applicability, 
which is in essence the opposite of IP. The progress applies only to very 
specific L2 networks. This tells me that it is really an L2 technology and 
should be used for MAC not IP.

Bottom line is that I do not believe that the work belongs to the IETF.  I do 
not support adoption at 6lo.


Regards,

Pascal


Le 2 août 2022 à 18:01, Jing Wang 
mailto:wangjin...@chinamobile.com>> a écrit :

Hi WG,

I support the adoption call. In my opinion, this can help enlarge scope of 
IP network, considering it may consume less resource of constrained nodes.

BR,
Jing Wang

From: Carles Gomez Montenegro
Date: 2022-08-01 22:58
To: 6lo
Subject: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03
Dear 6lo WG,

This message starts a call for WG adoption for
draft-li-6lo-native-short-address-03.

(Link below:
https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address-03)

Considering that some folks may be on vacation currently or in the next
few days, the call will end on the 22nd of August, EOB.

Please state whether you are in favor of adopting this document.

Also, any comments you may have, and/or expressions of interest to review
the document, will be very much appreciated.

Thanks,

Shwetha and Carles

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Initial version of the minutes from 6lo at IETF 113

[Liguangpeng (Roc, Network Technology Laboratory)]

Dear Chairs and all,

Thanks chairs and minutes takers. Maybe it's fault of my pronunciation, I don't 
think we discussed any topic about security. If I remembered, in that time we 
discussed constrained devices and more general case, which one is the typical 
use cases of APL. Maybe we should correct the following lines a bit.

[11:40] Native Short Address for LLN Expansion (Luigi Iannone ) 15 min

goes through changes since IETF112
applicability mostly in static deployment, otherwise, need to renumber.
next: will try to evaluate gain with this approach; will respond to latest 
comments.
then will consider asking for adoption
Carles: draft states applicability for static deployment of wired 
technologies. PLC?
Luigi: some others, will do literature review
Guangpeng: PLC, also APL (Advanced Physical Layer) which is extension of 
802.3cg
>Carles: other additions needed to the draft?
>Guangpeng: security
Peng Liu: support this work

Thanks,
Guangpeng Li

> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Carles Gomez Montenegro
> Sent: Saturday, March 26, 2022 4:57 PM
> To: 6lo@ietf.org
> Subject: [6lo] Initial version of the minutes from 6lo at IETF 113
> 
> Dear all,
> 
> The initial version of the minutes from the 6lo session at IETF 113 has been
> published:
> https://datatracker.ietf.org/meeting/113/materials/minutes-113-6lo-00.txt
> 
> Many thanks to Dominique, Adnan and Michael for the excellent
> minute-taking!
> 
> Also, many thanks to all participants for the productive session and
> discussions.
> 
> Should you identify anything that might need to be corrected from the
> minutes, please let us know.
> 
> Cheers,
> 
> Shwetha and Carles
> 
> 
> 
> 
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FW: New Version Notification for draft-li-6lo-native-short-address-02.txt

[Liguangpeng (Roc, Network Technology Laboratory)]

Dear 6lo WG,

Since we have submited new version of draft(-02) that aims to address comments 
from Carsten Bormann and other experts, I suggest moving discussion from thread 
at https://mailarchive.ietf.org/arch/msg/6lo/mMqVctND3yA8C0WQAX73Pi77jtk/ to 
this one. It will also be convenience for others to be aware of new comments 
from Brian Carpenter and Adnan Rashid who (in cc list) gave comments on -02 
version directly to authors of this draft. 

After agreement of Brian, I attach his technical comments here because he is 
not on 6lo list. The authors will update draft accordingly once after IETF 113. 
Welcome further discussion on this in 6lo mailing list.

> Thanks for reminding me of your draft. I have not gone into all the 
> details, but the basic idea seems solid to me.
>
> Do you expect to allow use of IPSEC between an NSA node and a normal 
> node?
> If so, is the security association based on a 128-bit address?
> Similarly for TCP or UDP sessions with normal nodes - how is the TCP 
> or UDP checksum calculated? Does the upper layer software in an NSA 
> node know what the full IPv6 address is?
>
> Perhaps this point needs to be discussed in section 4.1 "NSA 
> Addresses
>and
> IPv6 Addresses".

Thanks all for providing help and comments to this draft. Hope everyone has a 
fruitful IETF 113.

Best Regards,
Guangpeng Li 

-Original Message-
From: internet-dra...@ietf.org  
Sent: Saturday, March 5, 2022 9:24 AM
To: Zhe Lou ; Liguangpeng (Roc, Network Technology 
Laboratory) ; Luigi IANNONE ; 
Peng Liu ; Rong Long ; 
Zhe Lou 
Subject: New Version Notification for draft-li-6lo-native-short-address-02.txt


A new version of I-D, draft-li-6lo-native-short-address-02.txt
has been successfully submitted by Guangpeng Li and posted to the IETF 
repository.

Name:   draft-li-6lo-native-short-address
Revision:   02
Title:  Native Short Addressing for Low power and Lossy Networks 
Expansion
Document date:  2022-03-04
Group:  Individual Submission
Pages:  26
URL:
https://www.ietf.org/archive/id/draft-li-6lo-native-short-address-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-li-6lo-native-short-address/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-li-6lo-native-short-address-02

Abstract:
   This document specifies a topological addressing scheme, Native Short
   Address (NSA) that enables IP packet transmission over links where
   the transmission of a full length address may not be desirable.  This
   document focuses on carrying IP packets across an LLN (Low power and
   Lossy Network), in which the topology is relatively static where
   nodes' location is fixed and the connection between nodes is rather
   stable.  The changes in the logical topology are only caused by non-
   frequent disconnection in the link.  The specifications details the
   NSA architecture, address allocation, forwarding mechanism, header
   format design, including length-variable fields, and IPv6
   interconnection support.


  


The IETF Secretariat


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FW: New Version Notification for draft-li-6lo-native-short-address-00.txt

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi all,
Thanks for feedbacks from Pascal, Dominique, Carles and others. After we (three 
new authors and I) discussed the solution (original draft is 
draft-li-native-short-address-00) after communicating with Pascal and Carles, 
some significant modifications were made.

First of all, the document clarifies that NSA is suitable for Low power and 
Lossy Networks and every NSA node may be aware of IPv6 address of them. So the 
NSA technology fall into the scope of 6lo working group. 

Secondly, in this document, we generalized the address allocation function 
definition and added description of '4.1 NSA addresses and IPv6 Addresses' and 
'Limitation of Number of Children Node'. Those should be sufficient to 
distinguish the NSA allocation from algorithms like IEEE 802.15.5 and its 
variants. 

Thirdly and most importantly, to avoid drawbacks brought by renumbering, we 
added a new mechanism to avoid the renumbering during the topology change, by 
adding/updating routing entries along the affected path. The cost is comparable 
with the local repair of RPL. Routing related procedures is refined according 
to this design, see Section 5, 6 and 8.

We also modify IANA part to apply for new registry and ICMP NSA control 
message. Considering lacking of large bulk of dispatch type space in page 0&1, 
we suggest to apply for dispatch type values in Page 10. 

Please have a look at this document and do not hesitate to reply here if you 
have comments

Best regards,
Guangpeng

-Original Message-
From: internet-dra...@ietf.org  
Sent: Monday, October 18, 2021 9:00 PM
To: Zhe Lou ; Liguangpeng (Roc, Network Technology 
Laboratory) ; Luigi IANNONE ; 
Peng Liu ; Zhe Lou 
Subject: New Version Notification for draft-li-6lo-native-short-address-00.txt


A new version of I-D, draft-li-6lo-native-short-address-00.txt
has been successfully submitted by Guangpeng Li and posted to the IETF 
repository.

Name:   draft-li-6lo-native-short-address
Revision:   00
Title:  Native Short Addressing for Low power and Lossy Networks 
Expansion
Document date:  2021-10-18
Group:  Individual Submission
Pages:  21
URL:
https://www.ietf.org/archive/id/draft-li-6lo-native-short-address-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-li-6lo-native-short-address/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address


Abstract:
   This document specifies mechanisms of NSA (Native Short Address) that
   enables IP packet transmission over links where the transmission of a
   full length address may not be desirable.  This document focuses on
   carrying IP packets across a LLN (Low power and Lossy Network), in
   which the nodes' location is fixed and changes in the logical
   topology are caused only by unstable radio connectivity (not physical
   mobility).  The specifications include NSA allocation, routing
   mechanisms, header format design including length-variable fields,
   and IPv6 interconnection support.


  


The IETF Secretariat


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] FW: New Version Notification for draft-li-native-short-address-00.txt

[Liguangpeng (Roc, Network Technology Laboratory)]

Thank you for detailed comments. Please see in lines

> -Original Message-
> From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Carles Gomez Montenegro
> Sent: Wednesday, July 28, 2021 12:32 AM
> To: Liguangpeng (Roc, Network Technology Laboratory) 
> Cc: 6lo@ietf.org
> Subject: Re: [6lo] FW: New Version Notification for 
> draft-li-native-short-address-00.txt
> 
> Hi Guangpeng,
> 
> Thanks for your interesting draft.
> 
> Please find a number of comments below:
> 
> - Section 1. “NSA routing does not need to spread routing messages to 
> establish the
> node-local routing table; such diffusion action would consume too much 
> network resources,
> thus not being suitable for large networks that consist of many nodes.”
> 
> While your proposal involves no routing protocol messages, other messages 
> need to be sent
> (i.e. AR and the corresponding response messages). Since CNNs are often 
> characterized by
> dynamic topologies (e.g. due to the use of wireless links and/or due to node 
> mobility), how
> would topology changes be dealt with in your proposal?  Probably, some sort 
> of address
> maintenance (involving the transmission of control messages) is needed.
> 
[G. L] Good comment. The node's NSA address is always managed by it's direct 
ancestor. In my immature thought, root and forwarder nodes at most need to 
maintain two bitmaps (one for child forwarder, the other for child leaf) to 
record which child addresses have been used. When topology changes, the 
neighbor relationship between parent and its children may be broken, thus 
trigger update of the bitmaps accordingly. So there may be no control messages 
needed. 

> - Figure 1: the footnote and the related text before the figure may need 
> further clarification.
> LOWPAN_IPHC allows compressing an IPv6 header (when using global addresses) 
> down
> to 3 bytes. Perhaps you might want to highlight that such compression degree 
> can only be
> achieved for a reduced number of source-destination pairs in a given 6LoWPAN 
> network (if
> that captures your intent).
> 

[G. L] Exactly. Such compression degree relies on deriving address from 
encapsulating (Context or lower layer address) . It may not be common case. If 
anyone who is familiar LOWPAN_IPHC very much and show the exact conditions to 
achieve 2/3 Octets (show in RFC 6282), we can discuss what's the advantages and 
shortcoming in view of whole networking. Whatever，I should clarify the footnote 
and text in the document in next version.

> - Section 5.2. “The border router (i.e., the root node) can construct IPv6 
> address for nodes
> by concatenating IPv6 prefix and native short address.”
> 
> I understand that NSAs are of variable size. Does the Border Router assign a 
> prefix of a
> suitable size to each node? How does the Border Router learn about the short 
> addresses
> being used in the NSA domain?
> 
[G. L] According to NSA solution, the network topology can be controlled in 
both width and depth, thus the biggest NSA length is known. Suppose it will be 
limited under 64bits, then we can assign a /64 prefix for all NSAs and rest of 
bit between prefix and NSA can be zeros


> - Are nodes in the NSA domain aware of their (uncompressed) IPv6 addresses?
> 
[G. L] Actually no. Why they need to know that?

> - It seems like the Border Router acts as an address translator.
> 
[G. L] Yes, if we define translator as a node that consuming inputs and 
generating different outputs.

> - Section 7: “This document requires IANA to assign the range 0101000 to
> 010 of the "Dispatch Type Field"”
> 
> Probably you meant the range “0101 to 010”.
> 
[G. L] Apologize for the typo. I'll modify it soon. “This document requires 
IANA to assign the range 01010001 to
> 0101 of the "Dispatch Type Field"”

> Also, please note that the first dispatch field value (0101) in page 0 
> (RFC 8025) is
> reserved as LOWPAN_BC0 (mesh broadcast/multicast support).
> 
[G. L] Thanks for pointing this. I checked the registry table again, either NSA 
gives up using 0101 because of conflict with LOWPAN_BC0 (maybe just do not 
use TF=00), or move NSA to page in 1-14. I have no experience with this, more 
suggestion in this aspect will be appreciated.

> Looking forward to your presentation in the 6lo session.
>  
> Cheers,
> 
> Carles (with no particular hat)
> 
> 
> 
> > Hi,
> >
> > This document specifies mechanisms of NSA (Native Short Address) that
> > enables IP packet transmission over links where the transmission of a
> > full length address may be wasteful. All descriptions will focus on
> > carrying IP packets across LLN (Low power and Lossy Networks), those
> > LLNs positioned a

[6lo] FW: New Version Notification for draft-li-native-short-address-00.txt

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi, 

This document specifies mechanisms of NSA (Native Short Address) that enables 
IP packet transmission over links where the transmission of a full length 
address may be wasteful. All descriptions will focus on carrying IP packets 
across LLN (Low power and Lossy Networks), those LLNs positioned as limited 
domains. The specifications include NSA allocation, routing with NSA, header 
format design including length-variable fields, and how to access full IPv6 
networks.

Look forwarding to discussion and comments.

Thanks

Guangpeng Li

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Saturday, July 10, 2021 8:51 PM
To: Liguangpeng (Roc, Network Technology Laboratory) 
Subject: New Version Notification for draft-li-native-short-address-00.txt


A new version of I-D, draft-li-native-short-address-00.txt
has been successfully submitted by Guangpeng Li and posted to the IETF 
repository.

Name:   draft-li-native-short-address
Revision:   00
Title:  Native Short Address for Internet Expansion
Document date:  2021-07-10
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-li-native-short-address-00.txt
Status: https://datatracker.ietf.org/doc/draft-li-native-short-address/
Html:   
https://www.ietf.org/archive/id/draft-li-native-short-address-00.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-li-native-short-address


Abstract:
   This document specifies mechanisms of NSA (Native Short Address) that
   enables IP packet transmission over links where the transmission of a
   full length address may be wasteful.  All descriptions will focus on
   carrying IP packets across LLN (Low power and Lossy Networks), those
   LLNs positioned as limited domains.  The specifications include NSA
   allocation, routing with NSA, header format design including length-
   variable fields, and how to access full IPv6 networks.


  


The IETF Secretariat


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] 6lo session at IETF 111?

[Liguangpeng (Roc, Network Technology Laboratory)]

Hi Chairs,

I am working on an I-D about optimization of IP packet transmission over LLN. 
It will be ready before submission deadline of IETF 111. So, I hope I can get 
15 minutes to present the draft during IETF 111. If people are interested in 
it, maybe another 10 minutes would be better for discussion.

Thanks,
Guangpeng Li

From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Shwetha
Sent: Tuesday, June 8, 2021 11:10 PM
To: 6lo@ietf.org
Cc: Erik Kline ; Carles Gomez Montenegro 

Subject: [6lo] 6lo session at IETF 111?

Dear WG,

We (6lo chairs) are currently in the process of deciding whether to
request a slot for a 6lo session at IETF 111.

Should any of you want to suggest any 6lo-related topics to be discussed
in a potential 6lo session at IETF 111, please let us know no later than
the 10th of June at 23:59 (UTC).

Thanks,
Carles and Shwetha

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo