RE: Agenda updated

["PAPADIMITRIOU Dimitri" <[e-mail]>]

hi nic,

my 2 cents here below: 

> -----Original Message-----
> From: Nic Neate [mailto:[e-mail]] 
> Sent: Tuesday, November 18, 2008 3:07 PM
> To: labn - Lou Berger
> Cc: [e-mail]; Aria - Adrian Farrel Personal; 
> [e-mail]; 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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of labn - Lou Berger
> Sent: 16 November 2008 22:46
> To: Nic Neate
> Cc: labn - Lou Berger; [e-mail]; Aria - 
> Adrian Farrel Personal; [e-mail]; 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:[e-mail]]
> > > Sent: Friday, November 14, 2008 4:46 PM
> > > To: labn - Lou Berger; [e-mail]; PAPADIMITRIOU
> > > Dimitri; Aria - Adrian Farrel Personal
> > > Cc: [e-mail]
> > > 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: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Aria - 
> Adrian Farrel
> > > Personal
> > > Sent: 07 November 2008 19:29
> > > To: [e-mail]
> > > 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
> > >
> > >
> 
> 
>