Subject: RE: Proposed response to OIF on OSPF ENNI

From: "Drake, John E" <[email-masked]>
Date: Tue, 25 Jul 2006 14:28:09 -0700

Snipped
 
 Regarding Topic 2:

	Again I ask, wouldn't it be better to look at this document
which has been implemented by many vendors, and successfully
interoperability tested many times over many years to see what can be
leveraged instead of starting from scratch? 

	JD:  I noticed that Jonathan has put in this plug several times.
I am wondering whether these events are truly interoperability tests, in
the sense that the IETF uses the term, or rather rigged demos?  I seem
to remember that the OIF characterized itself as a marketing
organization.  

________________________________

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 25 Jul 2006 17:39:14 -0400

Hi John,
 
If you wish to discuss how the tests were carried out, you can talk to
the 
7 major carriers that provided lab sites and the 13 router and switch
vendors that participated
in the 2005 demo.
 
In what sense does IETF use the term interoperability test? Is there an
RFC on this?
I was unaware that IETF ran interoperability tests.
 
Cheers,
 
Lyndon

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Tuesday, July 25, 2006 2:28 PM
To: [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI

 Snipped
 
 Regarding Topic 2:

---

From: "Payam Torab" <[email-masked]>
Date: Tue, 25 Jul 2006 18:11:01 -0400

In the e2e recovery signaling draft
(draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt), there is a procedure
defined for a node on the shared restoration path to notify other nodes
regarding the working LSPs that become vulnerable as a result of switching
to the shared restoration path.
 
It seems there is a similar need to notify these nodes once the shared
restoration path becomes available again. Is this mechanism defined
anywhere?
 
Thanks,
Payam

---

From: [email-masked]
Date: Wed, 26 Jul 2006 00:25:20 +0200

hi 

your question is in a shared mesh case, are the ingress nodes (N-1) 
notified about the use of the recovery path by the remaining ingress node 
part of the same shared mesh group

answer is yes - you can notify the other ingresses by sending a PathErr of 
Notify msg - the error code defined for this case is "Notify Error/LSP 
Locally Failed" - 

much thanks,
- dimitri.

"Payam Torab" <[email-masked]>
Sent by: [email-masked]
26/07/2006 00:11
 
        To:     <[email-masked]>
        cc:     "'Dave Walters'" <[email-masked]>
        Subject:        shared mesh restoration - e2e recovery signaling 
draft

In the e2e recovery signaling draft 
(draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt), there is a 
procedure defined for a node on the shared restoration path to notify 
other nodes regarding the working LSPs that become vulnerable as a result 
of switching to the shared restoration path.

Thanks,
Payam

---

From: "Payam Torab" <[email-masked]>
Date: Tue, 25 Jul 2006 18:47:50 -0400

The question is availability of a mechanism once the shared restoration path
becomes available again - we would like to let the other ingress nodes know
their LSPs are no longer vulnerable (if they have not picked a different
restoration path already); Referring to the scenario on page 20 of the
draft, it is desirable for node E to notify H that the shared restoration
path H-E-F-G-K is available again.

A notify message with the error code/sub-code "Notify Error/LSP Recovered"
could be a good solution, but it does not seem to be used by the draft in
this context.

Thanks,
Payam

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Tuesday, July 25, 2006 6:25 PM
> To: Payam Torab
> Cc: [email-masked]; 'Dave Walters'; [email-masked]
> Subject: Re: shared mesh restoration - e2e recovery signaling draft
> 
> 
> hi 
>

---

From: [email-masked]
Date: Wed, 26 Jul 2006 00:52:46 +0200

ok you are referring to the case when the LSP reverts back to the primary
same business but instead make use of the "Notify Error/LSP Recovered" 
code

this is documented in section 12 (last part)

thanks,
- dimitri.

26/07/2006 00:47
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, "'Dave Walters'" 
<[email-masked]>, <[email-masked]>
        Subject:        RE: shared mesh restoration - e2e recovery 
signaling draft

The question is availability of a mechanism once the shared restoration 
path
becomes available again - we would like to let the other ingress nodes 
know
their LSPs are no longer vulnerable (if they have not picked a different
restoration path already); Referring to the scenario on page 20 of the
draft, it is desirable for node E to notify H that the shared restoration
path H-E-F-G-K is available again.

Thanks,
Payam

---

From: "Payam Torab" <[email-masked]>
Date: Tue, 25 Jul 2006 19:11:57 -0400

Dimitri- indeed, the last case under Section 12 is the case of interest, but
we are talking about the very last step of the process (last two sentences
in Section 12):

   3. Finally, de-activate the protecting LSP by setting the S bit to 1  
      in the PROTECTION object sent over the protecting LSP.

It is not clear (not documented) how the ingress nodes for other working
LSPs should know after this step that the protecting LSP is available again
and they are not vulnerable anymore. I hope this clarifies the question.

Thanks,
Payam

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 6:53 PM
> To: Payam Torab
> Subject: RE: shared mesh restoration - e2e recovery signaling draft
> 
> 
> ok you are referring to the case when the LSP reverts back to 
> the primary same business but instead make use of the "Notify 
> Error/LSP Recovered" 
> code
> 
> their LSPs are no longer vulnerable (if they have not picked 
> a different restoration path already); Referring to the 
> scenario on page 20 of the draft, it is desirable for node E 
> to notify H that the shared restoration path H-E-F-G-K is 
> available again.
> 
> A notify message with the error code/sub-code "Notify 
> Error/LSP Recovered" could be a good solution, but it does 
> not seem to be used by the draft in this context.
> 
> Thanks,
> Payam
> 
>

---

From: [email-masked]
Date: Wed, 26 Jul 2006 01:24:09 +0200

notify the other (N-1) ingresses by sending a PathErr of Notify msg - the 
error code defined for this case is "Notify Error/LSP Recovered" - applies 
here, i didn't list it in the draft because the mechanism of bringing back 
the recovery LSP availability is not specific to shared mesh it applies 
whenever the recovery LSP is not available for whatever reason

thanks,
- d.

26/07/2006 01:11

Dimitri- indeed, the last case under Section 12 is the case of interest, 
but
we are talking about the very last step of the process (last two sentences
in Section 12):

It is not clear (not documented) how the ingress nodes for other working
LSPs should know after this step that the protecting LSP is available 
again
and they are not vulnerable anymore. I hope this clarifies the question.

Thanks,
Payam