The MPLS WG Archive

[benjamin.niven-jenkins@bt.com]

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: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Loa Andersson
> Sent: Wednesday, May 18, 2005 10:47 AM
> To: mpls@ietf.org
> 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:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  loa.andersson@acreo.se
>                                             loa@pi.se
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls