draft meeting minutes from IETF 55

["Bender, Andrew" <[e-mail]>]

Notes from the routing area meeting are included below. 

I have tried to capture everything that transpired... in some cases I may have paraphrased mic dialog. 

Mic comments are delimited by '<yourname>-'. New question threads start with '*'. If you didn't give your name at the mic, or I didn't otherwise know who you were, you may be a "somebody". If you would like me to fix this, or believe I did not capture your comments accurately, please email.

Regards,
Andrew Bender
taqua.com

---

***
*rtgarea
***
Routing Area meeting minutes from the 55th IETF
Monday, November 18, 2002
1930-2200 Salon II

AD's:
Bill Fenner <[e-mail]>
Alex Zinin <[e-mail]>

Announcements:
alex-bar bof at champions

New Chairs:
-ospf
Acee Lindem <[e-mail]>
Rohit Dube <[e-mail]>
-rpsec
Tony Tauber <[e-mail]>
-vrrp
Mukesh Gupta <[e-mail]>

On the RTG Area Directorate:

-an advisory group
-improve technical review
-non-goals
 substitute ad review
 substitute ad decisions
 for secret cabal
-current members are:<lots>
-directorate mailing [e-mail]

Working Group Updates:

-bgmp-
bill fenner-
plan has been to publish current work as experimental to checkpoint, so it doesn't get lost
WG last call; comments came in; revisions made to reflect this; then on to iesg

-forces-
group co chair-
base documents all passed last call (reqmts, framework, informational)
current focus is the model
opened submission for protocols (main goal of group to create protocols)

-idmr-
bill fenner-
igmpv3 spec published as RFC3376
dvmrp draft - draft-ietf-idmr-dvmrp-v3-10 waiting for a security section that makes sense
additional draft currently in progress - multicast router discovery: draft-ietf-idmr-igmp-mrdisc-09

-idr-
yakov rekhter-
charter update occurred-decided to not accept any new documents until BGP base was finished as draft standard
RFC3392 update to 2842, "Capabilities Advertisement with BGP-4"
idr md5 keys ended up in dead state, not sure why 
*bill - transport area wanted to take over IP MD5. Will talk with authors to make sure this gets updated...

-base spec 
review period of 2 mos
over 60 comments
thanks to andrew lange for collecting comments
draft-ietf-idr-bgp4-18 incorporates updates
WGLC expected November 29th 

need a mib to move to draft standard
need fixes to security section, hopefully by end of this month

accepted idr-bgp-vuln-00 since security section of base spec is weak.
base spec will keep its existing security section with a pointer to this work.

no progress in BGP WG right now
new technology / ideas can be freely dicussed on mailing list

-isis-
tony przygienda-
-status
3 recent RFCs:
RFC3358 - Optional Checksums in ISIS 
RFC3359 - Reserved TLV Codepoints in ISIS 
RFC3373 - Three-Way Handshake for IS-IS Point-to-Point Adjacencies 
MIB(10) LC due in deceber 02
cryp auth(03) AD comments
GMPLS extensions(14) AD comments
TE extensions(04) AD comments
IPv6(03) LC Dec 02
<more belongs here-waiting for tony's email>

-comments
*kireeti-is there anything that can be / needs to be done to make ISIS work standards track?
alex(AD)-to date there lack of understanding of which extensions IETF can standardize. 
also, there is no authority for TLV assignment.
however, jdc1 and isoc draft agreement defines internet-specific extensitions
will ask iana to number these
*kireeti-can these reach standards track?
alex(AD)-sure

-manet-
scott corson?-
a lot of issues remain with the technology
pre-standard algoritihims being used to support current interop
otherwise, has been "in stasis" for last few years
rechartering to reduce scope
irtf group to take on part of the problem
there are still "2000" people on the mailing list
-comments
alex(AD)-sent a message to mailing list for ideas

-msdp-
david meyer-
been trying to close down for 3-4 years :)
did not meet this time at ietf 55
mike mcbride, leonard giuliano will be doing clean up
draft-ietf-msdp-spec-14 WGLC has been issued.

-ospf-
acee lindem?-
new co-chairs as of late september
first task:clean up charter
update to RFC1587 OSPF NSSA Option, draft-ietf-ospf-nssa-update-11, is in editors queue
pat murphy will be at the next meeting in SF

OSPF TE Extensions, draft-katz-yeung-ospf-traffic-09 is ready for IETF LC
OSPF Refresh and flooding reduction in stable topologies, draft-pillay-esnault-ospf-flooding-03 will go to last call soon
both of these are in some stage of AD comments:
Detecting Inactive Neighbors over OSPF Demand Circuits, draft-ietf-ospf-dc-05
Alternative OSPF ABR Implementations, draft-ietf-ospf-abr-alt-05

-pim-
sparse mode twice publised as experimental and informational
save security updates required, should be able to make standards track this time
dense mode not there yet
mib is moving along

-rip-
dead in all but name-mailing list stopped 2 years ago
some work is pending, but will shut down the WG for lack of participation

-rpsec-
tony tauber-
generic threat drafts planned RSN
generic requirements after that
wg should be a forum for discussion of routing protocol security, etc. 

-ssm-
pretty close to done
overview, draft-ietf-ssm-overview-04, passed WGLC some time ago, comments have been addressed
update to architecture, draft-ietf-ssm-arch-01, will be republished with ipv6 clarification wrt to 3306 and 3307 just as soon as I can upload

-udlr-
WG originally chartered in 1996 to integrate unidirectional links, to make these emulate bidirectional links
goal-allow current l2 and l3 protocols to operate without modifications
in march 01, RFC3077 - A Link-Layer Tunneling Mechanism for Unidirectional Links, was issued
new charter was created in june, 01 to provide informational RFCs with example applications
several drafts in yokohama on experiments, et al:
-DVMRPv3
-PIM-SM
-PPPoE
-security issues
ongoing work of gorup is to create a general document detailing entire list of protocols known to work with udlr
describe new experiments including ARP, DHCP, PIM-DM with satellite line example
also identify issues
all previous drafts have been obsoleted
charter needs to be updated, since WG is not producing a list of drafts anymore

current goal is to push current RFC 3077 to draft standard
administrative work still needs to be done in pursuit of this
interoperable implementations have been demonstrated by: Hitachi, Udcast, Ipricot, Sony, Thomcast
however, all do not implement / use standard udlr features

-vrrp-
VRRP for v6 draft-ietf-vrrp-spec-v2-06 is "pretty much ready", but "needs tweaks"
MIB for v4 needs a little bit of work
need group to look at VRRP security model
authentication failure is almost worst than letting a rouge participate in vrrp group
miscofiguration can ultimately result in a loss of connectivity for group
security section for v4 vrrp also needs to be looked at in this regard

Panel on Fast Convergence:

cengiz asked to provide framework
bof type disussion will be conducted to decide whether to take on this work

-IGP fast reroute presentation-
cengiz alaettinoglu-
slides promised at http://www.packetdesign.com/publications 
(scribe's note: it appears this link should have been http://www.packetdesign.com/pubs_000.html)

-convergence framework intro
link failure
1. hw detection preferred, or hello protocols
2. damp recovery
reaction to failure
3. switch to precomputed detours, via MPLS or IGP
4. generate lsp
5. trigger an SPF
propogation of the news
6.lsp flodding
convergence
7.spf completes

nanog talks in june showed vendors are improving
kompella, retana drafts prove work is still being dome

-mechanism
should be able to converge in a few ms (should be << 100ms)
horizon = (single_spf_time) + (network_diameter) x (scheduler_delays)
requires lsp to be transmitted before data packets and spf
lsp ahead of any packet by an SPF time
requires fast route install, small cpu sched delays 
...and really good implementation :P

-road blocks
fast hw detection works today for POS and DWDM (scribe, to self: hrrm...)
prioritize control
vendors are working on two-level FIB lookup
first:BGP, then IGP
assuring the small scheduling required is the biggest work item here

-solutions proposals
e.g. precomputed restoration as provided by MPLS FRR
ISPs have reported success with this scheme in practice
works to protect from single (vs. compound) link failures
typically only used in core, because of complexities presented by MPLS full mesh requirement
can we use the do the same for IGP, prior to SPF computation?

-igp 'frr'
goal is to have at least two: shortest, and necessary feasible 
'feasible' = neighbor whos distance is less than yours; e.g.:
ISIS downsttream
EIGRP feasible successor (scribe: ugh...)
could also be a neighbor whose path does not contain 'myself'; this relaxes the shorter distance requirement

-is this 'feasible'?
requires some level of redundancy to be built in to the architecture of the network
most isp networks are redundant: core routers, etc.
*dave-this would certainly be the case for sprint, and don't think it is unusual for ISPs in general

-illustration
graphs of three representative ISP networks shows percentage of routers with 2+ feasible next hops in the path between any two chosen source and sink pairs. example:
those with an ecmp to another neighbor:22%
those with a ecmp or a downstream:~95%
those that are just loop free:~97%+

-commentary
like MPLS FRR, triggering can happen on linecards directly
this is necessary for FIB scaling

-computing feasible paths
brute force: maintain spf trees of neighbors
resource requirement is approximately the same as for cSPF, MPLS FRR

-summary
few ms to tens of ms for IGP convergence is achieveable
IGP FRR can provide relief in the meantime for ISPs without MPLS, or those using MPLS only in core

-comments
*tony g-you may be setting the bar really high; it is cheap to keep the just the second neighbor. doing more is quite resource expensive
*yakov-routing systems include the igp, but keep in mind that igp convergence does not by it self improve / solve routing system convergence. this solves only 20% of problem
cengiz-don't agree. only get good performance in BGP by starting here. there are isp services that use only IGP
*tony g-would like to see a study of how many BGP routes could flip over on top of this without churning.
cengiz-don't need to change IGP metrics by doing this, only when SPF happens.
kireeti-he is flipping in the forwarding path, not control. this does not churn BGP, you could call it cheating if you wish.
*ross callon-don't see anything for the IETF to do here, since this was brought up about five years ago, to the same result; these are all implementation details
*alex(AD)-regarding whether IETF work is required-please wait for other two presenters
*somebody-maybe informational draft / bcp should be created to encourage vendors to do this
kireeti-what are you basing your statement on? (wrt assuming that vendors don't, presumably)
*kireeti-there is a whole slough of work in OSPF on congestion control. you can publish informational drafts. publish source code if you like, but you can't make this standard. what's on the wire is subject to protocols. e.g., LSP flooding is externally visible, but I can do whenever I want inside my box prior / susequent to this.
*tony g.-some juicy interop needs to be done.
*alex-implementation practices should not be standardized. advice to the community in bcps is fine. overall behavior of the routing system IS visible though. If we had decided that only local behavior could be described in the standards then we wouldn't have flap dampening, etc.
*tony-this is tricky. however, one doesn't need two level fib lookup to do this successfully; there are a variety of other clever schemes that achieve the smae result. memory, cpu optimizations have histoorically made implementors' guidelines useless quickly
*alex-if implementors guides are proposed, I will be the first to say 'heck no!'. (speaking only as a card carrying non-employer sponsored IETF member here)
*dave meyer-it is definitely not the case that everybody (i.e. vendors) knows how to do this, since present experience in overt behavior of networks provides a counterexample. 

-protocol livess protocol (PLP) presentation-
kireeti kompella-

-motivation
fast 'deadness' detection - learn that adjacent router is down quicker than is possible today
should be ultra simple for the sake of speed and reliability
single message for multiple protocols - shouldn't have to send 5 duplicate hellos to discover this, etc.

-constraints
don't / should not change all existing protocols
make it extensible

-solution-plp
augments existing routng protocols
message contains: dead timer, list of protocols, status for each
existing protocols don't to JUST this

-problem
deadness-is it control for data plane?
both are desired. 
both are interesting but different
remedy is to make the data plane a "protocol"

-operation
single message captures the state of all protocols on an interface
routing adjacency is up if all protocols and PLP are up

-vanilla plp
ppp keepalives are slow
eth doesn't have keepalives, could be a switch failure in the middle
sonet has oam, but framers can be up when something else is broken 
so, PLP reports loss of hellos promptly in these situations

-dead timer
each sender tells how often to expect hellos
peers need not set symmetrical values
need only send one hello in promised period, but more would be typical
sender can change dead timer without affecting peer (scribe: monotonically?)

-reporting on protocols
includes:
reporting bit vector - ex isis and data plane are supported / monitored
status bit vector - ex isis is up ,data is up
could use hellos to decide data plane status implicitly

-behavior
protocol must tell plp if it is down or up, so plp can report this
plp must tell protocol that adjacency is down through callbacks
also a trigger for loss of hellos / data plane has been proposed

-control vs data plane
only matters if graceful restart / non stop forwarding is used
if only control plane is down, a graceful restart is possible

-what if
plp dies? bunch of adjacencies go down. so, scheme should be ultra simple / stable
protocol dies / plp still up? higher level hellos time out, but this is not a disaster

-next stpes 
must work out interaction with graceful restart in greater detail
identify other protocols that would want to piggyback on this
devise a lightweight security mechanism, if any

-comments
*somebody1-when adjacency is down, what do you do? 
kireeti-you do the same thing that happens when hello times out today
ross-as an example, today, when adj is established, and I miss 3 hellos, I take action. If physical layer goes down, I do the same thing. this indication would be no different from a sonet LOS/LOF.
*followup-specifics are still up to the implementer for the timeline of action after an indication?
kireeti-do what you want, including cengiz's proposal if you wish. this is only a new trigger mechanism
*somebody2-this is a tcp problem?
kireeti-packets can be sent to an all (plp) routers address, or send it to a targeted neighbor. a question is do we run PLP direclty on IP, or via UDP? 
*somebody2-already have frequent rsvp te hello, or methods from a subsecond igp approach
kireeti-these are not lightweight
*tony g-two things: you omitted link bundling issues. also, what about LMP?
kireeti-had this discussion with jonathan. lmp had multiple purposes. it does link correlation; i.e. if you don't want to number them, etc. LMP also does control channel management. LMP will do hellos, but these are only for lmp control channels. Also, it negotiates hello timers, etc. which is unnecessary here. We wanted something simple and extensible. Also, sometimes a one-way problem occurs, with half downs. I don't want to run LMP between two routers.
*tony g-just stick it in LMP. 
kireeti-don't need the rest of lmp for this.
*somebody3-what is the reason for PLP hellos?
kireeti-control plane 
s3-use bgp hellos instead.
kireeti-how fast can you send them? bgp has to do something when TCP resets, or hellos are lost. this changes bgp very little. 
s3-another goal is not to change the other protocol?
kireeti-yes
*somebody4-not clear what adding data on control plane status does?
kireeti-what does a hello do? this does the same thing.
s4-so that's just an up/down state. couldn't everything else could be handled by icmp router discovery?
*somebody5-do we really need reporting vectors?
kireeti-could have isis running, but rsvp down. at a minimum, separation of control plane vs data plane status is needed for graceful restart. agree this is unnecessary if you don't do graceful restart.
*cengiz-it seems that you could do this in systems that are monolithic, or on linecards, in processes, etc. How are flapping links handled?
kireeti-there is a callback from plp saying control is down vs control is up.
cengiz-need to slow down (dampen) the 'good events' (i.e. link up) to prevent thrashing
kireeti-can push the damping into this(plp), but it already exists elsewhere. 
*somebody2-what aobut protocol choice?
kireeti-my choice is directly on top of ip as a protocol type. we probabaly need to start with a well known udp port however. plp must prove its merits first, and we must state why ip direct is better than udp if we go that route.
*somebody6-doesn't this require protocols to change in a period coupled to PLP emission?
kireeti-interaction not specified here. 
kireeti-do I want ISIS hello rate to be the same as RSVP hellos? I can have separate plp sessions if required. preferably this will not be used, because this undermines simplicity.
*alex (as ietf participant)-this should be so simple that it can be implemented on line cards. a few things that could get in the way; e.g. multihop; security is implied in the multihop case. also, where multihop requires you to know which next hop to send to, that could preclude doing this on the linecards. if we decided to use this for BGP, stability might be a concern; IGP currently has some elacticity for loss... this may destabilized. sure wish LMP was simpler.
*john-fyi... lmp has dealt with unidirectional failures with sequence numbers, so this is not an issue.
*john scudder?-remove multihop now! if the question is how to do hellos fast, this is a good idea. not personally convinced fast hellos themselves are a good idea. 
*somebody7-only want to use long hellos in higher layer when I can guarantee plp is run on same lan
*somebody8-multihop only affects receivers
kireeti-if you do multihop, dont run on linecards.

-multiaccess reachability protocol(marp)-
alvaro retana-

-motivation
fast detection of connectivity loss (peers, servers, etc.)

-description
assumes there is a shared media segment / switch in the middle of the path between two endpoints
works below l3 - discovery and maintenance left to devices

-operation
a lan looks like broadcast network to routers
looks p2p to switches

-packet format-only sent on failure
ver
len
auth type
auth string

type 
len 
opcode - 2B
hold time - 2B(mins)
holddown - 1B 
reserved - 1B
l2 addr

extensions are possible 

-opcodes
update 00
notify hard 01
notify soft 10
remove 11 

-questions
*tony g-switch would send the notification?
alv-yes. this way it doesn't depend on other routers
*yakov-link is just one part of data plane... control vs data plane resolution is important for graceful restart
somebody-why not use facilities of existing protocols
yakov-router control plane sometimes crashes because of errors.
*somebody2-any reason why this wouldn't work on NMBA?
alv-can't think of one.
*kireeti-why is it actually a benefit (vs. detriment) to involve switch?
*somebody-what about shared media like hub? can't detect those failures.

Discussion:

*alex(AD)-(to group) should a working group be chartered?
yakov-if we are to follow other gorups, shouldn't we have to do a requirements document first? 
alex-need to create a mailing list for both more generic framework discussion, dialogue on if this work is helpful, and specific protocols. if we see this is useful, then create a group.
kireeti-cant we do this on rtg area list? do we draw a line about if incremental OSPF is done on every router? is plp the way to go or do you need a l2 and l3 mechanism. what happens is there is a hub, etc. Need to expolre these issues first before creating a group

AD Mumblings:

there have been complaints that the iesg process is opaque.
internal operations are implented with a tool dcalled data tracker.
there is a link to a public-version, the ID tracker on iesg web page at https://datatracker.ietf.org/public/pidtracker.cgi
drafts are sorted based on state:

publication requested- id submitted to an ad
ad validation-ads are working on it
revised id needed-if there are comments from ad to author
expert review-not so common
IESG validation-should be considered within in 2 wks
rfc editor-approved by iesg

some things do get dropped
gave some guidelines in yokohama on how long each step should take. 

IPv6 'Liaison':

-routing and forwarding of ipv6 addresses presentation-
brian haberman-

-site locals:intro
ambiguous, limited scope address range. this is the analog of v4 1918 addresses
originally intended for dicsonnected networks. 
FEC0::/10 allocation- should be contained in the site bouandry

-what is a site
the limit of admin control
operators can make their own deicision
scoped architecture draft draft-ietf-ipngwg-scoping-arch-04, has a formal definition

-what does a router do?
depends on the role of the router
can't forward site locals outside
border routers check "zone ids" to determine borders, DA and SA are checked. 

-routing
multiple RIBS: one for global prefixes, one for each site-local zone
global prefixes adv'd out all
only advertise site locals in learned zone

-forwarding
retrieve zone id of incoming if
determine scope of da
lpm to determine outgoing if
...

-what's needed?
feedback
specification for how each routing protocol should handle this
done this in practice using rip ng. feels like / has the same complexities as a vpn configuration

-multicast
v6 mcast has 16 scopes these are:
-heirarchical (scope 4 is known not to be greater thant 5)
-non-overlapping
routers doing this also must maintain more zone ids
forwarding checks also required here

-v6 wg
site locals will be a big topic in this session
open season on how / when / where site locals should be used

-comments
*somebody-is the v6 group doing both unicast and mcast?
*brian-naive implementations can cause resource, forwarding complexity issues
*somebody-make zone boundaries cross only wires not boxes, to simplify
*somebody2-how open is the v6 wg to fundamental suggestions to simplify boundaries
brian-one idea:use traditional igp / egp boundaries
s2-this is deployable now
brian-will it help to say that bondaries everywhere is a bad idea. 
*somebody3-???
alex-need to think about what our message is to the v6 wg
brian-every 18 mos, somebody asks to use extra address bits for something. responses to these suggestions usually include questions on who will manage the space. another approach is to use well knowns. neither are attractive. with scoped addr's, if you see ambiguous address in default free zone, you don't have to do anything with it. 
*jeff haas- this sounds like a case of "if it hurts, don't do that". if you want to communicate, use routing instead of the virtual router approach. maybe we should say that to the wg.
brian-don't have to change the routing protocol to implement scoped addressed, but need to make sure it gets implemented consistently. example given for central cite router in an enterprise that connects to internet, with connections to three other sites in the enterprise that each use scoped addrs. 
haas-having to do policy rouing at line rate is not good.
*somebody-one zone only, or multiple zones
brian-both
somebody-this follows the vpn model, complicates forwarding. don't think this matches the requirements. can we put the boundaries on the interfaces for the previous enterprise multisite example case?
*bill-the discussion on scoping in the wg presumes every interface is in the site. dsl agg routers, and other complex topologies, may benefit from a simplifying assumption. question is, are multiple sites / zones in one router worth the complexity.
alex-go to ip 6 WG for follow up discussion

Comments:

alex(ad)- remember the iesg open plenary. status and direction of the ietf will be discussed. please participate.

Open Mic:

no questions... most already in at "bar bof" in "champions"
_______________________________________________
routing-discussion mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/routing-discussion