Subject: [CCAMP] GMPLS: RFC 3473 RSVP Notify Request Query

From: Preeti Daundiyal <[email-masked]>
Date: Wed, 10 Nov 2010 11:53:06 +0530

Hi,
   As per RFC 3473, only one notify request object should be send in the RSVP path message.
RFC 3473  :"If a message contains multiple Notify_Request objects, only the first
object is meaningful. Subsequent Notify_Request objects MAY be
ignored and SHOULD NOT be propagated".

But in case of we want to send multiple notify ip address (Upstream notify Ip address as well the downstream notify address), we need to send two notify address. Hence would require, two Notify request object to be send in the RSVP path message.

Query: Can we not avoid this restriction and send multiple notify request object in RSVP path message and intermediate node stores both the address for notification. In this case, How will the intermediate node distinguish between the upstream notification address and the downstream notify address. Is there some extension defined in some other RFC for this purpose or some other means to satisfy this requirement.

Regds,
Preeti

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

---

From: Madhuvanthi Rajasekaran <[email-masked]>
Date: Wed, 10 Nov 2010 12:48:34 -0800

Hi Preeti,

Please find comments inline based on my understanding.

Thanks,
Madhuvanthi

On Tue, Nov 9, 2010 at 10:23 PM, Preeti Daundiyal <
[email-masked]> wrote:

> RFC 3473  :“If a message contains multiple Notify_Request objects, only
> the first
>
> ignored and SHOULD NOT be propagated”.
>
>
>
> But in case of we want to send multiple notify ip address (Upstream notify
> Ip address as well the downstream notify address), we need to send two
> notify address. Hence would require, two Notify request object to be send in
> the RSVP path message.
>

>> Madhuvanthi>>The RFC 3473 defines the upstream notify address to be
specified by the path message and downstream notify address to be specified
by the resv message.

>
>
> Query: Can we not avoid this restriction and send multiple notify request
> object in RSVP path message and intermediate node stores both the address
> for notification. In this case, How will the intermediate node distinguish
> between the upstream notification address and the downstream notify address.
> Is there some extension defined in some other RFC for this purpose or some
> other means to satisfy this requirement.
>

>> Madhuvanthi>> I think as per RFC 3473, the intermediate node can store
both upstream and downstream
notify address. Differentiation of upstream or downstream notify is based on
the request received i.e.
in path or resv message.

>
>
> Regds,
>
> Preeti
>
> ------------------------------
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of this
> message. Aricent accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including damage from
> virus."
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 11 Nov 2010 05:53:52 +0800

See RFC4873:

    Note this requires the following change to [RFC3473], Section 4.2.1:

    o old text:
       If a message contains multiple NOTIFY_REQUEST objects, only the
       first object is meaningful.  Subsequent NOTIFY_REQUEST objects MAY
       be ignored and SHOULD NOT be propagated.

    o new text:
       If a message contains multiple NOTIFY_REQUEST objects, only the
       first object used is in notification.  Subsequent NOTIFY_REQUEST
       objects MUST be propagated in the order received.

---

From: Preeti Daundiyal <[email-masked]>
Date: Wed, 1 Dec 2010 12:18:42 +0530

Hi Lou,

   Thanks !  But as per our requirement , from the LSP ingress node we intend to signal both the upstream and downstream notify receipt address to the LSP intermediate/egress node. As per the flow specified below, (suppose we have tunnel from Node A to Node C).Node A (Tunnel ingress) sends two notify object in the RSVP path message to node B .  One Notify request object specifying the upstream notify receipent address and the another specify downstream notify address.
The address values being sent in notify request is as per rfc 4802 MIB objects (gmplsTunnelUpstreamNotifyRecipient, gmplsTunnelSendPathNotifyRecipient).

[X][X][X][X][X]

We want the intermediate Node B  to use both the notify objects and propagate both both objects to Node C.  How will be such a requirement  be met if we are using only one aobject as specified in the new text
o new text:
      If a message contains multiple NOTIFY_REQUEST objects, only the
      first object used is in notification.  Subsequent NOTIFY_REQUEST
      objects MUST be propagated in the order received.

Can u please suggest.

Regds,
Preeti

[X]
From: Lou Berger [mailto:[email-masked]]
Sent: Thursday, November 11, 2010 3:24 AM
To: Preeti Daundiyal
Cc: [email-masked]
Subject: Re: [CCAMP] GMPLS: RFC 3473 RSVP Notify Request Query

See RFC4873:

   o old text:

   o new text: