Subject: RE: Opinion sought on drafts being adopted by CCAMP

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 9 Mar 2004 13:34:05 -0800

Hi Adrian,

Comments:

-- 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)

-- segment recovery - no (not yet)

Cheers,

Lyndon

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Thursday, March 04, 2004 3:46 AM
To: [email-masked]
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-control-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-signaling-03.txt

GMPLS Based Segment Recovery
http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-segment-recovery-00.txt

Thank you,
Adrian

---

From: [email-masked]
Date: Tue, 09 Mar 2004 22:55:40 +0100

>    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 -

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: Kohei Shiomoto <[email-masked]>
Date: Wed, 10 Mar 2004 10:00:16 +0900

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

[email-masked] wrote:

> lyndon:
>
>> -- egress control - yes.     The question of what kind of target came 
>> up, BCP, Info, etc -

---

From: "Vishal Sharma" <[email-masked]>
Date: Thu, 11 Mar 2004 02:23:09 -0800

Hi Kohei et al,

<Kohei Shiomoto wrote:>
> 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

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kohei Shiomoto
> Sent: Tuesday, March 09, 2004 5:00 PM
> To: [email-masked]; Ong, Lyndon
> Cc: 'Adrian Farrel'; [email-masked]
> Subject: Re: Opinion sought on drafts being adopted by CCAMP
>
>
> Hi, Dimitri and Lyndon
>
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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Mar 2004 05:03:25 -0000

Hi Lyndon,

>    at the meeting, so no (not yet)

Since the person that raised the concerns at the meeting has given support to this draft
becoming a WG draft, can we move on?

> -- segment recovery - no (not yet)

Would you care to say why?

Thanks,
Adrian