Subject: Re: [mpls-tp] ACH TLV

From: Curtis Villamizar <[email-masked]>
Date: Mon, 07 Jun 2010 13:06:09 -0400

Vishwas,

This is almost two months old now - I'm catching up on some WG email
that I seemed to have missed.  Sorry for the delay.

In other protocols two bits are used:

  1.  optional or manditory
  2.  transitive or non-transitive

There are four cases of unrecognized packets:

  manditory transitive
  manditory non-transitive

    If a TLV is marked manditory and not understood, the packet is
    considered in error.  If the usual error procedure is silently
    drop, which is rarely the case, then to that.  More oftent the
    error procedure involves returning an error message.  There is
    usually a means to indicate that something was malformed or not
    understood in a TLV but at worst an error subcode is needed.

  optional transitive

    If a TLV is optional and not understood it may be ignored.  If it
    is transitive it must be passed on unchanged.

  optional non-transitive

    If a TLV is optional and not understood it may be ignored.  If it
    is nontransitive it must be removed from the packet.

If a TLV is understood, then these two bits are generally not
consulted.  For example, if the packet is not to be forwarded by an
LSR that understands the TLV for some reason, then any information
needed by the conditional should be in the TLV itself.

The wording in BGP could be used.

Also see one comment inline.

Curtis

In message <[email-masked]>
Vishwas Manral writes:
>  
> Hi,
>  
> I noticed the http://www.ietf.org/proceedings/10mar/minutes/pwe3.txt
> some things were not clarified in the draft. The idea was to get the
> same on the list. As the ideas were never presented on the list let me
> bring them forward here:
>  
> 1. We had the proposal of one bit to say, what to do if a TLV is
> unknown. The idea was as we move forward we may have new TLV's which
> older implementations may not recognize. By using a bit we are
> allowing different behavior, if the bit is set we can ignore the
> packet else we will silently drop the packet.

I think you meant igonre the TLV (not ignore the packet) or silently
drop the packet.

> The same has been done in most other similar existing RFC's like LSP
> Ping, where instead of a bit a range is allocated. This is very
> essential if we want to allow extensions of the MPLS-TP functionality.
>  
> 2.  As we want to allow the case where not all TLV's can be
> authenticated (example say a TTL TLV), we give the option of a bit to
> signal the same.
>  
> 3. The older padding TLV as mentioned earlier was of no use (it was
> used for padding to byte boundaries but then it itself was not). One
> way was to actually remove the padding type altogather.
>  
> The idea however was that we will never use 0xFF as the first byte of
> the type field. So if we had to put a 2 byte padding, we would put 2
> bytes of 0xFF. The parser would go to the type and if the first byte
> of type and if the value is 0xFF it will skip it and all following
> 0xFF values.
>  
> 4. I also noticed comment that the authentication TLV can be moved to
> a seperate Security RFC. It can be done that way, but the entire idea
> of this draft was to have a single draft having all possible TLV's.
>  
> Thanks,
> Vishwas
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp