Re: [Softwires] MAP documents - next steps

[Jacni Qin <[e-mail]>]

Hi all,

On 1/30/2012 7:31 PM, Ole Trøan wrote:
> hi,
>
> the MAP (Mapping of address and port) design team has now written and published the following sets of drafts.
>
> the base document (port mapping algorithm):
>    http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03
>    http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-mapping-address-and-port-03.txt
>
> the encapsulation document (MAP-E):
>    http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00
>
> the translation document (MAP-T):
>    http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00
>
> the DHCP option (MAP-DHCP):
>    http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02
>
> there is a MAP deployment document coming soon.
>
> the solution described in this set of documents, are written to satisfy the following from the softwires charter:
>     4. Developments for stateless legacy IPv4 carried over IPv6
>        - develop a solution motivation document to be published as an RFC
>        - develop a protocol specification response to the solution
>          motivation document; this work item will not be taken through
>
> in the design team's view, this set of documents are ready to be adopted as working group documents.

No objection to the adoption of the base document, with some comments 
(sorry if they've been discussed ever), please check below.
BTW, another question, I can' t remember the conclusion when the DT was 
chartered, whether the -E and -T were the missions of the DT, or not?


----------------------------------------------------
1. Section 4., ...

    The forwarding function uses the MRT to make forwarding decisions.
    The table consist of the mapping rules.  An entry in the table
    consists of an IPv4 prefix and PSID.  The normal best matching prefix
    algorithm is used.  With a maximum key length of 48 (32 + 16).  E.g.
    with a sharing ratio of 64 (6 bit PSID length) a host route for this
    CE would be a /38 (32 + 6).

I'm confused here. The forwarding is based on routing tables (while IMHO 
the Section 5.3 & 5.4 state it clearer),
the implementations may vary while the basic logic could be:
Each FMR should install one corresponding route in the IPv4 RIB, like,

Rule IPv4 prefix -> "connected", MAP Interface1

For outbound traffic from the private network, when the IPv4 RIB lookup is
performed, it should hit one element with a MAP interface, which can be
used as the pointer to the correct FMR in the MRT, to form the MAP IPv6
address of the destination.


2. Section 5.1.3., more text about what the "offset bits" is for, may 
need to
be added, something like, "The length of offset bits determines the excluded
ports ..."


3. Section 5.2., ...

    The offset of the EA bits field in the IPv6 address is equal to the
    BMR Rule IPv6 prefix length.  The length of the EA bits field (o) is
    given by the BMR Rule EA-bits length.  The sum of the Rule IPv6
    Prefix length and the Rule EA-bits length MUST be less or equal than
    the End-user IPv6 prefix length.

The prefix6-len + EA-bits len must be equal to the End-user IPv6 prefix
length, why there is a "less than"? Any reasonable use case about it?


4. Section 6.,  ...

    In an encapsulation solution, an IPv4 address and port is mapped to
    an IPv6 address.  This is the address of the tunnel end point of the
    receiving MAP CE.  For traffic outside the MAP domain, the IPv6
    tunnel end point address is the IPv6 address of the BR.  The
    interface-id used for all MAP nodes in the domain MUST be
    deterministic.

How to do that, to make the interface-id deterministic? By the
interface-id formula specified?

    ...

    The encoding of the full IPv4 address into the interface identifier,
    both for the source and destination IPv6 addresses have been shown to
    be useful for troubleshooting.

Does this statement apply to translation only, or to both?
----------------------------------------------------------


Cheers,
Jacni

>
> comments?
>
> for the MAP design team,
> Ole
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>