Subject: RE: what's the status of draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Oct 2002 10:38:28 -0400

What about making the method an informational part of the draft, with the 
sender-template-specific method a SHOULD?  In that way, the information 
about what was been done in the past will be preserved and inter-operable 
implementations can be made, but only as long as the interoperability with 
the path-specific method matters to someone.

Alia

At 07:09 AM 10/11/2002 -0700, Shahram Davari wrote:
>Unfortunately I did not see any consensus? and in fact I saw many
>objections. Therefore since no consensus exits for path-specific method,
>it has to be taken out of the draft.
>
>-Shahram
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:[email-masked]]
> > Sent: Friday, October 11, 2002 9:10 AM
> > To: Shahram Davari
> > Cc: [email-masked]
> > Subject: RE: what's the status of
> > draft-ietf-mpls-rsvp-lsp-fastreroute-00. txt
> >
> >
> >
> > > > As for the path-specific method, we cannot take it out
> > for a simple
> > > > reason, that is, it is how Juniper had implemented and
> > > > deployed.
> > >
> > >Although I have tried this a couple of times, but let me do it again:
> > >
> > >IETF is a standard organization. It is not a place to rubber stamp
> > >individual companies implementations, but rather a place to
> > figure out
> > >the best solutions for the industry.
> > >
> > >There is always a risk of implementing a technology before
> > it is standardized.
> > >If we go by your logic then every implementation in the
> > field must be
> > >standardized !
> > >
> > >Does that make sense?
> >
> >          Sharam,
> >
> >          At the risk of repeating myself and others on the
> > topic, remember the
> > IETF mantra: working code and rough consensus.   This is to a
> > large part
> > why the Internet works today and is still not a research project.
> >
> >          --Tom
> >
> >
> > Success is relative; the more success, the more relatives. -Anonymous
> >

---

From: Erblichs <[email-masked]>
Date: Fri, 11 Oct 2002 15:22:58 -0700

Group, and/or Shahram Davari,

	Doesn't early implementations of functionality always
	involve some risk that standard organizations will not
	accept the implementation?

	If the company is big-enough and they distribute
	enough copies of that functionality, then they use
	their customer-base to create a defacto-standard.

	Else, the company risks either being incompatible with
	the stardard, supporting multiple variations,
	or reverting their code to the now agreed upon standard.

	Thus, I don't know why Juniper doesn't release a Informational
	RFC on their implementation and the wg for this draft consider
	what should be done with the "path-specific method" to either
	achieve consensus or....

	Mitchell Erblich
	======================

---

From: "Pan, Ping" <[email-masked]>
Date: Fri, 11 Oct 2002 16:23:20 -0700

Hmmm... let me see who have done what in this space...

Path-specific one-to-one method:
   Juniper, several routers (cannot tell the names)

Sender-specific one-to-one method:
   Avici. ?

Many-to-one method:
   Cisco (both node and link protection), Juniper (link protection for now).

We never said that every vendor has to support everything in the draft 
right away right now. Since each method has its own merits, we let the 
developers and carriers to decide.

To talk about lack of consensus based on some people's comment is quite 
amazing and disturbing.

People have been asking why we glued two approaches together in the 
first place. It looks like we are here for some rubber-stamping. But 
you guys gotta ask yourself this: Cisco and Juniper are not the best 
friends in the first place, so why in the world do they get together to 
do this? The answer is that marketing people tried to kill each other, 
but didn't work. :-) The customers seem to know more than we do on the 
advantages and disadvantages of both methods...

... It's been a slow Friday afternoon. Let me tell the whole story 
behind this fast reroute crap:

About one year ago, Der-Hwa Gan got one-to-one fast reroute working on 
Juniper routers. The original idea came from Tony Li (while in Juniper) 
and Der-Hwa. It was by far the most complex code in RSVP (you guys ought 
to try it someday). It worked, and shipped. At the same time, Cisco got 
a MPLS fast-reroute working as well. Both methods didn't work together. 
So one day, Dave Cooper of Global Crossing came to us and told us that 
he needed fast reroute to be compatible with each other, and didn't care 
how to achieve it.

I got the assignment, found a copy of draft-swallow, and started the 
coding. When I thought it was done, I hooked up a Cisco router. Nothing 
worked! There was no sender-specific stuff in sight. All I got was the 
original Path messages tunneled through the bypass LSP. After talking to 
George Swallow and JP directly over the phone, I was told that the new 
code was still in beta, and has not been released yet. To me, being 
upset was an understatement! But Cisco folks were kind enough to send a 
copy of their new draft that actually told me how it supposes to work. 
As my release date slipping fast, I had to rewrite the darn thing from 
scratch.

More disturbing discovery was that since Cisco used Shared-explicit 
style, while Juniper used Fixed-Filter, there was no way we could turn 
on both Juniper and Cisco fast reroute to protect a single LSP. We could 
not ship this fast-reroute feature this way to the customers. Around 
this time, Alia from Avici told us that they had been reverse 
engineering Juniper fast reroute, and had found several serious problems 
(including merging rules and sender-specific vs. path-specific). So 
Der-Hwa and I started to changed our code while changing the spec. That 
merging rule in the draft was actually a line-by-line pseudo code at one 
point. It was kinda fun thinking back. :-)

When I was done with the facility fast reroute proposed by Cisco, there 
were a lot of implementation issues. So I merged both drafts together, 
and sent it to George and JP for correction along with a bunch of 
questions. Avici folks came on board also. So we had several rounds of 
discussion and disagreement, but came up a draft that developers knew 
how to implement. That was what you have seen.

The final outcome of the draft would allow both one-to-one and 
many-to-one fast reroute to be turned on to protect a single LSP. Both 
sender-specific and path-specific would work together too. That's what 
you have in Junos 5.4. The implementation of facility fast-reroute was 
limited to link protection in Juniper so far, because that was what Dave 
Cooper wanted anyway. Dave was kind enough that we actually interop'ed 
the facility fast-reroute with Cisco developers (Rob and Carol) in 
Global Crossing lab (this is bud to you, Brook!).

The reason for telling you all this is that this draft came directly 
from engineers with the help from providers. No vendor politics, no IETF 
politics, it was a lot of pain and fun at the end! If you are a 
developer, you can really implement this by reading spec.

So before you question our motives again, please reconsider.

Thanks!

- Ping

---

From: "Pan, Ping" <[email-masked]>
Date: Fri, 11 Oct 2002 16:31:44 -0700

Alia, please don't go down that path. :-) We have seen that 
informational RFC 2547.... Let the customers decide, not IETF.

Alia Atlas wrote:
> What about making the method an informational part of the draft, with 
> the sender-template-specific method a SHOULD?  In that way, the 
> information about what was been done in the past will be preserved and 
> inter-operable implementations can be made, but only as long as the 
> interoperability with the path-specific method matters to someone.
> 
> Alia
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Oct 2002 19:49:48 -0400

Absolutely.  The real requirement has been for inter-operability.  It is 
important that what is out there be inter-operable and provide the 
functionality required.

While I would not have chosen the trade-offs made for the path-specific 
method, there are advantages to it (earlier merging of detours so less 
bandwidth reserved) as  well as disadvantages.  Let those who plan to 
deploy it decide what they want.

The draft says how to sit down and actually implement this feature.  As 
Ping says, the code for it is rather complicated.   One has to keep track 
of merging states, keeping state around even though the relevant interface 
is down, propagating or not propagating messages, etc.

That said, much as Ping had the need to inter-operate with Cisco's bypass 
tunnels, we've had the requirement to inter-operate with both.  Much like 
Ping, I sat down and figured out what would be possible and logical to do; 
we did so.  That's why I did the draft suggesting how to deal in a network 
with both cases.

Certainly, we've implemented both the Path-specific method as well as the 
sender-specific method, because of the requirement to interoperate.  That's 
what standardization is about - the need to interoperate.

We're keeping the old Class-type for FAST_REROUTE, without the include-any 
administrative-color, in the draft for the same reason.  It describes what 
is done.

Clearly the issue of the path-specific method is contentious.  Are there 
others with opinions on this one?  Perhaps we could/should put in some 
applicability words about the advantages and disadvantages of each approach 
to aid those deciding which to implement and/or deploy?

Alia

At 04:23 PM 10/11/2002 -0700, Pan, Ping wrote:
>People have been asking why we glued two approaches together in the first 
>place. It looks like we are here for some rubber-stamping. But you guys 
>gotta ask yourself this: Cisco and Juniper are not the best friends in the 
>first place, so why in the world do they get together to do this? The 
>answer is that marketing people tried to kill each other, but didn't work. 
>:-) The customers seem to know more than we do on the advantages and 
>disadvantages of both methods...
>
>... It's been a slow Friday afternoon. Let me tell the whole story behind 
>this fast reroute crap:
>
>to try it someday). It worked, and shipped. At the same time, Cisco got a 
>MPLS fast-reroute working as well. Both methods didn't work together. So 
>one day, Dave Cooper of Global Crossing came to us and told us that he 
>needed fast reroute to be compatible with each other, and didn't care how 
>to achieve it.
>
>code was still in beta, and has not been released yet. To me, being upset 
>was an understatement! But Cisco folks were kind enough to send a copy of 
>their new draft that actually told me how it supposes to work. As my 
>release date slipping fast, I had to rewrite the darn thing from scratch.
>
>More disturbing discovery was that since Cisco used Shared-explicit style, 
>while Juniper used Fixed-Filter, there was no way we could turn on both 
>Juniper and Cisco fast reroute to protect a single LSP. We could not ship 
>this fast-reroute feature this way to the customers. Around this time, 
>Alia from Avici told us that they had been reverse engineering Juniper 
>fast reroute, and had found several serious problems (including merging 
>rules and sender-specific vs. path-specific). So Der-Hwa and I started to 
>changed our code while changing the spec. That merging rule in the draft 
>was actually a line-by-line pseudo code at one point. It was kinda fun 
>thinking back. :-)
>
>were a lot of implementation issues. So I merged both drafts together, and 
>sent it to George and JP for correction along with a bunch of questions. 
>Avici folks came on board also. So we had several rounds of discussion and 
>disagreement, but came up a draft that developers knew how to implement. 
>That was what you have seen.
>
>The final outcome of the draft would allow both one-to-one and many-to-one 
>fast reroute to be turned on to protect a single LSP. Both sender-specific 
>and path-specific would work together too. That's what you have in Junos 
>5.4. The implementation of facility fast-reroute was limited to link 
>protection in Juniper so far, because that was what Dave Cooper wanted 
>anyway. Dave was kind enough that we actually interop'ed the facility 
>fast-reroute with Cisco developers (Rob and Carol) in Global Crossing lab 
>(this is bud to you, Brook!).
>
>The reason for telling you all this is that this draft came directly from 
>engineers with the help from providers. No vendor politics, no IETF 
>politics, it was a lot of pain and fun at the end! If you are a developer, 
>you can really implement this by reading spec.
>

---

From: "Vishal Sharma" <[email-masked]>
Date: Fri, 11 Oct 2002 21:12:29 -0400

Alia,

I think the applicability idea is a very good one. Have been following
the interesting exchange for a while, and the applicability idea
would indeed be helpful in clearing confusions all around.

I would think a separate applicability draft on the applicability of
fast reroute techniques might be preferable, rather than cluttering
the existing draft that focuses on protocol details and method descriptions.

-Vishal

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Alia
> Atlas
> Sent: Friday, October 11, 2002 7:50 PM
> To: Pan, Ping
> Cc: Shahram Davari; 'Thomas D. Nadeau'; [email-masked]
> Subject: Re: what's the status
> ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00. txt
>
>
> many-to-one
> developer,

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Oct 2002 22:13:24 -0400

Good point. :-)   I was just hunting a reasonable compromise... if it 
becomes necessary.  I'd rather not frankly.  Let's just get what we've 
defined clearly standardized.

Alia

At 04:31 PM 10/11/2002 -0700, Pan, Ping wrote:
>Alia, please don't go down that path. :-) We have seen that informational 
>RFC 2547.... Let the customers decide, not IETF.
>
>Alia Atlas wrote:
>>implementations can be made, but only as long as the interoperability 
>>with the path-specific method matters to someone.
>>Alia