Corrected minutes for IETF59/RTG Area

[Alex Zinin <[e-mail]>]

Folks-

 Minutes with some corrections below.
 I'll see if there are any more before
 submitting a corrected ver to minutes@

--
Alex

Intro
Bill:
Routing Area Web page fallen into disuse
New routing area directorate folks: Dimitri, Loa
New WG chairs for ISIS: Chris Hopps, Dave Ward.
Thanks a lot to Tony and Tony.
New routing working group (RTGWG) as catch-all for small projects

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.
- Will take requirements from RPSEC

Dave:
What is the disposition of the BGMP 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 inter-domain routing 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
MSDP does the job today.
Has problems but not seen them.
It is holding together and being used.
Try to figure out the growth of MSDP 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 questions in the implementation questionnaire

ISIS
Alex:
New co chairs for ISIS
Discussion in the WG: should ISIS stds go to stds track?
IGP pt-2-pt pending revision

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

interesting discussions on mailing list:
 - MANET extensions
 - multi-address families,
 - multi-area adjacencies

MANET
Alex:
DSR spec is pending update after AD review

Will be making a decision wrt the direction with MANET-OSPF extensiosn

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
[e-mail]

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

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

SSM
Had 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?
About 15 ppl: not bad

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 for co-authoring, he wrote most of the text

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 time


_______________________________________________
routing-discussion mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/routing-discussion