[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Source routed Notify message
Hi Vishal,
thanks for your reply; I'll try to explain myself a
little better.
Let me quote the draft-ietf-ccamp-gmpls-recovery-functional-01.
"
o Switchover: The action when an end node detects a failure
in the working path is as follows: Start receiving from
the protection path. At the same time, send a switchover
request message to the other end node to enable switching
at the other end.
[...]
GMPLS signaling mechanisms may be used to (reliably) signal the
switchover request. *This message may be forwarded along the
protection path if no other routing intelligence is available in the
network.*
"
It seems to me that it is foreseen that, in protection/restoration
scenario, tail end nodes exchange messages in order to share information.
Now this is a scenario very similar to the one I depicted in my e-mail.
From my understanding the sentence "This message may be forwarded along the
protection path if no other routing intelligence is available in the
network." means that mechanism other that "normal" Ip routing should be
used in order to inform efficently the other tail end about something that
happens in the network.
Again it seems to me that the more efficent way to do that is use a concept
that is widley used and developed in GMPLS namely the ERO. I'm not saying
that ERO obj should be mandatory in Notify messages but it seems to me that
usage of ERO in notify should be allowed.
Other answers in line.
Regards,
Diego
"Vishal Sharma" <v.sharma@ieee.org> on 10/11/2003 21.50.41
Please respond to <v.sharma@ieee.org>
To: "Diego Caviglia" <Diego.Caviglia@marconi.com>, <ccamp@ops.ietf.org>
cc:
Subject: RE: Source routed Notify message
Diego,
I think the problem you're looking at is still a bit ill-defined.
(BTW, you have two nodes labeled H in the fig. below,
which one is A trying to inform?)
[dc] My fault.
Assuming that the lower rightmost node is H, here are
a few questions...
[dc] Absolutely yes.
Are you assuming, for example, that the DCN used for the SDH/SONET
network uses an associated control plane (with the same
topology as the data plane)?
[dc] Yes. AFAIK the most likely transport DCN scenario uses embedded
control channel.
That control channel can be easily implemented using DCC.
If not, then the IP message from A should be able to find its way
easily enough to H, via the DCN.
[dc] It depends on how the external part of the DCN interconnects the TNE.
In general if a failure affecting the DCN (here I'm supposing that the data
link failed was carrying also control channels) occurs the sender of the
packet can not be sure about the delivery of the packet or at least can not
be sure that the packet will be delivered following the best route.
Further, if "lower layer" data plane mechanisms are at
work, then the same mechanisms would have informed H as well,
so why does A need to do anything special to inform H?
[dc] This is not necessary true. In fact in my previous mail I specified
that the failure was unidirectional that means that node H is not able to
see the alarm.
In any case, since the Notify message is an IP packet, it could
always be IP source-routed (if A so desired), with some attendant
limitations on size of course.
[dc] Yes and in fact I'm worried about the limitation.
-Vishal
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Diego Caviglia
> Sent: Monday, November 10, 2003 8:17 AM
> To: ccamp@ops.ietf.org
> Subject: Source routed Notify message
>
>
> Hi all,
> is there anyone interested in having source routed, may by
> means of standard ERO obj, Notify [RFC3473] message?
>
> The motivation to use a source routing mechanism for Notify is avoiding
> OSPF convergence time during a network failure.
>
> The scenario I've in mind is the following:
>
> A---------------B---------------C
> | | |
> | | |
> | | |
> D---------------E---------------F
> | | |
> | | |
> | | |
> G---------------H---------------H
>
> Suppose there is a LSP (SDN/SONET) from H (Ingress) to A (Egress) and an
> unidirectional failure occours between C and F in the H-->A direction.
> Low layer mechanism (e.g AIS), informs A that a failure has
> occourred. TNE
> A wants to notify H about the failure but OSPF tables have not
> been updated
> thus TNA A knows that "normal routing" will have some problem in
> delivering
> the Notify to TNE H.
>
> A source routed path calculated using Link diversity with respect to the
> failed LSP can avoid OSPF convergence time and inform efficently TNE H
> about the failure of the LSP.
>
> That can be done either using the source route of the Ip header or using
> the ERO object. The former has some limitation while the latter is
> larghely used in GMPLS.
>
> Ragrds
>
> Diego
>
>
>
>