Wojciech Dec 写道:
On 29 January 2013 09:37, Rémi Després<[email protected]> wrote: The key is "keep it simple", with neither IPv4 addresses nor PSIDs in MAP-E IIDs. More explanations below. An IID needs to be there. The IPv4+PSID is computed in any case and makes such a decent IID, without increasing implementation complexity. Peeking across layers, possibly encapsulation layers to obtain such useful, according to some operators, info is not conductive to making things simpler for anyone operating the network. It also does not complicate matters for those operators not planning to make any use of this info. As I mentioned, having a fixed length IPv4+PSID would be my preference. fully agree with Woj. xing Regards, Woj. 2013-01-28 14:51, Wojciech Dec <[email protected]>t : Hi, the IPv4 and PSID in the IID are particularly useful in cases of address independence (ie 1:1). As said previously, the benefit is primarily in the ability an operational facilitation, where an operator can easily see/observe what IPv4 and PSID is being used by a given customer. This is easier than to look at the v6 prefix and use some magic decoder ring. (a) The IPv4 address already readable in the encapsulated IPv4 packet (the subject is only MAP-E, not MAP-T or 4rd). (b) With the proposed IID format, the length of the PSID cannot be determined without looking at the applicable mapping rule. (As already noted, the number of zeroes at the end of the PSID isn't specified in the address). (c) Once the rule is looked at, getting the PSID is easy (no more magic needed than to get find the PSID length ;-)). In addition, it has the desirable characteristic of creating an IID. A constant IID was the logic proposal for the original Encapsulation solution (then called "4rd" before becoming "MAP-E", ref. tools.ietf.org/html/draft-murakami-softwire-4rd-01). It is only when we tried to merge -E it with -T that we abandoned this simplicity. (Incidentally, to avoid limitation (b) above, we introduced that at that time a PSID-length field in IIDs (ref.www.ietf.org/mail-archive/web/softwires/current/msg02994.html), but this complexity would be superfluous for MAP-E.) Regards, RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
