RTG area
IETF-59

Intro
Bill:
Routing Area Web page fallen into disuse
New routing area directorate folks to replace Tony and Tony.
New routing working group as catch-all


Close BGMP, IDMR
- Saying this for 2 years
- Now date is set to wind them up (July 2004)
- Real target!


Create BFD WG before San Diego


Create RPSEC WG especially for BGP security around October.
- Requirements are coming somewhat from other SDOs.


Dave:
What is the disposition of the BGP draft?
Bill:
See slide later


WG reports
BGMP
- after approval as experimental found bug.
- no AS number in BGP open message, but text said to use it!
- new revision planned


Dave:
Will we have no stds track IDR protocol for multicast?
Bill:
Yes, that's what it means


Dave:
SSM makes stds track then this means we endorse SSM as *the* multicast IDR 
for IPv4
Bill:
Good point.
But since scaling problems with one, and almost no interest in BGMP


Dave:
Different to say no interest in BGMP and no interest in multicast IDR
Bill:
But clearly no interest in scalable protocol
Maybe this means there is no interest?


Dave:
But there is interest. And experimental protocol is deployed.
Have been asking this for some time.
This seems to be a statement to solve implicitly using SSM


Bill:
Don't think this is what we're saying.


Peter:
There is ASN traffic in the n/w
MSTP does the job today.
Has problems but not seen them.
It is holding together and being used.
Try to figure out the growth of MSTP in the Internet and try to predict 
when we will hit the problem.
Someone needs to figure a protocol to address all required functions


Bill:
Hard to say where effort to figure out IDR multicast should go
WG charter doesn't help. cf IDMR WG.
Takes more than a place to do the work. Takes energy and ideas and 
feeling is that those aren't coming.


CCAMP
Adrian:
No questions.


IDMR
Bill:


Dave Thaler:
what is the status of DVMRP. no security


Bill:
pushing for proposed std track since it has uses in certain 
environments


IDR
Yakhov:
Finished base spec. Very significant.
Many docs now go to IESG
Can now progress other items
Can now start new work
- cannot pick it all up
- need feedback for priority list
  - SPs and vendors
  - please input
Sue:
Thanks for BGP implementation reports respondents
Thanks to the people who processed the 260 questionnaires


ISIS
Alex:
New co chairs for ISIS
Should ISIS stds go to stds track?
IGP pt-2-pt pending revision


OSPF
Alex:
graceful restart recently approve
v3 authentication and MIB update to ADs
2547 extension for loop prevention minor comments from IESG


interesting discussions on mailing list
multi-address families, and multi-area adjacencies


MANET
Alex:
DSR spec is pending update after AD review


RPSEC
Alex:
Needs more input on requirements. Please do help.
Security requirements for BGP security (see previous new WG)



Routing WG
Alex:
New WG
No documents yet.
Wrong!
MPLS/SPF for traffic engineering
- expect comments and last call soon
Please subscribe to the mailing list
rtgwg-request@ietf.org


MPLS
Loa:
Had meeting Monday
Most cycles on TE
- P2MP
- OAM framework
A couple of docs about to IESG or with updates after review (7 or 8 of 
these)
12 docs in RFC ed queue about to be released as references are sorted out


??Topic??
Bill:
Spec updated to fix a blackhole
Means spec was reviewed very well!
IESG in a month or so


SSM
Some delay while discussing Apple(?)'s claim on IPR
Believed to be resolved


VRRP
Bill:
v2 approved
v3 (IPv6)
- some issues found
- most resolved


Routing Research charter
Avri:
see slides


Closed groups are going to do quarterly reports to the list and an annual 
gathering


Research proposals please
- short term (for example as rejected by WG)
   - complete the work in 6-18 months
- longer term
   - e.g. is there life after BGP?
   - e.g. routing and protocol scalability
This is research so if the end result was "bad idea" this would still be 
good research.


meeting slot planned for ietf 60
interim (co-sponsored) meeting is planned


Alex:
How to get onto closed mailing list?
Avri
Send to main list asking for "in"


Alex:
How do you get deliverables from a research group
Avri
We have to work with them to set up milestones
Keep open line between rtg area and rtg working group



IANA
Alex:
Who read the draft?
answer ----?


see slides


Issue - deployment of drafts uses interim codepoints
Often considerable deployments


Other non-rtg similar issues.


AFI/SAFI
Sue:
see slides


Used *before* reach problem stated by Alex


Kireeti wants an AFI


Alex:
Thanks to Kireeti


Bill:
RFC3692 on experimental alloc
suggests pick a small set and designate them for experimental alloc
default behavior is non-support - needs to be turned on by operator


Bob:
IPv6 had discussion on ICMP codes
ended up with 3 options
could use extendible codes
IPv6 leant towards alloc when adopted by WG
- becomes permanent when RFC
Need a generic way not just rtg-area


Alex:
that is intention


Bill have you adopted any ideas?


Bob:
No, beginning to put language in


Bill:
in case of temp alloc, concern is you assign to a proposal, but WG now 
needs to massage packet format, but it is already deployed with a 
number, what do you do? new number?


Bob:
Up to WG chairs as per Alex
What about individual submissions?


Alex:
This doc tries to address stds action policy
not individual - would need to go through IESG


Kireeti
No early allocation for individual drafts


Bob:
Same problem for ICMP etc because this is "IESG action"


Kireeti:
Alex and Kireeti is stds action for early alloc
Sue is talking about experimental which might go to stds track


Alex:
Would this be useful to IPv6


Bob:
Yes WG would consider using it
twiddling values in experimental by end user might be not good


Kireeti:
This is experimental only


Bill:
Would not be good for major deployment


Dave:
In last proposal not clear whether to assign a range but not a specific 
number, or if WG
says specific number.


Bill:
RFC doesn't say


Dave:
Not asking about RFC. What about configurable for experimental. Is usage 
agree ahead of time, or is it up to the implementer to force operator to 
type it in?


Bill:
Either. must be config because it is from experimental range and someone may 
have conflicts


Dave:
Compare different proposals. like subrange == experimental
Or mark as temporary out of ordinary == good because no change in 
implementation if no changes


Bill:
disadvantage if you rev or peter out. cannot reclaim until timeout


Dave:
Bob and Brian, 27 allocated over ten years
Time limit may not be important in large space


Kireeti:
Not all codespaces (eg IP protocols is implicit stds action) have 
explicit actions associated
Proposal is specifically for stds action space
Need stable allocation
Experimental is not a big deal if there is a change
First come first served is dangerous in a different way


Dave said what does one year mean when it expires? need to make this 
clearer.
Early is in some sense temporary
If spec dies it becomes "deprecated" and then time that out
(e.g. RSVP case, value was not marked deprecated so IANA 
re-allocated)


Alex:
Sense of the room, about draft-kompella-zinin
approach is useful? "pretty good"
approach is not right? - just Kireeti ;)


ditto Afi/safi
useful? very few
not useful? none
need to ask in IDR


IP/LDP loop protection
Alia:
see slides
pre-compute an alternate path
cf. IGP fast reroute


questions after second presentation


next hop fast re-route
Naiming:
see slides


Yakhov:
slide 3
R1 R2 is pt to pt, but suppose multiaccess media?


Alia:
if all nodes in same area, and R2 is the primary neighbor then R1 can 
assume traffic is from R2


Yakhov:
If SPF takes zero time then would there be any value


Alia:
propagate is non zero
install time is non zero


Yakhov:
not need to propagate to all


Alia:
Some cases there may be more than one router


Yakhov:
If only one?


Alia:
If more than one then it is valid


Kireeti:
80% if no U-turns?


Alia:
79.5


Kireeti:
Real network?


Alia:
Yes


Kireeti:
U-turns in real networks?


Alia:
Yes


Cengiz:
I tried without u-turns
even then in the networks I tried I had 90%


Kireeti:
I'm surprised that the number is so low w/o uturns because network is 
dense


Alia:
topology dependent
analysis based on src/dest pairs
lots of traffic not covered by loop free
percentage of traffic is not same as percentage pairs


Rahul:
what if equal cost paths to neighbor


Alia
It works


Rahul:
R2 is PLR
R1 u-turn neighbor
How does R1 know where to put traffic


Alia:
If there is only one primary neighbor


[note taker got confused ....]


Rahul:
when I said doesn't work I meant reduces


Alia:
never reduces below loop free w/out utirn


Yakhov:
Covers node failure?


Alia:
Yes


Ina????
Deployment considerations in n/w


Alia:
Need to support IGP extensions for u-turn


???
How fast


Alia:
depends on h/w
per interface forwarding table


Kireeti:
What effect on the size of the routing table


A
Forwarding table not routing table


Kireeti:
bad?


Alia:
Not as bad as one per i/f since max two


Kireeti:
has naiming done coverage?


Alex:
take discussion to RTGWG (not routing discussion list)


RIFT
David Meyer:
slides
send questions to the GROW meeting


OIF routing
Lyndon Ong:
there is liaison statement
- need to find out relationship to get people access to it


OIF has been working on E-NNI routing specification based on OSPF model for 
transport n/w is similar to ITU work
elements grouped into domains and connected to each other through E-NNI 
reference points
some domains may use distributed control and others may use EMS but still 
interface to other domains through sig + routing protocols


hierarchy
domains == RA (routing area)
model is similar to ITU model
domains may be partitioned to give mulit-level hierarchical 
relationship


Assumptions
see slide


Status
see slide
testing at OFC in 2003 did not test any hierarchy extensions


not a std solution
defined as prototype for testing


Rahul:
concerning to see changes to OSPF without telling OSPF WG
hierarchy is alarming
I'm expressing concern


Lyndon:
recognise concern
hierarchy is not simple and not something we have been testing
bringing it here now


Dimitri:
How does this differ from CCAMP DT routing for ITU since that work 
follows ITU model
Why take this experimental solution and not develop based on DT


Lyndon:
problems here are consistent w/ problems in DT
difference here is that OIF has gone ahead and defined what some of these 
extensions might look like


Russ:
please give ptr to url


Alex:
liaison will be available


Kireeti:
CCAMP chair hat on
worked on it for a while and bring it now
say this is for testing which is good
but now you have brought it to us
if ask for rubber stamp won't happen
but you need codepoints and we want a good relationship


tell us the requirements, and we will extend since we know protocols


big risk of two sets of solutions that are different


compare with RSVP work where OIF/ITU work is not compatible


protocols are understood here where implementers and deployers are found


are you asking for rubber stamp
what is end goal?


Lyndon:
not approved through OIF as an implementation agreement
it is a draft
if we can work out how to do it in OSPF then it is not too late


Kireeti:
do you want us to take your changes
do what with them?


Lyndon:
oif did send a liaison asking for comment/feedback
sent to ccamp chairs and routing area directors
expectation is not rubber stamp
expectation is that this group have a look at the problems that 
generated these prototype extensions
hope is that these problems will be addressed through std extensions of 
OSPF
whether the extensions change is up to this group


Kireeti:
would have been better to bring requirements


Arthi:
we can work through the problems and have solutions to them and get 
discussions


Lyndon:
work wasn't done for the sake of it
people looked at specs and said "we don't know how to do something"


Zafar Ali:
need to understand overlap with ITU requirements
follow same model


Lyndon:
should look for delta to ASON requirements


Zafar:
if so we can overlap the solution space


Dimitri:
how much is change to basic protocol and how much to TE LSAs?
how has OIF evaluated impact analysis


Lyndon:
expertise for impact is in this group
changes were to achieve specific functions


Alex:
there is concern about OSPF extensions being defined elsewhere
your answer is your not trying to define a std
your intention is to experiment and see what the extensions might look like
your intention is to come here and work with us


apology to Christophe - out of