The MPLS WG Archive

[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index][Thread Index][Author Index][Subject Index]

[PWE3] MPLS PID

From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Date: Thu, 27 Mar 2003 10:12:08 -0800
Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>, "'George Swallow'" <swallow@cisco.com>, "W. Mark Townsley" <townsley@cisco.com>, "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>, "'mpls@uu.net'" <mpls@UU.NET>, tnadeau@cisco.com

>Shahram,
>
>-> First of all I meant computing CRC over the first 20 byte of 
>-> payload header
>-> and comparing it to the suspected IP CRC in octets 11 and 12 
>-> of the payload.
>-> If they match then it is IPv4, if not it is something else 
>-> (similar procedure for IPv6)
>-> 
>-> Secondly I am proposing it now. Is there a problem? 
>
>  Yes. There is a problem. First of all relaying on CRC to
>  figure out the *type* of payload is not at all advisable.
>  One could produce (there is a remote possibility) a payload
>  which is not IPv4 or IPv6 but the CRC can be matched to
>  the payload of first 20 bytes to the bytes in 11 & 12.
>
>  RFC1071 uses 16 bit's one's compliment, which we all know
>  that won't catch all the bit errors/flips.

Agree, but isn't it better than relying on the first 4 bit of the
payload to indicate IPV4/v6? The possibility of a non-IP
payload to have its first 4 bits to be equal 2 or 4 is 2/16=12.5% while
the possibility of a 20 byte payload to match a particular CRC-32
is much mush lower.

The reason I mentioned this example was that some argued that all
ECMP methods must be supported.

-Shahram

>
>Venkata.
>