Subject: [mpls-tp] ACH TLV

From: Vishwas Manral <[email-masked]>
Date: Fri, 16 Apr 2010 11:24:15 -0700

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.

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