The MPLS WG Archive

["Vach Kompella" <vkompella@timetra.com>]

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: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Eric Rosen
> Sent: Thursday, October 21, 2004 12:25 PM
> To: mpls@ietf.org
> 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. 
> 
> 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
> 


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