IETF-63 Routing Area Minutes

Big thanks to Alia for taking the minutes!

Folks, please read and check the notes below.

--
Alex

IETF-63
August 1, 2005

Routing Area Meeting

1) Announcmentes:  L1VPN approved as a WG

    Alex:  We're going to try to meet with people in ref to starting a
           securing routing BOF for next IETF. 

WG Status:
   BFD:
   CCAMP:  Adrian Farrell:  A new RFC expressing ASON requirements as
needed to be met by GMPLS.  15 docs in RFC Editor queue & 10 in Alex's
queue & 7 drafts in Adrian's queue.  About to run up against finishing
stuff in charter.  There's plenty of related work to be done, so
hopefully 1 or 2 ADs will show up at CCAMP for the charter
discussion.  (I'll hold them
   FORCES
   IDR
   ISIS:  Chris Hopps: Moving on pretty good.  Pushed link addr, admin
tags, route capabilities drafts to AD.  Gathering implemntation status
because are taking to proposed standard.  We need these for admin
tags.  Not sure admin tags has been implemented.  The MIB is in
final-final last call.  There will be a multi-instance ISIS talked
about - so show up for that.
   L1VPN:  Tomonori Takeda : Just started & chartered work.  Please come to first mtg.
   MANET
   MPLS: George Swallow:  Managed to get through mtg without much AD
help.  Most of what was done this morning was about adding multicast
to MPLS.  There was a lot of interest in this; about half the room
agreed that charter should be extended.  Otherwise, some extensions to
OAM and inter-area.  One proposal that we didn't get to on inter-area
LDP.  Otherwise, mostly stuff that we're wrapping up.  Other OAM piece
is P2MP.  Broke the bottleneck on heirarchical LSPs.
          Alex:  Sorry - had to be at FORCES, b/c the chairs couldn't
                 be there.
          Bill:  I was defending Ron from the Internet area

   OSPF: Acee Lindem  : Several docs go to IESG.  Some pending - how far to go
next.  Still have the more radical OSPFv3 changes.  Less radical
OSPFv2 use of COS for multi-area pushed to IESG.  Talk about the MANET
extensions; will go to WG & it'll be trade-offs whether to add
complexity..  Still waiting on normative references...  OSPFv3 TE
draft (do have an implementation on it) hit on a question about
supporting an ASON requirement, to show that it can be done with
OSPF.  That's going to come back & not go to IESG right now.
   PCE:  JP Vasseur:  Everything is well.  The PCE Architecture ID is
going to final stage.  Generic reqs ID is making quite a bit of
progress.  Next is more discussion about the communication protocol
itself.  Reqs on PCE discovery underway & now need to talk about protocol.
   PIM:  Alex:  There's a doc that's on my plate & I'm still
                reviewing.  It's a good spec.  I hope to be done with
                it in a couple weeks.  
   RPSEC:  Alex:  The general threats doc went through the IESG &

           Sandy Murphy:  Generic Threats doc through IESG & there were some
                 strong objections to editorial problems.  Draft was revised &
                presented a couple IETFs ago.  RFC editor said changes looked very
                different, so changes will be summarized to the WG.
Draft is in RFC editor queue.
           Alex: BGP doc is pretty much ready.  
           Sandy:  Right, needs last call.  Also Russ presented at the
           WG about MD5 & routing protocols & will suggest that it be taken on.
Not sure anything else is active.

   RTGWG: Alex: GTSM revised draft had some comments.  Dave will
   update & then see how to proceed.  For IP FRR, the framework & LFA
   drafts have been updated.  Also, accepted draft on microloop
   analysis & prevention & an IPFRR MIB doc was accepted.

   SSM: Bill: SSM Arch is just waiting some minor revisions & then
   will last call.

   VRRP: Radia Perlman: VRRP for IPv6 reviewed by IESG & a concern by
   Sam Hartman about Secure ND and VRRP inter-op.  VRRP MIB needs a
   revision to address WG LC comments.  Subsecond timers draft needs
   more review.

Alex:  FYI, there was a WG formed in the INT area called TRILL that
would benefit from praticipation from the routing folks.  If you can
read drafts, show up to mtgs, comment, that'd be good.

Bill:  Unfortunately it's Thurs at 10:30, which is same time as IDR.

Bill:  GMPLS Change Process has doc rewrite "in progress", which means
not started yet.  Feedback was its too negative b/c doc kept saying
here's where it doesn't work and so on.  Instead of just making minor
tweaks to doc, will instead start from scratch & will instead talk
about how a successul path occurs & then talk about the exceptions
separately, so it doesn't sound like "this is how the IETF will
prevent you from doing what you want to do to GMPLS".

Bill:  Routing Protocol Standardization  RFC1264 predates RFC2026
       It's always been unclear to what it applies.  Does that mean a
new option or is it protocols only?  Where to draw the line & how do
you decide?  We've been saying for years that we'd update this & we
finally got around to it.  Changes from 1264 - updated to require 2
interoperable implementations for PS.  1264 said needed 1
implementation & written clearly enough for others.  Easiest way to
tell is by having two implementations.  Add explict descriptions -
things that modify routing computations or distributed databases.
Things like VRRP on a single route or FORCES don't apply.  Add an
escape mechanism (IETF Last Call) about when to apply or not apply
these in a situation where it's unclear or we should, this will be
said in the IETF Last Call & this will give the community a chance to
comment.   

Basically specifies all of the things that need to be done to submit
it; this collected them together so that there's only 1 place you have
to look.  Clarifies exactly what parts applies to the protocol
extensions.  For draft standard & full standard, the protocol needs
applicability and protocol analysis about how it scales and so one,
but extensions do not.  Removed security description from reports, b/c
it is already required in the drafts.  When 1264 was written, it
wasn't required.

There's a new structure to the doc.  There's a section that says here
are what the requirements are and then a section that says here's what
you do to submit.  Here's a summary of the process & other than the 2
implementations for a proposed standard, these really aren't changes.
(See presentation)

Since this document is open, we've had this discussion before in this
forum & people are generally ok with the requirements that 1264
imposes.  I'm going to ask about that again while they're summarized
on this chart.  

Acee Lindem:  The things that are more stringent, for PS requiring 2
implementations.  Would that be to any extensions as well?

Bill:  Yes, that was the plan?

Acee: Ok.  So you'd need 2.  That means you'd have to wait for any
proposed standard until there are 2.

Alex:  Right, by default.  This assumes that the extension may change
the routing dynamics.  If the WG chairs think that it shouldn't apply,
then can discuss with ADs & decide.

Acee:  Ok.  Then the protocol analysis can be quite implementation
specific.  Is that really useful?

Bill:  We can debate the amount of detail it goes into - but having an
analysis of the protocol is useful.  The specifics of what should be
contained in the analysis could be changed.  Moore's law keeps
improving resource, but not infinite.

Acee:  Could be a lot of work to collect.  Third question is having
the MIB for each extension?  MIBs tend to batch up extensions and then
have in a particular MIB.

Alex:  Even now, for PS need MIBs in ID state now.

Bill: Sometimes extensions are hard.  Sometimes MIBs weren't written
in an extendable way.  Look at the BGP MIB2 which is dragging out.
Definitely something to think about.

Acee: I'll definitely

Kireeti Kompella:  Why 2 implementations for PS?  You could say if
there was 1 author, then the author could have done it.  What if there
are more than 2 authors? Etc.

Alex:  You have to draw the line somewhere.  You may have authors from
different companies, but when you read the doc, you realize that
you're the first to read it and think about how to interoperate.  This
isn't a theoretical problem.

Kireeti:  I understand the intent, but I'm not sure this captures it.
What does 2 independent mean?

Alex:  The way it is defined is that the code-base should be different
for these.  This is the origin for each.

Kireeti:  Another point to pick up on Acee's comments.  We did the TE
extensions for ISIS and OSPF & now doing for GMPLS, but we never did
the MIBs.

Alex:  So you're critizing yourselves?  What do you think would
capture the requirement for the 2 implementations?

Kireeti:  Someone who isn't one of the authors (or working at the same
company) who has read the draft & actually implemented it.

Bill: At some point, you have to ask if someone is trying to game the
system or just trying to get things done.  We'd have to extend the doc
a lot to protect.  What we should possibly do is add the reasoning.

Dimitri:  What is the comparison work expected to give in this
context?  For example, extending a specific protocol?  pt 2 of Sec 5.2
 How would that translate to extending a specific protocol? 

Bill:  That requirement is more targeted at if you have a new
link-state protocol.  There'd need to be a big improvement over OSPF,
before we'd consider...

??: Does that apply to label protocols as well?

Tony Li:  First, regarding requiring 2 implementations not by authors,
we'd not have BGP...  Second, history suggests that the work involved
in producing a analysis doc is quite a lot & usually given a cursory
look.  If there is a need, I'd like a clear description 

Bill:  Description is copied from 1264.  It's open for discussion.
Alex:  If we don't do protocol analysis to understand scalability or
that it's documented, how do ensure that it's understood.

Tony:  I've never been in a WG where we haven't discussed the
implementability to death.  In practice, we're

Alex:  Protocol analaysis isn't just about implementability.

Tony:  If we didn't argue about the scalability during the protocol
design, something is broken.  All this is doing is documenting what's
discussed in the WG.

Chris:  Beauracracy - we work this stuff out in the WG.  It's supposed
to be a check on the system...  I think this might be too much
overhead.  When's the last time that we had a massive routing problem
that just swept through?  I think this is just over the top.

Alex:  What I'm hearing is that compared to 1991, the general
expertise is much higher & we're already having these discussions.

Adrian:  Me too.  I haven't seen a reqs draft that hasn't discussed
the scalability.

Loa:  If we say that this protocol analysis isn't mandatory, then we
may at least point to the WG discussion.

Bijan Jabbari:  Not in a position to do theoretical analysis in
release 1, until there's some stability.

Alex:  I hear you, but don't totally buy that.

Bill:  If there's something captured in the protocol analysis that
we'd find useful, but the protocol analysis doc itself is too heavy to
capture that, then we can find another way to do it.  There was a
reason; if that reason was that we were being too protective, then
removing it is good.

Bill:  Let's take it to the list.  Tony, would you be willing to start
a discussion on mailing list.

?? :  When you're starting from scratch, you don't want to get into
the details & need to start at top.  Inevitable to have more
releases.  Also, it shouldn't be 2 implementations - but should be >2,
and an odd number, for tie-breaking.

Adrian:  I'm really worried about the proliferation of MIB modules as
a result of requiring new MIB modules for each tiny little extension.
That's its own scalability problem.  It's possible to have a MIB
module to collect the extensions, but it's kind of messy.

Alex:  Yeah, it should be possible to say "why we don't need any
changes" or to point to the base protocol extension that says where
the MIB parts (whether RFC or draft).

Adrian: Are you saying that it's ok to have a draft say what changes
would be needed for the MIB

Alex:  In the email that you send to the ADs, you can specify where
the MIB stuff is for extensions.

Bill:  We may not have completely expressed or discovered which things
are different for extensions.

Kireeti:  If we discover that MIBs are not the only way of managing,
like XML CONF or such, then will the draft say MIBs or just
managability.

Bill:  The goal is not to stay behind the curve.  If we publish this
today, it'll say MIBs.  If things change tomorrow, we'll change it
tomorrow.  If the management community makes a decision to change,
then we'll reflect that.

Bill:  I'd be happy to hear any of these questions that people hear
and anything else brought up on the routing-discussion mailing list.
We'll send a follow-up after the meeting & asking for discussion.  
Really, the whole thing is open for discussion.

============
Talking about draft-bhatia-manral-diff-isis-ospf-01.txt

??:  What's the motive?

Danny:  We'd like to push this forward in the routing working group.

Bill:  If anyone has read this doc, please send comments.  What role
does it play?  In a way, it's an educational doc.  Is that a bad
thing?

Yakhov:  The motivation between OSPF and ISIS and discussions from
10-11 years ago; does this neeed to be rehashed.

Alex:  The doc captures the technical differences.  Do you think the
draft should capture the political background?

Yakhov:  Why not?

Alex:  Do you think there's something wrong with capturing the
technical diffs?

Yakhov: No, but should also capture the political.

Alex:  Send the text please.

==================
IPv6 Label Switching Architecture Proposal:
( http://www.ietf.org/internet-drafts/draft-chakravorty-6lsa-01.txt
 http://www.ietf.org/internet-drafts/draft-chakravorty-bcc-flowlabel-00.txt
 http://www.ietf.org/internet-drafts/draft-chakravorty-bcc-fec-00.txt )

Sham Chakravorty:  starts presentation...

Acee Lindem:  Are you comparing to something?  

Sham: well, yes, MPLS, but not completely

Yakhov Rekhter:  There was a presentation 7-8 years ago to the MPLS WG
about using the label tag for IPv6.   It was rejected b/c it had no
support label stacking.   Therefore, would need to support the MPLS
shim header.   Today we have existence proof that supporting the label
stack is important.  You still have

Sham:  You need to see our presentation.  We don't want to use MPLS
labels.  We try avoid that and to avoid MPLS label stacking.

George: So this will be very interesting, b/c absolutely everything
that's interesting in MPLS has a label stack.

Alex:  Let's let the presenter finish.

Sham:  Talks about extensive QoS Label space - 20 bits plus 8-bit
traffic class fields.  Problem with MPLS because QoS bits taken from
label space.

Francois LeFaucheur : RFC doesn't say that.  Can use the 3
EXP bits or use different LSPs or combo, but people don't need 64
usually...

Sham:  Discusses need for 11 different precedence & preemption
classes...

Francois: More discussion on how this can be done.

Alex:  Let's discuss after presenter finishes.

Francois:  I'll make a super-set comment of what Yakhov said.  There
are a number of things that are the same and a few that are
different.  What's different is how the label is encoded in the header
& the other is that there are many ways that a label is attached to a
FEC.  The label assignment could be data-driven.

Sham:  I didn't say that. The label can come from downstream or
upstream, etc.

Francois:  One difference is that you are proposing that the label
assignment can be driven by data.  Both of these ideas have been
discussed in the MPLS WG many years ago & both have been rejected for
good reasons.  We can discuss that but I don't think this changes.

Sham:  So what you're saying is that we have MPLS & we'll just use
this.  IPv6's flow label will stay unused.  I'm not here to debate
MPLS.  We're just trying to use the flow label.

Yakhov:  Just b/c IPv6 has a field called flow label doesn't mean that
it has to have practical use.  It has been considered before & been
rejected.  Unless you've good reasons, why should we reconsider?  You
have in one of your final slides, considering VPNs.  That's been done
with label stack.  How do you include label stacks?

Sham:  We don't need label stacks.  (Bit of back & forth)  Will take
off line.

Tony Li:  DoD has a preference for off-the-shelf.  Why not use 

Alex:  Many people in room not comfortable about defense discussions
of a particular country.

Ross Callon:  In some previous jobs, I worked on the details of IP
forwarding engines.  One thing that made it difficult was the variety
of different formats & combinations that practical products have to
do.  It's highly desirable to keep the number of combos down to a dull
roar & to keep it highly stable.  If you're proposing something that
affects forwarding hardware, there's a substantial time delay.  Unless
there's a substantial reason, then no need to change.

Adrian Farrell:  There are environments where we can't stack labels.
If you want & have a need to do layer-3 switching, then that's what
this is.  I have an issue with your saying that there's no label
distribution protocol & then putting up a slide showing one.

Sham:  I didn't do that.  I was showing the 3 models for generating
labels; I was showing the locally generated labels.

Adrian: When you say locally significant, you mean to the link, not
the router.

Sham: I mean to the flow.

Adrian: Both sides of a link need to understand the label.  You can't
say that you don't distribute the labels & then do so.

Sham: The forwarding mechanisms has to do with setting up the label
from B to C.

Adrian: Does B examine the label on the packet from A in order to
decide on a label to send to C?

Sham:  We don't assume that.

Joel:  Let me try to summarize.  MPLS is used for a lot of things.
Some of those are IPv4 and IPv6 and some of them are bits that aren't
even packets.  That's an advantage.  Another advantage is using label
stacks.  If we put stuff in an IPv6 header, then we lose both of
those.  My network does MPLS for lots of reasons & not to try to make
the forwarding plane faster.  You're not addressing the reality of the
work.  

Dino:  I'm going to try to give you constructive feedback.  Most of
the label stacks are 2 (Kireeti says up to 5), & there are plenty of
places where bits could be taken from IPv6.  How fast do you need
this?  If you want this to go in software, you can switch on whatever
you want.  If you want this to go in hardware, then you could put it
in the destination address; it's 128 bits, which is plenty.

Sham: Where we're trying to use this is to avoid the 

Jim Bayant:  First, this isn't done b/c there's an extra field.  The
objective was to use the flow field for radio networks.  This
architecture permits a discussion of how to use this flow labels
end-to-end.  We're not trying to change the forwarding plane.  We
don't have all the answers.  We think this is something that needs
discussion.  We've not been using radio networks.  We could have to
run at 20 kb.  We could hopefully run at 10 GB.  There is an
implementation & the point is that we're coming to you because we
think there is a purpose...

Alex:  OK. Question to presenter is why are you trying to switch on
the label?

Sham:  If the label were fixed, it's more like part of the address.
With a label being switched, it can be used for forwarding packets.
The next iteration we want to go in is to not forward on the IPv6
header.

Alex:  Why is forwarding on the label better?

Sham: Because the 40-byte header is too long for the
bandwidth-constrained systems.

Alex:  Something like header compression then?

Sham:  We've tried that, but it has its own issues.

Tony:  Looks like all you're doing is saving 32-bits from the MPLS
label.  Seems like you could be doing header compression with the
standard MPLS header & then get there faster & with off-the-shelf
hardware.

Dimitri:  You would be able to say that I've got a first packet & then
insert a label on which you could later do the forwarding.  What is
the level of standardization that would be needed to get that working?

Sham:  First, the first packet wouldn't have to get its info from the
address.  From the second packet, would switch based on the label. 

Alex:  We're running out of time.  Folks who are interested in
discussing this can stay here & discuss.  My summary is that you would
need to work more on better articulating the requirements for your
mechanism and advantages of your method versus the methods that we
have today.

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion