2012/3/7 Rémi Després <[email protected]> > Hi Tina, > > Le 2012-03-07 à 09:58, Maoke a écrit : > > > > 2012/3/7 Tina TSOU <[email protected]> > >> >> >> Sent from my iPad >> >> On Mar 6, 2012, at 2:24 AM, "GangChen" <[email protected]> wrote: >> >> > Hello Tina, >> > >> > Could you help to clarify the sentence: >> > >> > *1 MAP and divi-pd provide better security than 4rd-U, because they >> > provide more variation in port set definition. >> > >> > I guess they should have similar features on security >> Agreed. No much difference between MAP, divi-pd, and 4rd-U with regard to >> security. So I propose to remove this sentence. >> > > +1 (see below) > > > > well, *better security* might be an inaccurate expresssion. i suppose MAP > provides better flexibility than 4rd-U. personally, i understand the reason > of 4rd-U requiring fixed offset (4bits) is to support the longest-match of > port for CE-finding in the mesh mode (i.e., the MAX PSID). it is a > tradeoff. without the fixed offset, longest-match fails for the PSID > matching and there must be a way of distributing CE's PSID to other CEs. > however, > > > > it does also confuses me that the newest 4rd-U draft doesn't mention the > MAX PSID feature (or maybe i missed something). > > > The max PSID feature, present in 4rd-u-00 and -01 (i.e. before IETF 82), > was abandoned during the Taipei meeting (November 2011) > It no longer appeared in -02 (December 29). > > Reasons of the 4rd-u fixed offset are (ref. sec 4.3 of -04): > "NOTE: The choice of the PSID position in Port fields has been guided by > the following objectives: (1) for fairness, avoid having any of the > well-known ports 0-1023 in the port set specified by any PSID value (these > ports have more value than others); (2) for compatibility RTP/RTCP > [RFC4961], include in each port set pairs of consecutive ports; (3) in > order to facilitate operation and training, have the PSID at a > fixed position in port fields; (4) in order to facilitate documentation in > hexadecimal notation, and to facilitate operation and training, have the > PSID at a fixed position in port fields." > >
Remi, point (1) is qualified for the individual use case but not available for the enterprise environment, where surely it is possible that one put all well know services under a same CE. but if MAP or 4rd-U states enterprise use case is NOT to be supported, it is fine. point (2) is qualified but not a sufficient condition to derive the fixed position of PSID. point (3) and (4) is about the human reading on the PSID. however, the MAP or 4rd-U address has been human-unfriendly. i don't see training and operation on easy-to-read PSID is significant. therefore i think MAXPSID, though it is abandoned, is a convincing reason of having fixed position of PSID. - maoke > > > Hope it clarifies. > > Regards, > RD > > > > > >> > >> > Gang >> > >> > 2012/3/2, Tina TSOU <[email protected]>: >> >> Dear all, >> >> You may be interested to comment on >> >> >> http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-analysis/ >> >> >> >> Abstract: >> >> This memo analyses some port set definition algorithms which >> >> encode port set information into IPv6 address so as to support >> >> stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and MAP. >> >> >> >> >> >> Tetsuya, Simon and Tina >> >> >> >> _______________________________________________ >> >> Softwires mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
