RE: [mpls] moving discussion to the mpls working group list

[Alia Atlas <[e-mail]>]

Ben,

The IP FRR work applies as well to LDP.  There are a couple aspects for LDP 
that may require additional work or investigation so that the same methods 
used for IP FRR will apply to LDP.  This has come up on the rtgwg because 
of the discussion of possible work to support the more advanced (and 
contentious :-) methods for IP FRR.

For LDP FRR, there are possible restrictions on modes & the need to 
advertise label bindings to all ones neighbors - not merely those that are 
the primary next-hops.  The latter is a good idea, anyway, for convergence, 
and already in the RFC.  For the modes, I've mostly focused on the 
Downstream Unsolicited with liberal label retention.  If there is interest 
in other modes for the LDP FRR work, that'd be interesting to hear.

Alia

At 06:42 AM 5/18/2005, [e-mail] wrote:
>Loa, Colleagues,
>
>I have not been following the rtgwg and I can not find any drafts on LDP
>next-next-hop so apologies if my questions have already been addressed.
>
>
>My understanding is that the path LDP uses for a flow 'tracks' the IGP
>and an LDP flow will take the same path through the network as an IP
>flow to the same destination/FEC (assuming ECMP is not running).
>
>Therefore is there really a need for LDP FRR as well as IP FRR, when LDP
>tracks the IGP anyway? (Or am I getting ahead of myself and the proposal
>is to modify LDP to make it so that it can still track the IGP when IP
>FRR is used?)
>
>Ben
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Loa Andersson
> > Sent: Wednesday, May 18, 2005 10:47 AM
> > To: [e-mail]
> > Subject: [mpls] moving discussion to the mpls working group list
> >
> >
> > MPLS working group,
> >
> > there has been a discussion on the rtgwg mailing list on
> > possible extension to LDP for finding out the next-next-hop
> > label mapping. Possible applications for this functionality
> > world be fast reroute. Since the extensions to the LDP should
> > be handled by the MPLS working group, this mail is to
> > indicate that the discussion will be contiuned on the MPLS
> > working group list.
> >
> > The non-MPLS part of this discussion will remain on the rtgwg
> > mailing list.
> >
> > This is the content of the last mail on the rtgwg thread
> > called "Re: the shen-mpls-nnhop Was:(Re: thoughts on
> > draft-bryant-shand-ipfrr-notvia-addresses-00.txt)"
> >
> > /Loa
> >
> >
> > Naiming and Stewart,
> >
> > you wrote - and I guess this is valid:
> >
> > Naiming Shen wrote:
> >
> >  > I think the needs start emerging, any important services
> >  > riding on top of IP/MPLS transport infrastructure needs
> >  > fast convergence services. It's not reasonable to assume
> >  > only RSVP-TE LSPs need fast reroute, and other
> >  > network transport does not. This nnhop-ldp draft is to
> >  > facilitate the LDP based MPLS network for FRR with
> >  > node protection. I have been talking to some providers
> >  > in the past year, there are certainly interests in
> >  > this service.
> >
> >
> >
> > Stewart Bryant wrote:
> >  >
> >  > I think the interest that we are seeing in IPFRR for LDP
> >  > networks demonstrates the usefulness of this work. Sure
> >  > RSVP-TE FRR exists, but some customers have expressed
> >  > an interest in a solution that does not use RSVP.
> >  >
> >
> > However the MPLS working group need to take a decision if,
> > when and how this functionality should be developed.
> >
> >
> > The way of doing this would be
> >
> > - write down the requirements
> > - send them to the mpls wg
> > - we go through the moces to establish the mpls wg consensus
> >
> > Comments:
> >
> > - I don't think FRR for LDP based MPLS enabled IP networks
> >    should not go into the rtgwg, the charter of the rtgwg seems
> >    to say the rtgwg takes of everything that does not fit into
> >    other routing are working groups (Alex and Bill comments on this?)
> >
> > - my take is that for this purpose you could either document
> >    the requirements in a separate document or put them into one
> >    the existing documents. I've no preferences, but this should
> >    be rather short.
> >
> > - my preference would be to speed this up so we could have
> >    a decision going into the Paris meeting.
> >
> > Also I think it will be right to take this discussion to the
> > mpls wg list. I will write a mail to mpls list to that effect.
> >
> >
> > /Loa
> >
> >
> > --
> > Loa Andersson
> >
> > Principal Networking Architect
> > Acreo AB                           phone:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:  [e-mail]
> >                                             [e-mail]
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/mpls
> >
>
>_______________________________________________
>mpls mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/mpls



_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls