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

[Behcet Sarikaya <[e-mail]>]

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.

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


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.

Regards,

Behcet