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

[Alia Atlas <[e-mail]>]

Loa,

At 10:23 AM 5/18/2005, Loa Andersson wrote:
>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.

I certainly agree with this.

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

It's not clear what the requirements are yet.  Therefore, it seems 
premature to me to involve the MPLS WG.  Of course, if there's not much 
going on there (other than p2mp, etc... :-), then getting opinions is 
always useful.

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

Yes, absolutely.

Alia


>/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