Hi, Senthil, [email protected] 写于 2013-01-29 10:49:59:
> > > On 1/28/13 12:56 PM, "Ole Troan" <[email protected]> wrote: > > >Senthil, > > > >[...] > > > >>> The draft says that: > >>> (a) The PSID is: > >>> +--+---+---+---+---+---+---+---+---+ > >>> |PL| 8 16 24 32 40 48 56 | > >>> +--+---+---+---+---+---+---+---+---+ > >>> |64| u | IPv4 address | PSID | 0 | > >>> +--+---+---+---+---+---+---+---+---+ > >> > >> I believe this figure is misleading by placing the IPv4 address in a > >>fixed > >> location. Figure 3 and Figure 7 > >> In the draft shows that the IID is not in a fixed location. Also, the > >>text > >> surrounding the above figure 8, says > >> "The Interface identifier format of a MAP node is based on the format > >> specified in section 2.2 of [RFC6052], with the added PSID field if > >> present, as shown in figure Figure 8." > >> > >> > >> But RFC 6052 doesn¹t have the IPv4 address in a fixed location as per > >> section 2.2. So I think this figure is misleading. > > > >perhaps we should just remove the RFC6052 reference then? > >with a 48 bits of PSID + IPv4 address. > >I don't mind if it is just IPv4 address, but then someone need to drive > >that discussion. > > I think the above figure should be clarified as an example when the > prefix-length+EA <= 64. > If the prefix length is greater than 64, the IPv4 address appears after > the prefix length and > U bits are overwritten. For example, prefix is /68, then IPv4 address appears at the 69-100 bits or there are still 4-bit for u bits,and IPv4 address appears at 73-104 bits? BRs Linda Wang > If we clarify the above two points and remove the reference to rfc6052, > that would be fine. > > > Thanks > Senthil > > > >> | n bits | o bits | s bits | 128-n-o-s bits | > >> +--------------------+-----------+---------+------------+----------+ > >> | Rule IPv6 prefix | EA bits |subnet ID| interface ID | > >> +--------------------+-----------+---------+-----------------------+ > >> > >> > >>> (b) "If the End-user IPv6 prefix length is larger than 64, the most > >>> significant parts of the interface identifier is overwritten by the > >>> prefix." > >>> > >>> This is particularly unclear: > >> > >> True. > >>> - What happens to the u octet? > >> > >> I guess that needs to be made clear in the draft. We struggled with that > >> in our implementation. > > > >if we remove the 6052 reference, there is no u-octet. > > > >>> - And to the IPv4 address if the prefix is longer than /68? > >>> - ... > >>> > >>> Of course, if a use case is provided where MAP-E would be actually used > >>> with an IID shorter than 64 bits, it should be discussed. But: > >>> - There is no such use case so far. > >>> - Looking for one doesn't seem useful. > >> > >> I would like to see the IPv4 address be present from bits 96-127, no > >>need > >> for the PSID to be repeated again. That would allow us to go upto /96 > >>and > >> being consistent with RFC 6052 which allows one to configure a prefix of > >> upto /96. > > > >just put the IPv4 address in the bottom bits, and allow it to be > >overwritten by the prefix. > >it is just there for 'pretty printing' anyway. > > > >cheers, > >Ole > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
