Re: [Softwires] Comments on draft-ietf-softwire-map-02.txt

[Satoru Matsushima <[e-mail]>]

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 <[e-mail]> 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