Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

[John E Drake <[e-mail]>]

As a participant, I agree with Lou.

Yours irrespectively,

John


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Lou Berger
> Sent: Thursday, September 13, 2012 6:02 AM
> To: Rakesh Gandhi (rgandhi)
> Cc: [e-mail]
> Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-
> tp-rsvpte-ext-associated-lsp-04.txt
> 
> Rakesh,
> 	This seems really complicated.  Why allow for the optional
> notification from the egress?  There is precedent for use of notify
> messages without notify requests (see RFC4974).
> 
> Also, as it stands Associated Bidirectional really only requires
> support by the end nodes. (I think of it as almost an application
> overlay on top of normal LSP signaling.  I'd even consider using the
> RFC4974 call approach if it wasn't for requirement 11 in RFC6373.)  I
> think placing processing requirements on transit nodes, such as sending
> reverse_lsp notifications adds unnecessary complexity and should be
> avoided unless absolutely necessary.
> 
> Lou (as participant)
> 
> On 9/12/2012 9:57 PM, Rakesh Gandhi (rgandhi) wrote:
> > Hi Fei,
> >
> >
> >
> > I see what you are saying. Rewording the text to reflect this (not
> > sure about “SHOULD” word usage):
> >
> >
> >
> > When an initiating ingress node is provisioned with "Single Sided
> > Associated Bidirectional LSPs" and wishes to control both forward and
> > reverse LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD
> > know the signaling (path) errors on the reverse LSP. Transit and
> > egress nodes SHOULD be requested to notify the signaling error on the
> > reverse LSP by using the NOTIFY message and procedures defined in
> RFC[3473].
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Rakesh
> >
> >
> >
> >
> >
> > *From:*[e-mail] [mailto:[e-mail]]
> > *Sent:* Wednesday, September 12, 2012 9:40 PM
> > *To:* Rakesh Gandhi (rgandhi)
> > *Cc:* [e-mail]; Lou Berger
> > *Subject:* RE: Question on LSP control in
> > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> >
> >
> >
> >
> > Hi Rekesh, Lou
> >
> >  />          Speaking as WG participant, I haven't thought about this
> > too much so may be off, but method 3 seems to be most consistent with
> > the usage of the REVERSE_LSP Object in the path message.  Perhaps
> > consider using the REVERSE_LSP Object in the upstream/Resv direction
> > to allow the egress/tail to provide the ingress/head with arbitrary
> > information..../
> >
> > <fei>Well, I can see one of the advantages of this proposal is that
> it
> > allows the policy control in the egress/tail, where a decision can be
> > made that whether the signaling error should be passed to the
> > ingress/head. But it changes the rules defined in RFC3473....
> >
> >      The other proposal keeps alignment with RFC3473, and I prefer it
> > if the LSP control is totally in hand of the ingress/head (in other
> > words, there is no more information needs the egres/tail to inform
> the
> > ingress/head).
> >
> > *"Rakesh Gandhi (rgandhi)" <[e-mail]
> > <mailto:[e-mail]>>*
> >
> > 2012-09-13 08:53
> >
> >
> >
> > 收件人
> >
> >
> >
> > "[e-mail] <mailto:[e-mail]>"
> > <[e-mail] <mailto:[e-mail]>>
> >
> > 抄送
> >
> >
> >
> > "[e-mail] <mailto:[e-mail]>" <[e-mail]
> > <mailto:[e-mail]>>, Lou Berger <[e-mail]
> > <mailto:[e-mail]>>
> >
> > 主题
> >
> >
> >
> > RE: Question on LSP control in
> > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Fei,
> >
> > Please see inline..<RG>..
> >
> > *From:*[e-mail] <mailto:[e-mail]>
> > [mailto:[e-mail]]
> <mailto:[mailto:[e-mail]]>
> > *
> > Sent:* Wednesday, September 12, 2012 8:42 PM*
> > To:* Rakesh Gandhi (rgandhi)*
> > Cc:* [e-mail] <mailto:[e-mail]>; Lou Berger*
> > Subject:* RE: Question on LSP control in
> > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> >
> >
> > Hi Rakesh
> >
> > In the absence of such notification request, egress node SHOULD relay
> > the received signaling error on the reverse LSP to the ingress node
> > using the NOTIFY message."
> >
> > <fei> "Note that a Notify message MUST NOT be generated unless an
> > appropriate Notify Request object has been received."
> >
> >       If my understanding is correct, your proposed relay mechanism
> > does not depend on the existing of the Notify Request object, which
> > may conflict with the
> >       descripitons in RFC3473.
> >
> >       Do you want to change this or do I have some misunderstanding?
> >
> > <RG> Yes your understanding is correct.  NOTIFY message in this case
> > is generated based on the presence of the “REVERSE_LSP” object and
> > association type “Single Sided Associated Bidirectional LSPs.  I
> > understand what you are saying though. FYI,  Lou had following
> > thoughts on this. Do you think this simplifies things ?
> > />          Speaking as WG participant, I haven't thought about this
> too
> > much so may be off, but method 3 seems to be most consistent with the
> > usage of the REVERSE_LSP Object in the path message.  Perhaps
> consider
> > using the REVERSE_LSP Object in the upstream/Resv direction to allow
> > the egress/tail to provide the ingress/head with arbitrary
> information....
> > /
> > Thanks,
> > Rakesh
> >
> >
> >
> > Regards
> >
> > Fei
> >
> > *"Rakesh Gandhi (rgandhi)" <**[e-mail]*
> > <mailto:[e-mail]>*>*
> >
> > 2012-09-13 01:23
> >
> >
> >
> >
> >
> > 收件人
> >
> >
> >
> > Lou Berger <[e-mail] <mailto:[e-mail]>>
> >
> > 抄送
> >
> >
> >
> > "[e-mail] <mailto:[e-mail]>"
> > <[e-mail] <mailto:[e-mail]>>,
> > "[e-mail] <mailto:[e-mail]>" <[e-mail]
> > <mailto:[e-mail]>>
> >
> > 主题
> >
> >
> >
> > RE: Question on LSP control in
> > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Lou, Fei, WG,
> >
> > Thanks for your replies. May I propose following text to cover this
> > case? This allows the mid-point solution which has advantages but
> > given the additional complexity can be optional.
> >
> > Please advise.
> >
> > "When an initiating ingress node is provisioned with "Single Sided
> > Associated Bidirectional LSPs" and wishes to control both forward and
> > reverse  LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD
> > know the signaling (path) errors on the reverse LSP.  A transit node
> > MAY be requested to notify the signaling error on the reverse LSP by
> > using the NOTIFY message and procedures defined in RFC[3473]. In the
> > absence of such notification request, egress node SHOULD relay the
> > received signaling error on the reverse LSP to the ingress node using
> > the NOTIFY message."
> >
> > Thanks,
> > Rakesh
> >
> >
> > -----Original Message-----
> > From: Lou Berger [mailto:[e-mail]]
> > <mailto:[mailto:[e-mail]]>
> > Sent: Wednesday, September 12, 2012 12:14 PM
> > To: Rakesh Gandhi (rgandhi)
> > Cc: [e-mail] <mailto:[e-mail]>;
> > [e-mail] <mailto:[e-mail]>
> > Subject: Re: Question on LSP control in
> > draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> >
> > Rakesh,
> >
> >
> > On 9/12/2012 11:52 AM, Rakesh Gandhi (rgandhi) wrote:
> >> Thanks Lou.
> >>
> >> Are we ok in general to use NOTIFY message [RFC3473] for this?
> >
> > I'm not speaking for the WG, as noted my comments were as a
> participant.
> > IMO you'll need to fully document the proposal, perhaps discuss
> > alternatives considered, and then ask the WG for concurrence.
> >
> >>
> >> One advantage with the mid-point sending notification for the
> reverse
> >> LSP is that signaling error propagation time
> >> (mid->egress-node->ingress-node) is significantly reduced (to
> >> mid->ingress-node) which may be preferred in some cases.
> >
> >>From my (personal) perspective, the added complexity isn't worth the
> effort.  Of course, a detailed proposal may show otherwise.
> >
> > Lou
> >
> >>
> >> Thanks,
> >> Rakesh
> >>
> >>
> >> -----Original Message-----
> >> From: Lou Berger [mailto:[e-mail]]
> >> <mailto:[mailto:[e-mail]]>
> >> Sent: Wednesday, September 12, 2012 9:15 AM
> >> To: Rakesh Gandhi (rgandhi)
> >> Cc: [e-mail] <mailto:[e-mail]>;
> >> [e-mail]
> > <mailto:[e-mail]>
> >> Subject: Re: Question on LSP control in
> >> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> >>
> >> Rakesh,
> >>                  Speaking as WG participant, I haven't thought about
> >> this too much so may be off, but method 3 seems to be most
> consistent
> >> with the usage of the REVERSE_LSP Object in the path message.
> >> Perhaps consider using the REVERSE_LSP Object in the upstream/Resv
> >> direction to allow the egress/tail to provide the
> > ingress/head with arbitrary information....
> >>
> >> Lou
> >>
> >> On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:
> >>> Hi WG,
> >>>
> >>> Any thoughts on the following proposal?
> >>>
> >>> Thanks,
> >>> Rakesh
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Rakesh Gandhi (rgandhi)
> >>> Sent: Tuesday, September 04, 2012 1:36 PM
> >>> To: 'Lou Berger'
> >>> Cc: [e-mail] <mailto:[e-mail]>;
> >>> [e-mail]
> > <mailto:[e-mail]>
> >>> Subject: RE: Question on LSP control in
> >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> >>>
> >>>
> >>> Thanks Lou for your reply.
> >>>
> >>> RFC 3473 defines procedures for NOTIFY request and reply. We could
> use this for reverse LSP signaling error notification to the initiating
> ingress node.
> >>>
> >>> <Notify message> ::= <Common Header> [<INTEGRITY>] [
> [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
> >>> <ERROR_SPEC>
> >>> <notify session list ::= <upstream session> <downstream session>  >
> >>>
> >>> There are multiple ways we can use the NOTIFY message.
> >>>
> >>> Method 1 - Mid-point aware with Path message request:
> >>> When an egress node receives a Path message with REVERSE_LSP
> object, the node will insert NOTIFY_REQ message in the reverse LSP path
> message with node ID of the initiating ingress node. A mid-point node
> will send  a copy of the signaling error to the initiating node using
> the NOTIFY message.
> >>>
> >>> IPv4 Notify Request Object
> >>>    IPv4 Notify Node Address: 32 bits
> >>>       The IP address of the node that should be notified when
> generating an error message.
> >>>
> >>> Method 2 - Mid-point aware with Resv message request:
> >>> When an initiating ingress node receives a Path message for a
> reverse LSP, the node will insert NOTIFY_REQ message in the reverse LSP
> Resv message with its own node ID. A mid-point node will send a copy of
> the signaling error to the initiating node using the NOTIFY message.
> >>>
> >>> Method 3 - Tail-end relaying :
> >>> When an egress node receives a Path message with REVERSE_LSP
> object,
> >>> the node will relay the received signaling error message on the
> >>> reverse LSP to the initializing ingress node. The egress node
> copies
> >>> the received "ERROR_SPEC" object into a NOTIFY [RFC3473, section
> >>> 4.3] message and signals it to the ingress node. In this case,
> > NOTIFY_REQ message is not required.
> >>>
> >>> Please advise your thoughts.
> >>>
> >>> Thanks,
> >>> Rakesh
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Lou Berger [mailto:[e-mail]]
> >>> <mailto:[mailto:[e-mail]]>
> >>> Sent: Tuesday, September 04, 2012 11:35 AM
> >>> To: Rakesh Gandhi (rgandhi)
> >>> Cc: [e-mail] <mailto:[e-mail]>;
> >>> [e-mail]
> > <mailto:[e-mail]>
> >>> Subject: Re: Question on LSP control in
> >>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> >>>
> >>> As I read the current rev, no such notification mechanism is
> specified.
> >>>  Looks like you get to propose one!
> >>>
> >>> Lou (as WG participant).
> >>>
> >>> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:
> >>>> Hi Lou, Fei,
> >>>>
> >>>> When an (originating) ingress node is provisioned with "5 (TBD)
> >>>> Single Sided Associated Bidirectional LSPs  (A)" and wishes to
> >>>> control both forward and reverse  LSPs by adding "REVERSE_LSP"
> >>>> object, I would think that the ingress node needs to know about
> the
> >>>> signaling (path) errors (such as soft preemption or admission
> > failure) on the reverse LSP.  Is there any text somewhere in an
> > RFC/draft that describes how a mid-point node can send the signaling
> > (path) error to the originating ingress node for the reverse LSP? Is
> > there an assumption to use RSVP_NOTIFY message? Sorry if I had missed
> > any previous discussion on this topic.
> >>>>
> >>>> Thanks,
> >>>> Rakesh
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp