Re: Turnipp - a merger proposal

[Lyman Chapin <[e-mail]>]

>Date: Fri, 8 Apr 94 14:19:35 JST
>From: [e-mail] (Paul Francis)
>To: [e-mail], [e-mail]
>Subject: Re: Turnipp - a merger proposal
>Cc: [e-mail], [e-mail], [e-mail]
>
>>  >
>>  >The inconveniency of doing source routes with variable length address show in
>>  >CLNP, where routers have to look inside the option field to determine the
>>  >currently active destination address - not to mention that poor
>>  >implementations that would not examine the option field might generate loops.
>>  
>>  Christian,
>>  
>>  You're not going to like this comment, but an implementation that does not
>>  at least recognize the existence of a type-2 option field is not only poor,
>>  it's non-conforming;  it can discard the packet if it sees an option it
>>  does not support, but it cannot ignore the presence of a source route
>>  option field and forward the packet without looking into it.
>>  
>
>Has CLNP changed since RFC994?  RFC994 says that partial source routing 
>is type 3, and therefore the packet can be forwarded without the router 
>looking into the option. 
>
>PF

Paul,

You're right - partial source routing is type 3, complete source routing
is type 2.  But that's why partial source routing doesn't work for CLNP
(routing loops), and why we have an amendment in progress in SC6 to change
PSR to be a type 2 option (and at the same time, allowing the entries
in the PSR option to be NETs - effectively, area prefixes - so that PSR
can be used to support provider selection).  I don't know of anyone who
uses the current (broken) PSR in CLNP, precisely because of the possibility
of generating loops.  [In my response to Christian, I was assuming complete
source routing.]

- Lyman