Subject: Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt

From: Loa Andersson <[email-masked]>
Date: Mon, 02 May 2005 09:55:21 +0200

Mike,

actually the Naimings draft did not go anywhere when discussed in the
MPLS wg, this change to LDP would have to be taken up in the mpls again.

/Loa
> 
>> 2.      Explicit tunnels are needed, which means that targeted LDP 
>> sessions are necessary to have this support LDP traffic.
> 
> 
> Yes. In the case of node protection we could also using Naiming's scheme 
> of next-next hop LDP advertisement.
> 

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

---

From: Naiming Shen <[email-masked]>
Date: Mon, 02 May 2005 09:03:31 -0700

Loa,

Last time the issue was with the wording of IPR statement in the
previous version of NNHOP LDP draft, we plan to refresh the
document in the mpls wg soon.

thanks.
- Naiming

Loa Andersson said the following on 05/02/2005 12:55 AM:
>> Yes. In the case of node protection we could also using Naiming's 
>> scheme of next-next hop LDP advertisement.
>>
> 
>

---

From: Loa Andersson <[email-masked]>
Date: Mon, 16 May 2005 13:03:51 +0200

Naiming,

could you give me the pointer to "the last time" you are
refereing to. I find "the latest" in the reference to this
from the Seoul meeting. There were two question posed, do
we want to take LDP there and will it actually achieve
what the authors claim. Both questions were left for
further discussion on the MPLS mailing list. As far as
I remember this discussion has not taken place.

/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:  [email-masked]
                                            [email-masked]

---

From: Naiming Shen <[email-masked]>
Date: Mon, 16 May 2005 08:55:56 -0700

Loa,

Check out the MPLS mailing list archive April 2004 with
subject of "discussion on nexthop fast-reroute drafts".
I posted the mail first on the list asking for two drafts,

draft-shen-nhop-fastreroute-00.txt
draft-shen-mpls-ldp-nnhop-label-00.txt

to be adopted as the working group document in mpls-wg.
there were some syntax comments and some IPR dicussions
followed. the IPR issue should be fixed and we also
posted version-1 drafts after that. I can post the
new versions and start the discussion again.

thanks.
- Naiming

---

From: Alia Atlas <[email-masked]>
Date: Mon, 16 May 2005 13:21:42 -0400

Naiming,

One concern is what precisely is gained by this extension.  It seems to be 
removing the overhead of the additional LDP sessions & adding in the 
assumption that the LDP labels are allocated per-platform.

There are also timing issues - such as what is the delay in obtaining the 
new information & the effect of using the old.  For instance, does a 
neighbor N, on receiving a label withdraw from its neighbor R, send an 
immediate label release or wait until all routers that N has forwarded R's 
label to have released it?

Another is what does S do when it detects that the LDP session to N is 
down?  Say there is a single link from S to N which has an untargeted LDP 
session on it.  When the link fails, if it's POS, MPLSCP will also go down 
- triggering the session to be torn down.  At the same time, traffic may be 
forwarded, using labels learned from N, to N's neighbor R.  When/how are 
those labels invalidated?

Alia

---

From: Naiming Shen <[email-masked]>
Date: Mon, 16 May 2005 10:58:01 -0700

Hi Alia,

Alia Atlas said the following on 05/16/2005 10:21 AM:
> Naiming,
> 
> One concern is what precisely is gained by this extension.  It seems to 
> be removing the overhead of the additional LDP sessions & adding in the 

Correct. Also I added one section on why we use this approach vs.
use targeted ldp session in the new version, there is more benefits
than you mentioned above.

The below concerns are timing issues and implementation details. But any
pre-setup scheme always have timing issues.

> 
> There are also timing issues - such as what is the delay in obtaining 
> the new information & the effect of using the old.  For instance, does a 
> immediate label release or wait until all routers that N has forwarded 
> R's label to have released it?

The implementation and configuration deal with those timing issues.
A router can be configured to send immediately, or wait for a fixed
time, or applying some backoff throttling scheme, etc. this is not
much different from any other routing/label updates.

> down?  Say there is a single link from S to N which has an untargeted 
> LDP session on it.  When the link fails, if it's POS, MPLSCP will also 
> go down - triggering the session to be torn down.  At the same time, 
> traffic may be forwarded, using labels learned from N, to N's neighbor 
> R.  When/how are those labels invalidated?

It's also a local policy and configuration issue. One can keep using this
until the new route/ldp converge, one can sets up a max time to use the
rerouted tunnel, etc. This is not much different from the RSVP based
MPLS FRR, your neighbor is down, you learned the next-nexthop lable from
this neighbor for FRR(actually the reason you use this label is because
this neighbor is down), and how to invalidate those labels.

thanks.
- Naiming

>>>>>>> 2.      Explicit tunnels are needed, which means that targeted 
>>>>>>> LDP sessions are necessary to have this support LDP traffic.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 17 May 2005 13:07:26 +0200

Naiming,
I checked this (thanks for the pointer) I actually forgotten
that the IPR discussion was realted to this document.

The -01 version has also dated so I guess it would be a good
idea to post version -02.

What I see happening in the April -04 discussion is that the
issues from Seoul was not at all discussed (much less solved).
And further issues added (mostly the IPR, which now seems to
be solved).

I also saw very little support for the draft as such.

What concerns me here is that this is a solution without
clear requirements.

That is not to say that we don't have potential applications,
e.g. the pwe3 multihop pw's or the not via frr. Neither of those
schemes have yet been adopted as working group documents.
It is even doubtful if the mh pw's are within charter.

If there is a need to add nnhop label retrievement for
LDP, that should be brought to the MPLS working group by the
working group or party that have that need as a requirement.

In the mean time the answer is if you need to do FFR in MPLS
enabled IP networks you should use RSVP-TE.

/Loa

Even though it is
not fuly clear that

-- 
Loa Andersson

---

From: Naiming Shen <[email-masked]>
Date: Tue, 17 May 2005 10:21:29 -0700

Hi Loa,

> idea to post version -02.

Will do soon.

> What concerns me here is that this is a solution without

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.

> working group or party that have that need as a requirement.

I plan to submit the new version and open the discussion in
MPLS working group soon. Thanks for the support.

> enabled IP networks you should use RSVP-TE.

The current FRR in MPLS ONLY allows the protection for RSVP-TE.
and as far as I know of, most of the MPLS enabled network today
is LDP based, they certainly need fast convergence/reroute too.
And this draft is one solution to facilitate that.

thanks.
- Naiming

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 17 May 2005 19:48:24 +0100

> in the past year, there are certainly interests in

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.

> And this draft is one solution to facilitate that.

Strictly this draft facilitates the nnhop labels needed for the
LDP variant of the IPFRR work that is going on in the rdgwg, rather
than being a solution in its own right. It is however a useful
starting point in addressing the nnh label problem, and should
continue to be investigated.

- Stewart

---

From: Alia Atlas <[email-masked]>
Date: Tue, 17 May 2005 16:12:55 -0400

Hi Naiming,

>than you mentioned above.

I'll be interested to read those.

>pre-setup scheme always have timing issues.

The timing issues need to be understood & the ramifications considered.  I 
disagree that all of these are implementation details - some of them have 
definite inter-operability impact.

>much different from any other routing/label updates.

There is an inter-operability component here.  Generally, a router can 
reuse a label once it has received label releases from all its upstream 
neighbors.  If you claim that it is an implementation issue - does that 
mean the above assumption doesn't hold, may hold, or may sometimes hold?

It's a question of when a label can be re-used.

>>session on it.  When the link fails, if it's POS, MPLSCP will also go 
>>down - triggering the session to be torn down.  At the same time, traffic 
>>may be forwarded, using labels learned from N, to N's neighbor 

This is somewhat different.  With RSVP-TE FRR, the downstream label is also 
learned/confirmed via the backup signaling - indicating that the label is 
still valid.

I do not think that these are specifically blockers - but I do think that 
they are some of the issues that need to be considered/discussed.  It's 
very easy to just pass up the extra label info, without thinking through 
all of the ramifications.

Other aspects are - oh, the case where multiple neighbors N1 and N2 both 
have a common neighbor R.  What happens if the neighbors N1 and N2 report 
different labels for R?

If there is a need to use tunnels for backup and there are sufficiently 
many that doing targeted LDP sessions is really not desirable, then this 
draft might be useful - but I'm not fully convinced (on several of those 
fronts).

Alia

---

From: Loa Andersson <[email-masked]>
Date: Wed, 18 May 2005 11:07:53 +0200

Maiming and Stewart,

you wrote - and I guess this is valid:

 > 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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 18 May 2005 14:26:15 +0100

Loa Andersson wrote:
> when and how this futopicctionality should be developed.
> 
> 

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.

>   the existing documents. I've no preferences, but this should

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.

> 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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 18 May 2005 10:05:23 -0400

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

---

From: Loa Andersson <[email-masked]>
Date: Wed, 18 May 2005 16:23:05 +0200

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

-- 
Loa Andersson

---

From: Alia Atlas <[email-masked]>
Date: Wed, 18 May 2005 11:13:32 -0400

Loa,

>doc. That part belongs in mpls.

I certainly agree with this.

>requirement work may very well be be done in rtgwg or anywhere

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

Yes, absolutely.

Alia

>>detail of the required mode.  There could be more text in the LFA draft 
>>to reflect the acceptable LDP modes/configurations that would work.
>>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 
>>highly likely that one tunnel technology used would be LDP, since that 
>>uses a hardware mechanism clearly supported today.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 18 May 2005 17:37:42 +0200

Alia,

Alia Atlas wrote:

My whole point was that there is a document, with a solution, without
documented requirments, that is intended for the mpls working group.
The protocol extensions will happen in the mpls wg. This is why I
think that part needs to be on the mpls wg mailing list. It is not
a good idea to present a draft e.g. in Paris, and pointing to a
discussion on another mailing list.

Taking my wg chair hat off.

I personally think that it is likely that the mpls wg will
draw the same conclusion as you do "It's not clear what the
requirements are yet", that we will say that we recognize that
the rtgwg works on requirements and unless there are other
sources of requirements we will wait for those requirement to
settle, and possibly keep the individual draft as closely
aligned with the requirements work as possible.

Putting the chair hat on again.

The reason for doing this is twofold, I want he the working
group to have the best possible information of the draft when
it is presented, and two I want the authors (in this and other
cases) to have the best possible condtions when they discuss
what problem their particular draft solves.

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

-- 
Loa Andersson

---

From: Alex Zinin <[email-masked]>
Date: Wed, 18 May 2005 14:18:31 -0700

Hi, folks-

 I have no idea why, but we seem to get back to the topic of RTGWG scope
 with the periodicity of almost exactly once a year :)

 As explained in May, 2004 (see [1]), RTGWG works on the IP-only scenario
 with a note that if we produce something that also works for MPLS/LDP we
 will only be happier.

 Anything that targets MPLS networks specifically, let alone requires
 modifications of MPLS protocols, has to go to the MPLS WG. It is then the
 job of the MPLS WG chairs to assess whether there's sufficient support
 behind that piece of work, whether requirements are needed, etc.

 Alia mentioned that we should have the documents reviewed in OSPF, IS-IS,
 and MPLS WGs. That's the plan. Once we have the Basic FRR docs in a decent
 shape, we'll take them there for review.

 In the event that in future we (the community) see that a mechanism
 produced within RTGWG can be somehow improved with a few extensions to
 MPLS protocols, and it turns out that RTGWG is a better place to do that,
 the RTGWG would ask the MPLS WG to work on the extensions, possibly
 suggesting what they could look like, and definitely pointing to a
 document that describes how they would be used.

 With regards to draft-shen-nhop-fastreroute and draft-shen-mpls-ldp-nnhop-label:

   I am not aware of any requirements on the RTGWG side at this point for
   the mechanisms in draft-shen-mpls-ldp-nnhop.

   From what I remember, draft-shen-nhop-fastreroute described a mechanism
   targeted for LDP MPLS networks, and hence MPLS would be the place to
   discuss it, which I think is what happened. Iff the MPLS WG was really
   excited about it and asked RTGWG to look at it with the IP-FRR glasses
   on, I'm sure folks here would be happy to do that.

 Hope this helps.

-- 
Alex
http://www.psg.com/~zinin

[1] http://www1.ietf.org/mail-archive/web/rtgwg/current/msg00113.html

---

From: George Swallow <[email-masked]>
Date: Wed, 18 May 2005 18:51:15 -0400

>    on, I'm sure folks here would be happy to do that.

Yes.  In particular, the shen draft can be used with TE tunnels as the
backup paths.  This offers a solution in which TE is only involved in
the failure case, which could be much more attractive to customers who
don't want to deal with *all* of their traffic riding on tunnels.

So a complete solution is available in the MPLS WG.  Note that the
not-via address had not been dreamed up when this draft was first
submitted.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: Alia Atlas <[email-masked]>
Date: Thu, 19 May 2005 13:52:55 -0400

It's true that one could use the shen-mpls-nnhop with just TE tunnels 
providing the alternates.    If that suffices for requirements, I don't 
think that the type of tunnel will matter - just whether or not a tunnel is 
used.

Of course, that scenario was understood the last time the draft was 
discussed in the MPLS WG.  Maybe this time, there can be more discussion, 
if there is more interest.

Alia

---

From: Naiming Shen <[email-masked]>
Date: Wed, 25 May 2005 13:30:25 -0700

Hi Alia,

Alia Atlas said the following on 05/17/2005 01:12 PM:
>>> One concern is what precisely is gained by this extension.  It seems 
>>> to be removing the overhead of the additional LDP sessions & adding 
>>> in the assumption that the LDP labels are allocated per-platform.
>>
>>

Just announced at:
http://www.ietf.org/internet-drafts/draft-shen-mpls-ldp-nnhop-label-02.txt,
please take a look and let me know if the new section makes sense.

I forgot to reference the notvia-addr draft in it, will do in next version.
the rest of the comments seem to be LDP protocol specific, i think we could
do in MPLS group. Sorry about the late response from me.

thanks.
- Naiming

> The timing issues need to be understood & the ramifications considered.  
> I disagree that all of these are implementation details - some of them 
> have definite inter-operability impact.
> 
>>> the new information & the effect of using the old.  For instance, 
>>> does a neighbor N, on receiving a label withdraw from its neighbor R, 
>>> send an immediate label release or wait until all routers that N has 
>>> forwarded R's label to have released it?
>>
>>
>>> Another is what does S do when it detects that the LDP session to N 
>>> is down?  Say there is a single link from S to N which has an 
>>> untargeted LDP session on it.  When the link fails, if it's POS, 
>>> MPLSCP will also go down - triggering the session to be torn down.  
>>> At the same time, traffic may be forwarded, using labels learned from 
>>> N, to N's neighbor R.  When/how are those labels invalidated?
>>
>>
> This is somewhat different.  With RSVP-TE FRR, the downstream label is 
> also learned/confirmed via the backup signaling - indicating that the 
> label is still valid.
> 
> I do not think that these are specifically blockers - but I do think 
> that they are some of the issues that need to be considered/discussed.  
> It's very easy to just pass up the extra label info, without thinking 
> through all of the ramifications.
> 
> have a common neighbor R.  What happens if the neighbors N1 and N2 
> report different labels for R?
> 
>>>>>>>> Yes. In the case of node protection we could also using 
>>>>>>>> Naiming's scheme of next-next hop LDP advertisement.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>