Subject: [rrg] draft-irtf-rrg-recommendation-00 - Modified-Header Forwarding (MHF)

From: Robin Whittle <[email-masked]>
Date: Wed, 18 Feb 2009 17:55:32 +1100

Hi Tony,

I fully support the recommendation that we spend another year
devising our final recommendation.

Here is some suggested text to add after "3.1.3 Map & Encap".

The two MHF techniques are:

  ETR Address Forwarding (EAF) - for IPv4  (A4g)
  30 bits for the ETR address
  http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw

  Prefix Label Forwarding (PLF) - for IPv6  (A4f)
  19 or 20 bits to identify the BGP advertised prefix of the ETR
  http://www.firstpr.com.au/ip/ivip/ivip6/

  Regards

    - Robin

3.1.4 Map & Forward with Modified Header Forwarding (MHF)

An alternative mechanism to Map & Encap retains the mapping system
and overall structure of tunneling the traffic packet across the DFZ
to a tunnel endpoint device at the RLOC address - which forwards the
packet directly to the destination network.  Instead of
encapsulation, Modified Header Forwarding (MHF) alters the IP header
of the original packet to include sufficient bits to specify part or
all of the RLOC address of the tunnel endpoint device.  That device
restores the original state of the IP header and forwards the traffic
packet directly to the destination network.

Strategy A4f (below) provides enough bits in a modified IPv6 header
for routers to forward the packet to the ISP network which contains
the RLOC device.  Strategy A4g encodes a 30 bit RLOC address into a
modified IPv4 header so the packet can be forwarded all the way to
the tunnel endpoint.

The primary advantages of these techniques are elimination of
encapsulation overhead and of the Path MTU Discovery problems which
are inherent in any encapsulation-based tunneling solution.

The primary disadvantage is the need for all DFZ, and some internal,
routers to be upgraded to recognise the altered IP header format.
For IPv4 an additional constraint is lack of support for fragmented
packets or fragmentable packets longer than some constant, likely to
be somewhat less than 1500 bytes.  However, similar constraints may
apply to any system which adequately manages the PMTUD problems
caused by encapsulation.

These techniques could be used by adapting any Map & Encap
architecture which does not need to carry further bits of information
with the traffic packet and which does not require the tunnel
endpoint to be able to determine which device tunneled the packet.
For such an architecture, MHF could be used as a more efficient
long-term alternative to encapsulation.

Alternatively, if the routers could be upgraded in time for the
introduction of the scalable routing solution, these techniques could
be used from the outset, eliminating the need for development of
encapsulation techniques and of solutions to the resultant PMTUD
problems.

---

From: "Tony Li" <[email-masked]>
Date: Mon, 23 Feb 2009 11:41:16 -0800

Robin,

Thank you very much for your suggestion.  However, section 3.1.3 (and, for
that matter, all of section 3.1) is much more general than section 3.3.1.4.
I believe that those two techniques are covered quite adequately there.

Regards,
Tony

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Robin Whittle
|Sent: Tuesday, February 17, 2009 10:56 PM
|To: RRG
|Subject: [rrg] draft-irtf-rrg-recommendation-00 - 
|Modified-Header Forwarding(MHF)
|
|Hi Tony,
|
|I fully support the recommendation that we spend another year
|devising our final recommendation.
|
|
|Here is some suggested text to add after "3.1.3 Map & Encap".
|
|The two MHF techniques are:
|
|  ETR Address Forwarding (EAF) - for IPv4  (A4g)
|  30 bits for the ETR address
|  http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw
|
|
|  Prefix Label Forwarding (PLF) - for IPv6  (A4f)
|  19 or 20 bits to identify the BGP advertised prefix of the ETR
|  http://www.firstpr.com.au/ip/ivip/ivip6/
|
|
|  Regards
|
|    - Robin
|
|
|
|3.1.4 Map & Forward with Modified Header Forwarding (MHF)
|
|An alternative mechanism to Map & Encap retains the mapping system
|and overall structure of tunneling the traffic packet across the DFZ
|to a tunnel endpoint device at the RLOC address - which forwards the
|packet directly to the destination network.  Instead of
|encapsulation, Modified Header Forwarding (MHF) alters the IP header
|of the original packet to include sufficient bits to specify part or
|all of the RLOC address of the tunnel endpoint device.  That device
|restores the original state of the IP header and forwards the traffic
|packet directly to the destination network.
|
|Strategy A4f (below) provides enough bits in a modified IPv6 header
|for routers to forward the packet to the ISP network which contains
|the RLOC device.  Strategy A4g encodes a 30 bit RLOC address into a
|modified IPv4 header so the packet can be forwarded all the way to
|the tunnel endpoint.
|
|The primary advantages of these techniques are elimination of
|encapsulation overhead and of the Path MTU Discovery problems which
|are inherent in any encapsulation-based tunneling solution.
|
|The primary disadvantage is the need for all DFZ, and some internal,
|routers to be upgraded to recognise the altered IP header format.
|For IPv4 an additional constraint is lack of support for fragmented
|packets or fragmentable packets longer than some constant, likely to
|be somewhat less than 1500 bytes.  However, similar constraints may
|apply to any system which adequately manages the PMTUD problems
|caused by encapsulation.
|
|These techniques could be used by adapting any Map & Encap
|architecture which does not need to carry further bits of information
|with the traffic packet and which does not require the tunnel
|endpoint to be able to determine which device tunneled the packet.
|For such an architecture, MHF could be used as a more efficient
|long-term alternative to encapsulation.
|
|Alternatively, if the routers could be upgraded in time for the
|introduction of the scalable routing solution, these techniques could
|be used from the outset, eliminating the need for development of
|encapsulation techniques and of solutions to the resultant PMTUD
|problems.
|
|
|
|
|
|
|
|
|
|
|
|_______________________________________________
|rrg mailing list
[email-masked]
|http://www.irtf.org/mailman/listinfo/rrg
|

---

From: Robin Whittle <[email-masked]>
Date: Tue, 24 Feb 2009 12:36:57 +1100

Hi Tony,

I disagree with your apparent view that the 3.1 taxonomy is adequate

> I believe that those two techniques are covered quite adequately there.

I think that if you are to have the 3.1 taxonomy, it should be
extended to cover all the architectures - or that a note be added
that this only covers a subset of the currently proposed
architectures.  Unless there is a note to the contrary, readers will
assume that each taxonomy has a place for every one of the architectures.

My understanding of the 3.1 taxonomy is that describes the set of
primary mechanisms by which routing scaling architectures achieve
their goals.  I understand these are broad divisions and that other
taxonomies divide the architectures more finely.

The "Modified Header Forwarding" techniques do not fit at all into
your current 3.1 taxonomy.  They are not Transport, Translation or
Map & Encap.  In many ways these MHF techniques resemble Map & Encap,
but there is no encapsulation, and therefore no overhead or PMTUD
problems.

I think that if you retain the 3.1 taxonomy you should add, at the
bare minimum, something like this:

   An alternative mechanism to Map & Encap retains the mapping system
   and overall structure of tunneling the traffic packet across the
   DFZ to a tunnel endpoint device at the RLOC address - which
   forwards the packet directly to the destination network.  Instead
   of encapsulation, Modified Header Forwarding (MHF) alters the IP
   header of the original packet to include sufficient bits to
   specify part or all of the RLOC address of the tunnel endpoint
   device.

   These two techniques are described below as strategies A4f and
   A4g.  They both require upgraded DFZ and other routers but avoid
   Map & Encap's problems of encapsulation overhead and Path MTU
   Discovery problems.

In the long term, upgrading all the routers is not a problem.  The
system could be introduced as Map & Encap and transition later to
using MHF instead.  Perhaps, by the time we implement the solution,
it will be practical to upgrade the DFZ routers anyway, and therefore
 avoid the PMTUD problems of encapsulation entirely.

I believe that these MHF techniques are by far the best long-term
approach for any core-edge separation architecture.  I believe they
should be a part of however many taxonomies which are used in this
document.

I will write in another message some changes I suggest to the 3.3.1
section to better cover Ivip's Map & Encap approaches and "Map &
Forward with Modified Headers".

  Regards

    - Robin

---

From: "Tony Li" <[email-masked]>
Date: Mon, 23 Feb 2009 22:53:04 -0800

Hi Robin,

|I disagree with your apparent view that the 3.1 taxonomy is adequate
|as it stands:

Then you mistake my intent completely.  The taxonomy in 3.1 is inadequate
and not particularly helpful and not really worth further refinement.  It's
included mostly out of completeness.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Tue, 24 Feb 2009 19:44:02 +1100

Hi Tony,

> included mostly out of completeness.

But the current text gives no indication that this 3.1 taxonomy is
inadequate.  I don't see the value in "completeness" if it means
including every possible taxonomy, including those which are inadequate.

I suggest that if you don't want to improve it, that you either
clearly state it is incomplete or remove it.

My first preference is for improving it and my second is for removing it.

  - Robin

---

From: "Tony Li" <[email-masked]>
Date: Tue, 24 Feb 2009 13:05:06 -0800

|But the current text gives no indication that this 3.1 taxonomy is
|inadequate.  I don't see the value in "completeness" if it means
|including every possible taxonomy, including those which are 
|inadequate.
|
|I suggest that if you don't want to improve it, that you either
|clearly state it is incomplete or remove it.

Fair enough.  I've added some text to clearly focus us on section 3.3.

Tony