Vach Kompella | 4 Jun 2004 18:30

Interface parameters

We need some text around the interface parameters that defines the
behavior when an unknown interface parameter is seen.  E.g., some
vendors have implemented FCS retention, and there is apparently no way
to turn it off.  Any code that pre-dates FCS retention may or may not
work with this up-level code because:
  - there are mandatory interface parameters
  - there are optional interface parameters
  - there is no way to tell if, for a PW, an interface parameter is
optional or mandatory
  - any new interface parameter may also be mandatory or optional

So it is fine for the FCS retention draft to say that it is backwards
compatible with any pre-FCS retention implementation.  However, that is
true only if the behavior of the older implementations is to ignore any
unknown interface parameters.  This is what draft-ietf-pwe3-control
says:

  5.4. Interface Parameters Field

     This field specifies interface specific parameters. When
applicable,
                                                         ^^^^^^^^^^^^^^^
     it MUST be used to validate that the PEs, and the ingress and
egress
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     ports at the edges of the circuit, have the necessary capabilities
to
     interoperate with each other. The field structure is defined as
     follows:

(Continue reading)

Luca Martini | 8 Jun 2004 09:11
Picon
Favicon

Re: Interface parameters

Vach,

The text you are asking for is one paragraph below at :
"The Length field is defined as the length of the interface parameter
   including the parameter id and length field itself. Processing of the
   interface parameters should continue when encountering unknown
   interface parameters and they MUST be silently ignored."

The point here is that there is an assumption that all REQUIRED 
parameters for existing PW types have been defined.
Any new interface parameters will fall into two categories :

1) A new PW type is defined , and it requires new "REQUIRED" interface 
parameters.
2) A new option on an existing PW is created , and this will be by 
definition optional to maintain backward compatibility.

In either case the control document is fine, and both cases will require 
new separate drafts.

As far as the text below, maybe I can make it a little clearer and 
change the "When applicable" to "When REQUIRED by the definitions below"
Or something of the sort.

Luca

Vach Kompella wrote:

>We need some text around the interface parameters that defines the
>behavior when an unknown interface parameter is seen.  E.g., some
(Continue reading)

Shah, Himanshu | 4 Jun 2004 20:34

RE: Interface parameters

This is exactly what we propose in 
draft-shah-pwe3-control-protocol-extension-01.txt.

A mechanism to dynamically exchange/negotiate 
capabilities/parameters in a backward compatible fashion.

/himanshu

> -----Original Message-----
> From: Eric Rosen [mailto:erosen <at> cisco.com]
> Sent: Friday, June 04, 2004 2:02 PM
> To: vach.kompella <at> alcatel.com
> Cc: pwe3 <at> ietf.org
> Subject: Re: [PWE3] Interface parameters 
> 
> 
> 
> Perhaps  it is  a  mistake  to try  to  use the  Interface  
> Parameters as  a
> generalized  capabilities  negotiation  mechanism.  Has  
> consideration  been
> given to an alternative, such as using a new LDP TLV? 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
(Continue reading)

Eric Rosen | 4 Jun 2004 20:01
Picon
Favicon

Re: Interface parameters


Perhaps  it is  a  mistake  to try  to  use the  Interface  Parameters as  a
generalized  capabilities  negotiation  mechanism.  Has  consideration  been
given to an alternative, such as using a new LDP TLV? 

Gmane