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. 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
