The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

We  had originally  agreed to  remove  the Host  Address FEC  on grounds  of
disuse, but this  decision was deferred due to  a liaison statement received
from some forum which claims  to have written specifications which depend on
it. 

However, I find  that liaison statement very confusing.   In particular, the
liaison states: 

    "In RFC 3036, there is a  semantic difference between a Host Address and
    a  prefix  with length  32.   The new  version  proposes  to remove  the
    semantic difference.  This is not a problem for the MPLS Proxy Admission
    Control; we are  just requesting that the Host  Address codepoint not be
    deprecated."

This seems to be  saying that they want the Host Address  FEC to remain, but
they don't  care if its semantics  are changed.  That  is somewhat peculiar.
To me, it suggests that they are  not actually using the Host Address FEC as
it is specified  in RFC 3036, but  rather are overloading it to  be used for
another purpose entirely;  in effect stealing the codepoint  for a different
use. One might think that the  very fact that this codepoint is stealable is
itself an indication of its lack of use.

It seems to me then that we should just go ahead and remove the Host Address
FEC from rfc2026bis.  If some other organization needs a TLV whose usage has
not  been specified  in  any IETF  document,  they should  follow the  usual
procedures and write  an internet draft requesting a  code point assignment.
If they want  to reuse an existing codepoint in  the "IETF consensus" range,
they should obtain IETF consensus. 




_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls