I am not sure that's of any use to intermediate nodes without the rest
of the rules, but I suppose you have to put something unique into the IID.
I have one concern indirectly related to this. Section 6 still says:
If the End-user IPv6 prefix length is larger than 64, the most
significant parts of the interface identifier is overwritten by the
prefix.
I believe that makes the IID non-conformant to RFC 6052.
On 24/01/2013 5:44 PM, Ole Troan wrote:
Tom,
This caught my eye too. Why repeat the PSID?
the reason I got, if my memory serves me correctly, is that it allows a
intermediate box to look at the PSID,
without knowing the mapping rules (which it must to look at the PSID in the
first 64 bits.
cheers,
Ole
On 24/01/2013 11:27 AM, Ole Troan wrote:
hi,
can we please keep discussion on the list. not via the issue tracker?
does anyone else have an opinion?
(if I don't hear anything from anyone else, I'll default to keep current text.)
cheers,
Ole
On Jan 24, 2013, at 17:23 , softwire issue tracker
<[email protected]> wrote:
#19: IPv4 address superfluous in MAP-E Interface IDs
Changes (by [email protected]):
* priority: trivial => major
* status: closed => reopened
* resolution: wontfix =>
Comment:
Value of having the PSID in MAP-E IIDs for maintenance isn't clear at all:
- PSID length isn't determined in IIDs (there can be an unknown number of
trailing zeroes)
- all PSID bits are already readable in the first 64 bits
Suggestion to close the issue:
- keep IPv4 addresses in IIDs (they contains some bits that aren't in the
first 64 bits)
- don't keep the PSID in IIDs (insufficiently justified complexity)
...
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
