Subject: [mpls] Host Address FEC

From: Eric Rosen <[email-masked]>
Date: Thu, 21 Oct 2004 15:24:37 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Vach Kompella" <[email-masked]>
Date: Thu, 21 Oct 2004 13:06:18 -0700

Alternatively, it could mean that they use Host Address FEC as if it
were a regular Prefix FEC, so the change in semantics is not material.
In any case, they should clarify why they don't care if the semantics
are changed, which may would help us decide if the request is
meaningful.

-Vach 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Rosen
> Sent: Thursday, October 21, 2004 12:25 PM
> To: [email-masked]
> Subject: [mpls] Host Address FEC 
> 
> 
> 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. 
> 
> 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. 
> 
> 
> 
>

---

From: Ina Minei <[email-masked]>
Date: Thu, 21 Oct 2004 18:27:20 -0700 (PDT)

Let us set aside for a moment the question of how the FEC is used.

	Once the Host FEC was defined, there is nothing to preclude use of
it in many creative ways. If for example one needed to carry some kind of
host information in LDP, would one define a new TLV, or just reuse the
host address FEC? I would think the latter. Thus I don't think one should
make the argument based on the use of the FEC.

				Ina

---

From: Eric Rosen <[email-masked]>
Date: Fri, 22 Oct 2004 11:07:04 -0400

Ina> Once the Host  FEC was defined, there is nothing to  preclude use of it
Ina> in many creative ways. 

Protocol elements have both syntax and semantics; reusing an existing syntax
for a new semantics is a change in the protocol.

The purpose  of the Host  FEC was the  following.  Some folks  insisted that
they needed the labels to distinguish between the following two cases: 

- a packet destined for some software module in a given router;
- a packet which is being tunneled to a given router for further forwarding.

If  you  don't need  to  make  this distinction  based  on  the label,  then
obviously there's no reason to ever use the Host Address FEC. 

Why did  people think they needed  this distinction?  Because  they had some
hardware which, after the initial  label lookup, needed to decide whether to
send the packet into the CPU-accessible memory, or whether to run it through
the  forwarding logic.  The  forwarding logic  in question  could look  up a
second label  or an IP address,  but could then  only send the packet  to an
output card, not to the CPU. 

AS it turned out, the need for this distinction never showed up in practice,
and  no one actually  originates Host  Address FECs.   To me,  this suggests
pretty strongly  that it needs to be  removed as part of  the progression to
draft standard. 

> If for example  one needed to carry some kind of  host information in LDP,
> would one define a new TLV, or just reuse the host address FEC? 

It depends on  whether one is trying  to avoid the IETF process  or not.  If
you are  trying to carry  some new kind  of host information,  shouldn't you
present an  internet-draft explaining that,  and requesting a  codepoint for
that information? 

If we keep the Host FEC in as  it is described in RFC 3036, it has an impact
on  all LDP implementations,  whether or  not those  implementations provide
features  which  have been  specified  in  some  other forum.   Since  those
features,  and the  related  use of  the  Host Address  FEC,  have not  been
presented to or approved by this WG, I don't understand how this can be kept
as part of the IETF standard.