Hi Behcet,
On 2012/09/15, at 0:49, Behcet Sarikaya wrote: > Ole, > Thanks for your quick reply. > Please see inline. > > On Fri, Sep 14, 2012 at 2:36 AM, Ole Trøan <[email protected]> wrote: >> Bechet, >> >>> I have some comments on this draft. >>> >>> Regarding Section 5, I am curious why we need the mapping, i.e. >>> Section 5 if we are doing MAP-E? i.e. NAT44'ed IPv4 packet is >>> encapsulated in IPv6 using RFC 2473. RFC2473 defines quite in detail >>> in Section 5 on Tunnel IPv6 Header almost everything needed. >> >> MAP-E does everything MAP does. support of mesh mode, stateless BRs... >> without mapping how would that be achieved? >> > > Well, this is very well answered in draft-mdt-softwire-map-encapsulation-00 > Section 8.2 which says that > > all CEs do not look up the mapping rules upon receiving an > IPv4 packet from its LAN side and then CE must encapsulate the IPv4 > packet with IPv6 whose destination must be a given BR. > > referring to the Hub & Spoke model. > > Do we have a similar statement in draft-ietf-softwire-map-02? > I think we should. > It looks that there're two cases for hub-and-spoke mode. One is that a CE forwards packets with MRT as same as mesh mode, but it has only DMR. The other is that a CE forwards all packets with following DMR even it has several FMRs. Do we need to distinguish each of them? then write up both cases for hub-and-spoke? >>> More specific comments: what is the relationship of this draft with >>> the original MAP-E draft, draft-mdt-softwire-map-encapsulation-00? >>> That draft described in detail how RFC 2473 would be used which is >>> missing in draft-ietf-softwire-map-02. OTOH draft-ietf-softwire-map-02 >>> does not even reference draft-mdt-softwire-map-encapsulation-00, why? >> >> draft-ietf-softwire-map has evolved from >> draft-mdt-softwire-map-encapsulation and is meant >> to incorporate all the significant parts of it. something may have fallen >> out in editing, >> if so please propose text. > > draft-mdt-softwire-map-encapsulation gives details of many things > including encapsulation and fragmentation referring to specific > section of RFC 2473. I think we should carry these important details > to the new and normative draft? > Would you suggest which text should be carried out from previous MAP-E? > > One more issue: > > Regarding Section 7.2 which states that BR MUST use this anycast IPv6 > address as the source > address in packets relayed to CEs. > It seems like this has been carried over from 6rd. > > I have concerns on this MUST. I think that CE has to maintain multiple > tunnel interfaces with BRs if there are more than one BR, right? How > would this be possible if CE does not know the unicast address of BR? > > Also, at times, MAP-E could be stateful. This is explained in Section > 7 of draft-mdt-softwire-map-encapsulation which you do not not have. > How could CE identify the specific BR in this case? > > I suggest changing MUST to MAY or even removing that sentence. It looks you suggest the case which supports multiple DMRs on a CE. Is that correct understanding? On the CE, the source address of a received IPv6 packet MUST be the BR address of the DMR(s) which the CE has. cheers, --satoru _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
