[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Misconnections during activation of backup LSPs
Hi Kohei et al,
<Kohei Shiomoto wrote:>
> Yes, my concern is misconnection during activation of backup LSP
> procedure originally raised by Yoshihiko (See
> http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00079.html). Similar
> situation can occur not only for P&R context but also for more general
> context when preemption takes place. Solutions should be explored in
> more general context and several solutions could be developed. I feel
> that the P&R solution document should also address the problem and give
> the solution referring some documents on preemption.
I think Kohei brings up an excellent point.
In fact, it would be good to provide solutions not only to
avoid misconnections, but to also detect and remove them in
a timely manner, since very simple malfunctions can lead to
misconnections (even if all protocols operate as desired).
[Having spent some reasonable time thinking about these issues,
I volunteer to, and will be happy to, provide inputs both to the P&R
solution documents as well as to any subsequent documents on this
issue that we as a WG decide to produce.]
For example, let us consider again Yoshihiro's original example.
A-----------B
\ /
C-------D
/ \
E F
A-B: Primary LSP
A-C-D-B: Secondary LSP
E-C-D-F: Extra (preemptable) LSP
Even if we apply Yoshihiro's suggestion of activating the secondary path
upon the receipt of the Resv message, we can _still_ have misconnections
as follows.
If node C deletes state for the extra-LSP in the control plane upon
receipt of the Path message
(which itself requires further clarification
in the documents, as I will point out in a separate email)
but, due to any malfunction whatsoever, fails to alter the cross-connect in
its
data plane (allowing it to still connect E-C to C-D), we will have a
misconnection.
This occurs as soon as node D, upon receiving the Resv for the
secondary from B (with the Protection obj.) correctly changes its
cross-connect
from C-D --> D-F to C-D --> D-B. This is because traffic will now
(incorrectly) flow from E to B, instead of A to B.
Note that this could _continue indefinitely_ if C's control plane happens to
have gotten disconnected from its data plane (with neither stopping to
work).
Even if not, at the very least, there would be a misconnection
until C receives the Resv message, and then corrects for its previous
mistake, and rectifies its cross-connection in the data plane by changing
it from E-C -> C-D to A-C -> C-D.
Regards,
-Vishal
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Kohei Shiomoto
> Sent: Tuesday, March 09, 2004 5:00 PM
> To: Dimitri.Papadimitriou@alcatel.be; Ong, Lyndon
> Cc: 'Adrian Farrel'; ccamp@ops.ietf.org
> Subject: Re: Opinion sought on drafts being adopted by CCAMP
>
>
> Hi, Dimitri and Lyndon
>
> Yes, my concern is misconnection during activation of backup LSP
> procedure originally raised by Yoshihiko (See
> http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00079.html). Similar
> situation can occur not only for P&R context but also for more general
> context when preemption takes place. Solutions should be explored in
> more general context and several solutions could be developed. I feel
> that the P&R solution document should also address the problem and give
> the solution referring some documents on preemption.
> I feel that "rsvp for e2e recovery" draft is ready for WG document.
>
> --
> Kohei Shiomoto
> NTT Network Innovation Laboratories
> 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
> Phone +81 422 59 4402 Fax +81 422 59 6387
>
>
>
>
> Dimitri.Papadimitriou@alcatel.be wrote:
>
> > lyndon:
> >
> >> -- egress control - yes. The question of what kind of target came
> >> up, BCP, Info, etc -
> >> Whatever kind of document it winds up being, I think one
> >> important result should be marking 3473 as being supplemented
> >> by the new document to avoid any future confusion.
> >>
> >> -- tunnel tracing - yes
> >>
> >> -- rsvp for e2e recovery - there seemed to be still some concerns
> >> at the meeting, so no (not yet)
> >
> >
> > the concern raised (*) by kohei is the following what are
> > the exact steps happening during preemption of LSPs that
> > are using the spare capacity in dedicated/shared re-routing
> > schemes - however, this concern is broader than simply this
> > document - and there are two solutions either the steps
> > are being detailed in this document or preemption is going
> > to be addressed in a specific document and reference will
> > be provided
> >
> > (*) went to discuss privately since we didn't have the time
> > to discuss this point - kohei please correct me if i am
> > wrong here -
> >
> >> -- segment recovery - no (not yet)
> >>
> >> Cheers,
> >>
> >> Lyndon
> >>
> >> -----Original Message-----
> >> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> >> Sent: Thursday, March 04, 2004 3:46 AM
> >> To: ccamp@ops.ietf.org
> >> Subject: Opinion sought on drafts being adopted by CCAMP
> >>
> >>
> >> All,
> >>
> >> At the CCAMP meeting today we discussed making several drafts working
> >> group items. Can you
> >> please express your opinion (yes/no) on whether each of the following
> >> drafts is ready to
> >> become a CCAMP working group draft.
> >>
> >> Feel free to express yes with reservations. If you have reservations
> >> or objections, please
> >> express them on the list. if you need anonymity for your comments
> >> then please filter them
> >> through the chairs.
> >>
> >> Silence will be taken as meaning nothing, so please say what you think.
> >>
> >> GMPLS Signaling Procedure For Egress Control
> >>
> http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-cont
rol-01.txt
>>
>>
>> Generic Tunnel Tracing Protocol (GTTP) Specification
>> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt
>>
>> RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery
>>
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-sign
aling-03.txt
>>
>>
>> GMPLS Based Segment Recovery
>>
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recover
y-00.txt
>>
>>
>> Thank you,
>> Adrian
>>
>>
>