[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Graceful restart - inter-protocol dependencies
Rick....you must differentiate the co-cs mode case from the co-ps case.
They both belong to the co mode BUT there are very significant
differences....indeed, the 3 network modes arise by the way constraints
are applied to a unified networking model (and if you are active in ITU
then check out what is happening in SG15 on this topic).
In the co-cs mode case the constraints mean the following behaviours are
FORCED:
- control/management OOB.....this means that in a co-cs network
system there is more than 1 data-plane network. This has major
implications on the design of these networks (wrt addressing, security,
resilience, stability, etc);
- the only traffic carrying trail constructs allowed are p2p and
p2mp, ie no merging is possible......and these are the ONLY trail
constructs that allow deterministic traffic/fault/performance management
anyway;
- a trail MUST complete between trail source and sink points as
this is where the characteristic information is processed that looks
after the integrity of the trail (eg OAM stuff);
- there are no QoS/traffic classes.....this looks like a throwaway
remark but it's extremely important.....especially when considering
network builder services, ie when building a client layer topology this
defines performance inheritance behaviour;
- true client/server relationships can exist, ie complete
functional decoupling of client and server layer networks....again
absolutely critical for a whole raft of factors (security,
scalability,...) when considering network builder services.
Now add these observation to my previous ones (eg the importance of the
trail object (which I think many folks still don't really get), and how
once created it gets decoupled from the routing process) and you start
to get the picture of the required behaviour of a co mode technology.
Its jolly hard to get things wrong with the co-cs mode but this is not
true for the co-ps mode. However, there is no reason why the co-ps mode
should not reproduce the important behaviours, and in doing so re-use
the components (eg similar OOB design, signalling), that apply to co-cs
mode technologies.....indeed when we kicked off the ASON work this was
precisely what was in our minds. And as a more general observation
here: When folks talk about convergence there is a lot of confusion as
to what this really means....it for sure does NOT mean that (i) 1
network mode/technology can do it all, nor does it mean (ii) one can
somehow 'functionally crunch' all 3 networking modes and treat them
alike. What is does mean however is that we don't need lots of
different technologies belonging to the SAME mode (as this creates
duplication/waste and leads to stovepipe services and downstream
migration/interworking problems), but we do need all 3 modes working in
concert....and wrt to this latter observation we can apply sensible
component re-use, ergo the comment above wrt ASON.
And the 'service' reason this is required is because (as we sunset PDH,
lower rate SDH VC12, FR and ATM layer networks) we need a network
builder service capability at bit rates smaller than SDH VC4.
It's taking a lot longer then we expected for the above to be better
understood but I can see strong signs now emerging that we are starting
to get there.
regards, Neil
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of
> ruiquan.jing@ties.itu.int
> Sent: 30 September 2005 03:17
> To: ccamp@ops.ietf.org
> Subject: RE: Graceful restart - inter-protocol dependencies
>
>
>
>
> Hi David,
>
> We should specify which version of RSVP we are talking. What
> I have said is
> about GMPLS RSVP-TE as used in ASON.
>
> When there is a failed link within the network, the ingress
> node will know the
> failure by transport plan OAM mechanism such as SDH path
> layer AIS, or by RSVP- TE Notify message. And usually these
> mechanisms are faster than routing
> protocol convergence speed. After the ingress node knows
> which link or route
> has failed, it will do the rerouting while excluding the
> failed link or route.
>
> Hope I say it clearly :-)
>
> Rick
>
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of
> David Charlap
> Sent: Thursday, September 29, 2005 10:35 PM
> To: 'IETF MPLS List'; 'IETF CCAMP List'
> Subject: Re: Graceful restart - inter-protocol dependencies
>
> But RSVP doesn't work this way. It is a soft-state protocol.
>
> If the route table changes such that the next-hop interface
> changes, RSVP is
> supposed to reroute the connection accordingly.
>
> This probably won't happen if the next-hop is a strict-hop in
> an ERO, but it
> can easily happen if the next-hop is loose or if the LSP is
> signaled without
> an ERO (meaning routing is consulted to determine the
> next-hop to the egress
> node.)
>
> If there is a paragraph in an RFC that says RSVP-TE should
> ignore all route- table changes once an LSP comes up, I missed it.
>
> -- David
>
> Jing Ruiquan wrote:
> > I think only the originating node should do the rerouting with
> > RSVP-TE .At the same time, all the nodes will converge their IGP
> > routing
> data base.
> >
> > Rick
> >
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> > Behalf Of David Charlap
> > Sent: Thursday, September 29, 2005 2:37 AM
> > To: IETF MPLS List; IETF CCAMP List
> > Subject: Graceful restart - inter-protocol dependencies
> >
> > Is there any point to implementing RSVP-TE's graceful
> restart without
> > also implementing graceful restart for routing protocols?
> >
> > On the one hand, RSVP doesn't require routing to recover LSPs. It
> > knows the next-hop interface, because of the preserved data-plane
> connection.
> > Whatever other information it may need, the switch can either
> > preserve this information or recover it from a neighbor using the
> > RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03).
> >
> > On the other hand, nodes more than one hop upstream of the failure
> > will detect the loss of routing-connectivity to the failed
> node if IGP
> > graceful restart is not also implemented. They may reroute the LSP
> > away from the failed node, or tear it down altogether, even
> though the
> > data plane is still active and RSVP graceful restart is
> recovering the
> control-plane state.
> >
> > An originating node may consider the destination unreachable, as a
> > result of losing the routes even though the data-plane for
> the LSP is
> > still up (which can be confirmed via OAM.)
> >
> > A transit node, when processing an loose ERO-hop, may choose to
> > reroute or fail the LSP if its local topology information says that
> > the failed (and
> > restarting) node is not available. It might even choose to do this
> > for an established LSP, as a result of Path refresh processing.
> >
> > My questions are:
> >
> > 1: Does this mean it's pointless to use RSVP graceful
> restart without
> > also using IGP graceful restart (for whatever IGP is active).
> >
> > 2: Is IGP graceful restart sufficient to prevent this problem? For
> > instance, OSPF's restart procedure requires all
> preserved state to
> > be thrown away if a topology change is detected.
> >
> > 3: An originating node can use OAM to validate the data plane of an
> > LSP, and choose to ignore what routing tells it about the
> > destination's reachability. But what about transit
> nodes? As far
> > as I know, MPLS doesn't support segment-OAM, and it would be
> > prohibitive for every transit node to run its own OAM streams
> > to detect self-to-end connectivity.
> >
> > 4: Are there other solutions to this problem?
> >
> > One possible solution might be route-pinning, but RSVP
> doesn't have a
> > built-in mechanism for this. The usual workaround (signal the LSP,
> > requesting route-recording, then turn the RRO into an ERO for
> > subsequent
> > refreshes) can work, but are there situations where even
> this would be
> > insufficient to prevent a transit node from rerouting/tearing the
> > connection in this particular situation (where RSVP is doing a
> > graceful restart but the IGP is not)?
> >
> > -- David
>
>
>
>
>