Subject: RE: [mpls] Host Address FEC

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 21 Oct 2004 22:01:42 -0400

Hi Eric,

See inline ...

Tom Phelan

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, October 21, 2004 3: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. 
> 
> 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.

No, you've got it backwards.  We want the Host Address FEC to remain, with its current syntax.  The MPLS Forum protocol uses the Host Address FEC as a host address, as it's intended in RFC 3036.  The proposed semantic change was to the Prefix Address FEC (not the Host Address FEC) - to make a Prefix Address with a 32-bit prefix equivalent to a Host Address FEC.  This change, to make a Prefix Address FEC able to substitute for a Host Address FEC has no effect on our protocol.  The MPLS Forum protocol needs to have the Host Address FEC as it is in RFC 3036, and uses it in the spirit of its meaning there.

> 
> 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. 

Well, what we actually need is a TLV whose usage *has* been specified in an IETF document, and would like to see it continue to be specified.  Something vastly different than what you're saying here.

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

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

Tom> The proposed  semantic change  was to the  Prefix Address FEC  (not the
Tom> Host  Address FEC)  - to  make a  Prefix Address  with a  32-bit prefix
Tom> equivalent  to a  Host  Address FEC.   This  change, to  make a  Prefix
Tom> Address FEC able to substitute for  a Host Address FEC has no effect on
Tom> our protocol 

Tom, this is not a  correct understanding.  Eliminating the Host Address FEC
does not have  any effect whatsoever on the semantics  of the Prefix Address
FEC. 

Tom> The MPLS Forum protocol needs to have the Host Address FEC as it is in RFC
Tom> 3036, and uses it in the spirit of its meaning there.  

So you say, but  it doesn't seem that way to me.   Maybe you should write an
Internet Draft explaining how you intend to use it. 

Suppose the  Host Address  FEC is removed  from RFC  3036, and you  write an
Internet  Draft proposing that  the codepoint  be reused  for an  MPLS Forum
protocol. Can you explain why that doesn't meet your needs?

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 22 Oct 2004 12:34:14 -0400

Eric,

>does not have  any effect whatsoever on the semantics  of the Prefix Address

In Ina's first draft, the Prefix Address FEC was GOING TO change as a 
result of elimination of the Host Address FEC.  Re-read her original draft 
and you'll see it in the list of proposed changes to RFC 3036.  Both of 
those changes were backed out of the current draft.

>Internet Draft explaining how you intend to use it.

The document is publicly available at
http://www.mplsforum.org/tech/mpls-proxy-admission-control-protocol-ia.pdf
  .  It could be copied into an internet draft, but that's just makework, 
since you can read the document right now with one click.

>protocol. Can you explain why that doesn't meet your needs?

Again, that's just unnecessary makework, plus makework to remove the FEC in 
the first place.  Why are you so opposed to leaving it in place?

Cheers,
Andy

---

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

> result of elimination of the Host Address FEC. 

I was getting ready  to send her comments on that when  it was brought to my
attention that she had removed the changes.  No change to the Address Prefix
FEC is  necessary.  (I wrote the original  text for section 2.1,  and it was
always  my  intention that  the  Host Address  FEC  be  optional and  easily
removable,  as I  always thought  it was  a  bad idea  and had  no plans  to
implement it.) 

> It could be copied into an internet draft, but that's just makework, since
> you can read the document right now with one click. 

I think you mean that I can access the document with one click ;-)

I believe that the liaison statement  is really requesting a codepoint in an
IETF protocol,  to be used  for a purpose  which is specified in  a non-IETF
document.  This is no different than any other attempt by non-IETF groups to
extend IETF protocols, and I believe  the usual process for that involves an
internet-draft, as well as review within the IETF.

---

From: Eric Gray <[email-masked]>
Date: Fri, 22 Oct 2004 14:02:26 -0400

Eric,

    It may be rediculous to assert that we should remove something from the
LDP specification because nobody is using it only to then say that - if 
someone
is using it - they should use the usual IETF process to put it back in.

    The problem here is that an outside organization defined a 
dependency on a
piece of the protocol then believed to be part of the standard. We could 
uphold
the traditional IETF argument and say - "where then is the implementation?"

    However, if we want to do that, then I would strongly urge that we 
hold off
pushing LDP to Draft Standard until we have "sufficient operational 
experience."
The fact that we have other organizations who want to use some of the 
currently
(at least allegedly) unimplemented features of the current specification 
is probable
cause to suspect that the current Proposed Standard has not yet received 
enough
of an experiential work-out.

    So, either we allow that an external dependency constitutes a "use" 
under the
aegis of the IETF process, or we defer progressing the Proposed Standard at
this time.

--
Eric Gray

---

From: Eric Rosen <[email-masked]>
Date: Fri, 22 Oct 2004 14:31:24 -0400

> It may  be ridiculous to assert  that we should remove  something from the
> someone is  using it - they  should use the  usual IETF process to  put it
> back in. 

That is a somewhat misleading paraphrase of my position. 

I believe that they have specified a  new use for a codepoint which has been
assigned  but not  used, and  I don't  see why  that should  be  treated any
differently than a request for a new codepoint. 

Since they don't  have deployment yet, this seems like a  good time for them
to fix  their specs  and remove the  unfortunate dependency.  It  seems like
there are many ways  for them to do this, as there  is no real dependency on
the semantics of the Host Address FEC.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 22 Oct 2004 14:54:32 -0400

Eric,

It specifies a use for a codepoint documented in a published standards 
track RFC.  It's no different than using a published codepoint in any 
other  standards track RFC.

There's no established WG consensus to remove the FEC from LDP.  It was 
proposed in the initial revision of the 3036 update, but then the change 
was removed after several people spoke up in favor of retaining the FEC.

If it turns out the WG consensus is to remove the FEC, then Ina will have 
to restore the two changes she removed, including changing the semantics of 
the Prefix Address FEC to provide equivalent functionality.

But at this point, no such consensus exists.

Cheers,
Andy

-----------

---

From: Eric Rosen <[email-masked]>
Date: Fri, 22 Oct 2004 15:42:12 -0400

> the Prefix Address FEC to provide equivalent functionality. 

We  really  need  to get  clear  on  the  technical  issue here.   The  ONLY
difference  between the Host  Address FEC  and an  Address Prefix  FEC which
specifies a /32  is the following.  If these two FECs  are both present, and
each is bound to a different LSP, then a packet whose IP destination address
matches both of these FECs will be assigned to the LSP with the Host Address
FEC.  Further,  a packet whose IP  destination address does  not match these
FECS cannot be assigned to the LSP  with the Host Address FEC, though it can
be assigned to the  LSP with the Address Prefix FEC (i.e.,  the LSP with the
Host Address FEC can only be used  for packets which are destined to the LSP
egress, not for packets which are to be further forwarded by the LSP egress).

Hence it simply does not make any  sense to say that if the Host Address FEC
is  eliminated,  the Address  Prefix  FEC needs  to  be  changed to  provide
equivalent functionality!   The reason for eliminating the  Host Address FEC
is to eliminate the associated functionality, because that functionality has
never been used.

It's  already been  stated that  the  MPLS Forum  work could  have used  the
Address Prefix FEC  with a /32 prefix.   If that's the case, then  it is not
using the Host Address FEC correctly.

---

From: Ina Minei <[email-masked]>
Date: Fri, 22 Oct 2004 14:59:04 -0700 (PDT)

> using the Host Address FEC correctly.

	I agree with you that to represent a host address, one could use
an Address  Prefix with a /32 prefix. However, one would then have to
define the error  handling for an incorrect length and the procedures that
must be applied in case one expects to receive a host address but gets a
length different than 32. Why not have a FEC that represents a host
address in this case?

			Ina

---

From: Eric Rosen <[email-masked]>
Date: Mon, 25 Oct 2004 10:45:01 -0400

> length different than 32. Why not have a FEC that represents a host

The question before us is not whether it would be good to have such a thing,
but whether the Host Address FEC as defined in RFC 3036 is that thing.

According to RFC 3036, if an LSP is associated with a host address FEC, then
a packet  can be assigend  to that LSP  only if the packet's  destination IP
address is the same as the "host address" of the FEC. 

As I  have endeavored unsuccessfully to  explain, this was  intended for use
when  the egress  PE needed  to  infer from  a packet's  incoming top  label
whether the packet is addressed to the egress PE or not.

I believe  that the MPLS Forum document  in question does not  adhere to the
rules specified in section 2.1 of RFC 3036, and hence is in violation of the
LDP spec. 

In effect,  they are redefining  the Host Address  FEC to meet  their needs.
The only thing that enables them to  get away with this is the fact that the
Host Address FEC, as defined in RFC 3036, is not used. 

I don't care  if they use a /32  Address Prefix FEC or if  they define their
own FEC  that always has  a /32  address.  I just  would like to  follow the
proper process here, and I think  the proper process is for them to specify,
in their own documents, the FEC  they want, and then request a codepoint for
it. 

Given that  the Host Address  FEC as  specified in RFC  3036 is not  used, I
think it must be removed before progression to Draft Standard.