The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <4.3.2.7.2.20030317233654.05434398@paris.cisco.com>, Jean Philippe V
asseur writes:
> 
> 
> This only drawback with the Resv RRO message would be the existence of mid 
> point LSRs non supporting the soft preemption draft as they might no detect 
> the Resv message change (RRO preemption pending bit set) and as such would 
> not trigger an immediate refresh. This would introduce some delay in the HE 
> notification.
> 
> JP.


Our RSVP guys tell me the same LSR we are both concerned about that is
blind to RRO changes such as local-protect-inuse also barfs on unknown
bits in the session object so if one of them was in the path the
initial PATH message would have to remove the request for
soft-preemption to get the LSP to come up in the first place.  So this
would work for LSR software in the field and just work better when
that software is upgraded.

This brings to mind two useful changes to RFC3209 or another document
could be written and later merged in.  Either the semantics of the
SESSION-ATTRIBUTES Flags should have a note that unknown bits should
be ignored.  In the description of the RRO, a note should be made that
an LSR must pass on changes to the IPv4/IPv6 flags immediately and
must ignore flags that are not understood.  A small section could be
added giving guidelines for well written extensions.  These would have
a request bit in the SESSION-ATTRIBUTES Flags, a capabilities bit in
the RRO IPv4 or IPv6 flags, and if needed one or more status bit (such as
available and inuse for local-protect, or pending for soft-preempt).

It would be easiest to write an extensions mechanism draft and then
fold it into RFC3209 later.  If we were worried about too few bits
(and I'd prefer we didn't go this route) we could add an extension
request object with a 32 bit flag, and a 32 bit extension capabilities
and flags subobject to RRO.  I'd prefer keeping the number of
extension to mimimum and only doing things with very clear benefits.

I would hope that extensions would be rare and if proved useful would
be folded into an update to RFC3209.  Extensions have to be rare
because we only have 8 bits available so we should be choosey.  I
think soft preempt is a valuable extension.  Its need has been stated
by ISPs and its need has been proven in practice.  More than one has
brought this up, but not on the list, the author of this document is
from GX though, so this is from an SP.

Curtis