Re: the shen-mpls-nnhop Was:(Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt)

[Loa Andersson <[e-mail]>]

Alia,

we need to be careful so we talk about the same thing. The
shen-mpls-nnhop is intended for the mpls working group, has
been oreented there and asked to be made a working group
doc. That part belongs in mpls.

What you describe below is requirments on a solution. The
requirement work may very well be be done in rtgwg or anywhere
else.

Actual protocol design should be done by the working group
that owns the protocol.

/Loa

Alia Atlas wrote:

> Loa,
> 
> In this case, I agree with Stewart. (Much less usual than Stewart 
> agreeing with Mike :-)
> 
> To my mind, the IP FRR work that has been going on in rtgwg also applies 
> to LDP.  LDP, after all, learns its next-hops from the IGP.  I have been 
> referring to this work as IP/LDP FRR since the beginning and certainly 
> advocating for its applicability to LDP as well.
> 
> There are two points that I can see where there could be additional work 
> for the mpls wg.   First, LDP FRR requires knowledge of labels from 
> neighbors who are not the primary neighbors.  This means that the 
> loop-checking which can be enabled in LDP should not be (at least for 
> the non-primary neighbors)- because the label bindings do not all 
> represent paths that would be taken.  This  doesn't require changes to 
> LDP; it is a detail of the required mode.  There could be more text in 
> the LFA draft to reflect the acceptable LDP modes/configurations that 
> would work.
> 
> Second, an advanced method may require extensions to support label 
> discovery.  For U-turn alternates, the requirement is merely that a 
> router advertise its label bindings to all neighbors - not merely those 
> that are primary.  This is already clearly within the LDP spec - and a 
> good idea for convergence reasons.  Thus, there's no work required for 
> that aspect.  For U-turn alternates, for the explicitly marked U-turn 
> packet, I do use a specific label that all implementations need to use 
> in common; ideally that'd be a reserved label (13) but I haven't tried 
> to start that discussion, until the future of U-turn alternates becomes 
> more clearly defined.  For a tunnel approach that has the tunnel 
> egressing at the next-next-hop, Naiming's idea of learning label 
> bindings via a neighbor might be helpful.  For the tunnel approaches, 
> there's also the potential/probable need for targeted sessions to 
> support multi-homed prefixes, but that requires no extensions.  For a 
> tunnel approach, it is highly likely that one tunnel technology used 
> would be LDP, since that uses a hardware mechanism clearly supported today.
> 
> My expectation was that the rtgwg would need to last-call the IP/LDP FRR 
> work in the MPLS WG, as well as the ISIS and OSPF WGs, because of the 
> applicability there.
> 
> What do you think?
> 
> Alia
> 
> At 09:26 AM 5/18/2005, Stewart Bryant wrote:
> 
> 
>> Loa Andersson wrote:
>>
>>> Maiming 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 futopicctionality 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?)
>>
>>
>> I disagree.
>>
>> Whilst the MPLS WG must be engaged in this work, to do it
>> exclusively in MPLS WG would be a mistake.
>>
>> The work that we have done to date has achieved a high degree
>> of commonality between the IP solution and the MPLS solution.
>> Maintenance of that commonality would be at risk if the
>> MPLS WG struck out in their own direction. This work
>> requires a significant knowledge of the working of routing
>> protocols and therefore RTGWG (or perhaps a new WG in routing)
>> would seem a more natural home than MPLSWG.
>>
>>> - 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.
>>
>>
>> I think that we need an FRR requirements draft.
>>
>> BTW the scope is further widened by the applicability of elements
>> of the solution (loop free convergence) to network management.
>>
>>> - 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.
>>
>>
>> Certainly the MPLS WG need to be an aware and active participant
>> in this work, but please do not precipitate a schism.
>>
>> - Stewart
>>
>>> /Loa
>>
>>
>>
>> _______________________________________________
>> Rtgwg mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/rtgwg
> 
> 
> 
> 


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]

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