HI Satoru,

I am saying that hub & spoke model is quite simple in case of MAP-E.
In the draft, draft-ietf-softwire-map-02, as you have done it in
draft-mdt-softwire-map-encapsulation-00, specify hub&spoke case first.

I know that mesh model is important for MAP-E as BR may be deployed
deep in the network. You are explaining in detail in Section 5. I
suggest adding one clarifying statement saying that it applies to the
mesh model.

As for the details of encapsulation in reference to
draft-mdt-softwire-map-encapsulation-00, I suggest that you

either make draft-mdt-softwire-map-encapsulation-00 a normative
reference and make it up to date, or

add some details to draft-ietf-softwire-map-02 on how the
encapsulation in MAP-E works in reference to RFC 2473.

As for the source address of IPv6 packets sent by BR, I suggest
removing the requirement to make it an anycast address. I read in a
vendor web site (Cisco) it is stated that anycast addresses must not
be used as source addresses. RFC 4291 does not require this though.

The reason? As I explained, at times MAP-E is stateful, how would CE
find the right BR if it does not know BR's unicast address?

I hope the above is clear. I am removing the conversation we had
before, but I am curious, what is MRT? I could not find it anywhere?



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

Regards,

Behcet
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to