[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Agenda updated
hi nic,
my 2 cents here below:
> -----Original Message-----
> From: Nic Neate [mailto:Nic.Neate@dataconnection.com]
> Sent: Tuesday, November 18, 2008 3:07 PM
> To: labn - Lou Berger
> Cc: IBryskin@advaoptical.com; Aria - Adrian Farrel Personal;
> ccamp@ops.ietf.org; PAPADIMITRIOU Dimitri
> Subject: RE: Agenda updated
>
> Hi Lou,
>
> Following up on our conversation in CCAMP.
>
> I think you agreed that the "Resource Sharing" association
> type 2 is not relevant to this discussion.
>
> You also said that the intent of the statement from 3.2.1
> "processing and identification occur with respect to segment
> recovery LSPs" is to indicate that the procedures defined in
> RFC 4872 for setting the association ID to an LSP ID are not
> used. Instead, a unique identifier should be chosen by the
> association source (as suggested in our draft).
>
> I find this quite a stretch, and think a clarification would
> improve the chances of interoperability.
where is the stretch ? in end-to-end the source of the tunnel is the
source of the association whereas in the segment case they are not the
same.
> I'm also concerned with the reuse of association type 1 with
> different semantics in segment recovery to those defined for
> end-to-end recovery. Consider the case where a segment
> recovery LSP is itself end-to-end protected.
what does this actually mean ? does it refer to the case where there are
two 2 protecting segments ?
> Then there will
> be two type 1 association objects, and the merge node must
> process each differently. How does the implementation you
> mentioned decide which is which?
>
> You also dismissed the other issues raised in
> draft-rhodes-rsvp-recovery-signaling relating to protection
> of recovery LSPs and overlaping protection. Please could you
> respond on the specific technical points raised in the draft?
it is the same as the base case, if a segment recovery LSP is himself
protected partially the source of the association will not be the source
of protected recovery segment.
thanks,
-d.
> I'd be glad to meet up and discuss this in person while we're
> in Minneapolis.
>
> Thanks,
>
> Nic
>
>
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of labn - Lou Berger
> Sent: 16 November 2008 22:46
> To: Nic Neate
> Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -
> Adrian Farrel Personal; ccamp@ops.ietf.org; ALU - Dimitri
> Papadimitriou
> Subject: RE: Agenda updated
>
> I agree with Dimitri.
>
> also, note:
>
> 3.2.1. Recovery Type Processing
>
> Recovery type processing procedures are the same as those
> defined in
> [RFC4872], but processing and identification occur with respect to
> segment recovery LSPs.
>
> Lou
>
> At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote:
> >nick,
> >
> >you mention:
> >
> >"3.1 Association between LSPs in different sessions
> >
> > Segment recovery protecting LSPs may have a different endpoint
> > address from the corresponding protected LSP. The protected and
> > protecting LSPs are therefore in different Sessions.
> The Association
> > object of type 1 (recovery) is not effective in this case, as the
> > Association ID can only associate to an LSP ID within the same
> > Session."
> >
> >but segment recovery makes use of:
> >
> >"9.1. New Association Type Assignment
> >
> >
> > IANA has made the following assignment to the "Association Types"
> > Registry (see [RFC4872]) in the "ASSOCIATION (object)"
> section of the
> > "RSVP PARAMETERS" registry located at
> > http://www.iana.org/assignments/rsvp-parameters.
> >
> > Value Type
> > ----- ----
> > 2 Resource Sharing (R) [RFC4873]"
> >
> >and states:
> >
> >"Consider the following topology:
> >
> > A---B---C---D---E---F
> > \ /
> > G---I
> >
> > In this topology, end-to-end protection and recovery is
> not possible
> > for an LSP going between node A and node F, but it is possible to
> > protect/recover a portion of the LSP. Specifically, if
> the LSP uses
> > a working path of [A,B,C,D,E,F], then a protection or
> restoration LSP
> > can be established along the path [C,G,I,E]."
> >
> >[...]
> >
> >"Segment protection or restoration is signaled using a
> working LSP and
> > one or more segment recovery LSPs. Each segment recovery LSP is
> > signaled as an independent LSP. Specifically, the
> Sender_Template
> > object uses the IP address of the node originating the
> recovery path,
> > e.g., node C in the topology shown above, and the Session object
> > contains the IP address of the node terminating the
> recovery path,
> > e.g., node E shown above. There is no specific
> requirement on LSP ID
> > value, Tunnel ID, and Extended Tunnel ID."
> >
> >so where is the issue ?
> >
> >-d.
> >
> > > -----Original Message-----
> > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]
> > > Sent: Friday, November 14, 2008 4:46 PM
> > > To: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU
> > > Dimitri; Aria - Adrian Farrel Personal
> > > Cc: ccamp@ops.ietf.org
> > > Subject: FW: Agenda updated
> > >
> > > RFC 4873 authors,
> > >
> > > Just wanted to flag that I'm presenting a problem in segment
> > > recovery signaling on Monday, together with a suggested solution.
> > >
> > > Problem statement:
> > >
> http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00.
> > > Suggested fix:
> > >
> http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00.
> > >
> > >
> > > Nic
> > >
> > > -----Original Message-----
> > > From: owner-ccamp@ops.ietf.org
> > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria -
> Adrian Farrel
> > > Personal
> > > Sent: 07 November 2008 19:29
> > > To: ccamp@ops.ietf.org
> > > Subject: Agenda updated
> > >
> > > I have made some updates.
> > >
> > > http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
> > >
> > > Please shout if there further issues.
> > >
> > > Thanks,
> > > Adrian
> > >
> > >
>
>
>