Subject: [CCAMP] offline answer to comments on draft-zhang-ccamp-srlg-fa-configuration-02

From: Oscar González de Dios <[email-masked]>
Date: Thu, 28 Apr 2011 15:19:08 +0200

Hi all,
                After the presentation of draft-zhang-ccamp-srlg-fa-configuration-02 in last ccamp meeting in Prague, there was a couple of questions from Igor that, due to lack of time, could not be discussed. Please find bellow the questions (taken from the minutes) and additional comments

>Igor Bryskin: two things, what happens after you establish an LSP and someone adds an SRLG on a transit link?
>Oscar Gonzalez de Dios: then you have to recollect it.
>Igor Bryskin: but this is nontrivial. This is a general problem, how you propagate modified information along the path.

The idea is that by periodic PATH messages with RRO the updates of the SRLG information are recollected. As stated in RFC 3209 about the applicability of the RRO (see section 4.4.2 ), " Second, an RRO collects up-to-date detailed path information hop-by-
   hop about RSVP sessions, providing valuable information to the sender  or receiver.  Any path change (due to network topology changes) will  be reported." Thus, changes in the SRLG would be reported.

>Igor Bryskin: I understand exactly the motivation; we have the same issue to provide SRLG information to the higher layer. My second question is what happens if you assign nothing to the link, you still need to provide information to the higher layer. If you had two >FAs sharing the same link and you have no SRLGs assigned to the link?
>Oscar Gonzalez de Dios: nothing.
>Igor Bryskin: you need to provide something at least the link ID.
>Deborah Brungard: okay we are running out of time, please discuss further on the list.

I  stick to my previous answer. In the RRO you collect the path information.  So if you don't have the SRLG information, because none is defined, you can still use the details of the path coming from the RRO . I think you  don't have to 'invent' a SRLG to the higher layer.

Best Regards,

                               Óscar

________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 28 Apr 2011 13:34:37 +0000

Oscar,

Here is the problem with your proposal. Suppose you have an LSP going through:

A-B---C----D---E----F,

There is something in the original Path message requiring to collect SRLGs on all links. Suppose after the LSP is set up, the operator assigns an additional SRLG on link DE. Hence, there is a need to re-collect SRLGs along the path. Suppose, node D send s a Notify message to node A instructing to do so. This would trigger a new Path message originated by node A. Node B, however, will see no difference in this message compared to the previous one it has received and simply swallow it as a refresh.

Cheers,
Igor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Oscar González de Dios
Sent: Thursday, April 28, 2011 9:19 AM
To: CCAMP ([email-masked])
Subject: [CCAMP] offline answer to comments on draft-zhang-ccamp-srlg-fa-configuration-02

Hi all,

Best Regards,

                               Óscar

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 28 Apr 2011 16:14:02 +0200

On 28/04/2011 15:34, Igor Bryskin wrote:
> A---B---C----D---E----F,
> There is something in the original Path message requiring to collect 
> SRLGs on all links. Suppose after the LSP is set up, the operator 
> assigns an additional SRLG on link DE. Hence, there is a need to 
> re-collect SRLGs along the path. Suppose, node D send s a Notify 
> message to node A instructing to do so. This would trigger a new Path 
> message originated by node A. Node B, however, will see no difference 
> in this message compared to the previous one it has received and 
> simply swallow it as a refresh.
>

Igor, Oscar, all

I may be missing something, but if node A changes the message_id / epoch 
of the path message, wouldn't this force the intermediate nodes to fully 
process the message considering it a trigger? Browsing RFC2961 4.5 seems 
to state this would be possible?

thanks
R.

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 28 Apr 2011 14:27:55 +0000

Good point,

All I was saying that the document need to have a section describing what to do in the case when the set of SRLGs has been changed after the LSP is set up.

Igor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: Thursday, April 28, 2011 10:14 AM
To: [email-masked]
Subject: Re: [CCAMP] offline answer to comments on draft-zhang-ccamp-srlg-fa-configuration-02

A-B---C----D---E----F,

Igor, Oscar, all

I may be missing something, but if node A changes the message_id / epoch of the path message, wouldn't this force the intermediate nodes to fully process the message considering it a trigger? Browsing RFC2961 4.5 seems to state this would be possible?

thanks
R.

---

From: Oscar González de Dios <[email-masked]>
Date: Thu, 28 Apr 2011 16:34:25 +0200

Yes, good catch Ramon, Igor,

                I fully agree on adding  a section describing what to do in case of change of SRLG information. For the solution, I support Ramon proposal of the change in the MESSAGE_ID object to trigger the processing of the PATH message and recollect the SRLG info.

                And also, recalling Deborah comments, there is still further work to do on operational issues.

                Thanks again Ramon and Igor for the comments and suggestions

                Óscar

De: [email-masked] [mailto:[email-masked]] En nombre de Igor Bryskin
Enviado el: jueves, 28 de abril de 2011 16:28
Para: Ramon Casellas; [email-masked]
Asunto: Re: [CCAMP] offline answer to comments on draft-zhang-ccamp-srlg-fa-configuration-02

Good point,

Igor

A-B---C----D---E----F,

Igor, Oscar, all

thanks
R.