[Idr] Draft minutes

[Yakov Rekhter <[e-mail]>]

Folks,

Please review the minutes (see attached) for correctness. The deadline 
for review is August 31, 2004.

Yakov.
------- Forwarded Message

Date:    Tue, 24 Aug 2004 12:51:05 -0400
From:    "John G. Scudder" <[e-mail]>
To:      [e-mail]
Subject: [Idr] Draft minutes for August 2 meeting

Inter-Domain Routing WG (idr)

Monday, August 2 at 1300-1500
=============================

CHAIRS: Susan Hares <[e-mail]>
         Yakov Rekhter <[e-mail]>

SCRIBES: Ignas Bagdonas <[e-mail]>
          John Scudder <[e-mail]>
          David Ward <[e-mail]>

See proceedings 
(http://www.ietf.org/proceedings/04aug/index.html) 
for presentation slides.

- ----

Document Status Update (5 mins)
	S. Hares, Y. Rekhter

	Presenter: Yakov

Four new work items accepted since last IETF, good consensus.
Other items proposed, not sufficient consensus, not accepted as WG items.
IESG review of BGP base spec package is done, 
comments incorporated (BGP-4, MIB, etc).  Will 
issue further revisions as needed.
Submitted 6 docs to IESG to advance since last IETF (GR, extcomm, etc)
Confeds -- need to be updated with comments from 
last call, need implementation report -- once 
done, to IESG.

No new progress until >= 2 impls:
- - ORF
- - 4-octet ASN
- - AS path ORF
- - MIB
- - AS wide unique identifier

Questions/Comments:

Susan Harris: Just to clarify - which document was reclassified to historic?

Yakov: RFC 1863.

- ----

Dynamic Capability for BGP-4 (10 mins)
	draft-ietf-idr-dynamic-cap-05.txt
		Enke Chen, Srihari R. Sangli

	Presenter: Enke

Additions to support capabilities which affect Update encoding:
- - Ack request
- - Ack
- - Sequence number

What capabilities need ack?
- - 4-byte AS
- - Multipath
- - Address Family (probably)

Ack is optional so need not be used for capabilities that don't require it.

Unfortunately ack is not backward compatible. 
Want to reuse current code point (fine if 
little/no deployment w/ prev spec version) or get 
new code point?

Questions/Comments:

Yakov: Get a new code point, we have hundreds of 'em, no need to economize.

Martin Djernaes: Why not increase capability 
number space to 16 bits, also length to 16 bits?

Chandra Appanna: Agreed, increase sizes.

Chandra: What impact on the state machine?

Enke: Little or none, session is already established.

Chandra: Really?  What about when you send a 
capability which changes something you negotiated 
at OPEN time?

Tony Li: Reserve one value "for future extensions"

Enke: Does anyone really need more length than 255?

Many: Yes.

(Out of time, move to mailing list)

- ----

Advertisement of the Group Best Paths in BGP (15 mins)
	draft-chen-bgp-group-path-update-01.txt
		E. Chen, N. Chen

	Presenter: Enke

Why?  Persistent oscillation issues -- RR or confederation.

Observations:
- - Full mesh is free of oscillations
- - Route selection groups paths based on neighbor AS.

Two approaches:
- - Advertise group-best (i.e. best path from each 
neighbor AS) -- eliminates MED oscillation, still 
vulnerable to topology-based issues, still 
reduces info vs. full mesh.  Paths adv'd == 
number of neighbor ASes.  Topology issues means 
that IGP constraints still apply -- intra-cluster 
links must have smaller metrics than 
inter-cluster links.
- - Advertise group multi-path -- adv all paths 
that survive MED comparison -- effectively makes 
RR advertisements independent of IGP metrics. 
However, virtually as much state as full mesh. 
Suggestions: accept MED, reduces number of routes 
that survive MED step ==> fewer routes advertised.

Encoding:
- - must be changed (pfx, neighbor_as) for 
group-best, (pfx, originator_id) for 
group-multipath
- - no encoding change for reachable routes 
(because neighbor_as, orig_id already in update)
- - need new encoding for w/draw
- - therefore need new capability to indicate 
ability to parse new w/draw and all, also 
advertises which mode to be used (best only, 
group best, multi)

Implementation/deployment:
- - only RR/confed BR need to advertise multiple paths
- - non-RR need only to Rx, not Tx -- Rx is easy

recommendation:
- - Use group-best, incremental deployment. 
group-multi solves more problems but too many 
paths

Questions/Comments:

Pedro Marques: We could use the route server doc 
we just moved to historical for this instead of 
using this encoding.  One reason I would like to 
use a new path attribute is because some non RR 
might like to do this, in which case originator 
ID won't work.  Since there's no backward 
compatibility anyway, why try to reuse existing 
semantics?

Enke: I think Orig_ID is a good fit.

Yakov: Neighbor AS hack won't work with AS set.

Enke: When advertising, you must create AS 
sequence, this is in base specification.

John Scudder: I agree w/ Pedro. If defining a 
capability, then use a new encoding.  Most 
important contribution of this draft is not 
encoding, what is most important is ruleset of 
what to advert and when.

Enke: <missed comment>

Yakov: There is little value to send the same information in the same message
twice.

Pedro: What about non-RR?  You have to have the 
exit point (external box) to be able to do this. 
The originator_id only works for RR server.

John: If define a way to solve multi-path in BGP, 
please solve the general case and not just the 
oscillation case.

Enke: There are a lot of issues if we generalize and I don't know any examples.

(Out of time, move to mailing list)

- ----

Graceful Shutdown of BGP Sessions (15 mins)
        draft-dubois-bgp-planned-maintenance-00.txt
		N. Dubois,  B. Decraene,  B. Fondeviole

Presenter:  Nicolas

Why?
- - Want no packet loss during maintenance 
- - Current is break paths and then inform peers
- - Want make-before-break

NOTE: not always useful for single IBGP session

Observed behavior:
- - in small network test, router shutdown goes from 20s traffic loss to 0s
- - w/ 100k routes 20ms loss vs 4 sec loss
- - timer should be between 30 and 60s draft was too conservative w/ 300s

Questions/Comments:

Tony Li:  What happens if the router undergoing 
maintenance simply withdraws in an orderly fashion

Nicolas:  Yes, that is exactly what the draft proposes

John Scudder:  No changes to BGP?  Can you do this with a route map?

Nicolas:  No changes to BGP state machine.  Can 
be done w/ route-map -- did that for testing. 
But, too hard for ops people.

- ----

Group Cooperative Route Filtering Capability for BGP-4 (10 mins)
	draft-muley-hares-idr-orf-order-00.txt
		Praveen Muley, Susan Hares, Keyur Patel

Presenter:  Sue

Problem:
There is a whole bunch of ORF types, may not have efficient policy together.
Multiple policies but no grouping.

Solution:
Apply in order by putting a Group_id wrapper

Process:
Add group
apply in grouping order

Uses:
VPN policies
Global routing

Questions/Comments:

Enke Chen: Using this approach you can apply one policy before some other.

Sue: This is to group them - ORF type or entry based

Enke: Now tied to type and group as structure vs type and entry

Enke: What does this accomplish? This is a 
location implementation problem.  Currently you 
decide what order to send them in.

Sue: Different ordering than base spec defines.

Enke: Type based or entry based?  If you have 
prefix and AS_PATH list, can you group them 
together?

Sue Hares: Yes.

Enke Chen: What is grouping granularity?

Sue Hares: Any is possible.

Enke: I'm still confused about what it 
accomplishes.  Local implementation will do 
ordering anyway.  I don't know what else it does. 
Is there anything?

Sue: Gives a different ordering.

<more discussion not captured>

Enke: I need to read it and then we can discuss further.

Pedro Marques: What difference does it make which 
I apply first? The only action is to accept 
therefore, what does the ordering matter?  A&&B 
== B&&A.

Sue: Efficiency of statement of process, some 
ORFs have permit/deny which gets you to an AND

Pedro: I don't think so.

Chandra Appanna: Who are you trying to define 
'efficiency' for? Sender or receiver? How do you 
guarantee what is efficient for receiver?

Sue: The one doing the filtering

Chandra: How can the guy advertising it, know 
what's efficient for the guy on the other end?

Sue: Getting back to Pedro's example, with permit and deny ordering matters.

Pedro: No.

Chandra: Why scramble the order?

Enke: If we're talking about efficiency, this is 
an implementation detail -- each implementation 
may want to optimize itself differently.  Not 
sure this needs to be standardized.

Sue: Thanks for your feedback.

Praveen (co-author): order matters per VPN: ext comm/AS w/in VPN.

Pedro: Please send a detailed example to the mailing list.

Praveen: OK

Jeff Haas: The ORFs we have today are very coarse 
(AND) ... instead add sequencing and AND them 
together

John Scudder:  If you are trying to build 
route-map semantics the draft doesn't express it 
clearly. Missed OR'ing, AND'ing instead focused 
on 'efficiency'

Sue: We can update it.

Chandra Appanna: If all policy is ANDed there's no issue.

Pedro: With your encoding, the ordering w/in a 
group is now independent but, between groups you 
are still left w/ the AND'ing problem.

Sue: Sequence DOES matter.

(Out of time, move to mailing list)

- ----

Carrying ATM reachability information in BGP (15 mins)
	draft-ck-bgp-atm-nlri-00.txt
		Chaitanya Kodeboyina, Chris Metz, Peter Busschbach

Presenter: CK

Want to make MPLS network transparent to STM routing/signalling.
- - PNNI tunneling through MPLS doesn't scale
- - Instead do something almost exactly like 2547 but for PNNI
- - Why BGP?  Same reasons as for 2547 -- Solves 
adjacency problem, fits existing carrier 
infrastructure, can use RR, solves interdomain 
problem.
- - "We use BGP to carry everything else so why not 
ATM reachability information?"

Solution:
BGP carries ATM info, passes to ATM route 
selector(ATM topo db) and signaled to/from PNNI
Define new AF/SAF
Use Route Distinguishers between ATM switches in different domains
New extcomm values: ATM admin weight (~= PNNI metric)
Use RT to manage independent ATM networks over single core

Note, also presented to L2VPN WG

Questions/Comments:

Yakov: whole proposal is really L2VPN, only 
peripherally IDR WG.  Should wait to see if L2VPN 
accepts, then if accepted look at it in IDR


MDT SAFI and Connector Attribute (10 mins)
	draft-nalawade-idr-mdt-safi-01.txt
		Gargi Nalawade, Arjun Sreekantiah

Presenter: Gargi

Two proposals -- MDT SAFI, Connector attribute. 
Could be split to two documents as needed.

Problem:
Multicast VPNs is incongruent w/ unicast topology
<see rosen-mcast-vpn-07.txt>

What is a Multicast Domain?
set of PE routers connected by a mcast tunnel
MD per mcast-enabled VPN
a default MDT (multicast distribution tree) connects all PEs

Autodiscovery:

MDT setup by PIM-SM, Bidir PIM or PIM SSM
For SSM each PE needs to know the src addr of 
each of the other PEs in the same MD
Therefore need autodisc of src addr of each of PEs in the same MD

Therefore use new MDT SAFI

RD - assigned to one mcast domain
IPaddr - dest addr (PE)
MDT - addr of given MD
RTs in the ext comm attr and/or the RD used to associate w/ the correct VRF

Why connector attr?
If use NHself then originating PE is overridden
Need original original NH of VPNv4 update to find which tunnel to use

Called Connector because it connects a VPNv4 
prefix's update w/ the MDT safi.  (Suggestions 
for better name solicited.)

Indicates the correlation and depnd between the 2 
safi's and/or carries NGH value by an originating 
BGP speaker

More discussion @ L3VPN WG

Questions/Comments:

Yakov: Part of a larger work that is in L3VPN WG 
(mcast 2547) but, BGP specific part depends on 
whole solution by L3VPN WG. Therefore, don't 
spend time talking about this work but, the L3VPN 
WG.

(Didn't get name, from Cisco): If other WG 
accepts pkg, does that mean IDR is supposed to 
accept it?

Yakov: no, it means if other WG doesn't accept 
it, there's no point in us even spending time

Alex: I agree with Yakov unless you (IDR) see a showstopper in this proposal

Yakov: well it's not broken so don't worry about that

Yakov: please hold other questions until after Rahul's talk

- ----

Preserving BGP Next-Hops (10 mins)
	draft-raggarwa-bgp-nexthop-rewrite-00.txt
		Rahul Aggarwal, Chaitanya Kodeboyina

Presenter: Rahul

Applications:
- - MVPN 2547 inter-AS option B
- - Others possible

BGP NH of unicast routes are rewritten in option B... PIM RPF fails
Address of multicast source must be preserved

Solution:
Preserve original Next Hop
Carried as optional/transitive attribute
Address family inferred from length of attribute

Compared to "Connector":
- - Connector doesn't have well-defined semantics (inferred from AFI/SAFI)
- - This attribute has specific semantics

Questions/Comments (for previous two presentations):

Gargi: disagree w/ statement that connector 
semantics are not well-defined. it is just a 
matter of listing out other uses. Also, not just 
bit-bucket but, types define what is to be carried

Pedro Marques:
MDT safi - on one slide the RD can identify the 
VRF, or the RT can identify the VRF: can have 
more than one RD per VPN. The RT model is always 
used to leak between VPN.  Please stick to using 
just RT.

Gargi: OK.

Yakov: Then RT model will be consistent for unicast

Gargi: We can talk.

John Scudder:
To Rahul ... were you serious about inferring the 
AF/SAF from length of attr? ... there may be 
other AF in the future (ATM, IPV9) in which you 
cannot infer

Rahul: Not solving hypothetical problems.....

Yakov: What happens when something has the wrong 
length. The semantics of the value are directly 
stated as type V6 and length is 128 bits

Eric Rosen: I don't see that semantics is 
undefined here.  The two proposals appear to be 
just about the same. Any claims for lack of 
definition are by further type setting. The BGP 
NH or connector attr must be able to specify. The 
issue is only if you think that you don't need 
MDT attr.

Rahul: difference comes down to non-congruent 
topologies, we should discuss that in L3VPN WG

Eric:  The incongruent topology is to have MDT 
and BGP NH/connector attr. Otherwise, these 
drafts are extremely close.

Someone from Cisco: There are implementations out 
there that don't use BGP NH for VPN addresses. 
Therefore, we have to specify this.

Eric Rosen: if we work out non-congruent stuff in 
L3VPN, shoudn't these converge?

Rahul: quite likely

Yakov: who control the type space for MDT/connector?

Gargi: IANA or IDR

Yakov: IDR doesn't control type space

Everyone: IANA

Someone from Alcatel: Don't need RD ... only need 
group mcast addr as global unicast addr must be 
local IP addr.

Gargi: Think of it like an VPN NRLI (MDT in this 
case like a label) .... kept RD to understand one 
NLRI from the other. Allows addr overlap.

Yakov: is the combination of ip addr (loopback) and group addr globally unique?

Gargi: not necessarily, could be shared by number 
of PEs.  Why RD is there? Look at L3VPN proposal: 
join to the group from another signaling manner

Yakov:  When won't it?

Gargi:  (Something about two PE's having the same loopback address)

Yakov:  In that case unicast wouldn't work.

Gargi:  OK then the PE addrs must be unique.

Yakov:  Well then is the combination unique?

Gargi:  Yes.

Yakov:  Well that was the other guy's point.

Enke Chen: here is another application - 
eliminating route oscillation: make it TLV based 
so can include multiple original nexthops and 
also carry AF/SAF.  I agree with John about 
AF/SAF.

Enke: Also you can carry ASN with nexthop, carry multiple.

Rahul: Very interesting.

CK: draft actually says that orig_NH has same 
type as the normal NH type, it's not implied by 
length at all

Pedro (to Enke): Just because the encoding is 
convenient doesn't mean it's OK -- still have 
same amount of scaling issues from carrying extra 
data.

Enke: I don't care about encoding efficiency, 
it's to let MED be derived from orig NH while 
still allowing RR to rewrite NH.

Rahul: I have another application for it but I haven't thought it out well yet.

Someone from Juniper: Type of original NH is not 
from length but, apply the rule that is used to 
derive from the NRLI that is passed

Eric Rosen: There is no rule that NH passed is 
same AF/SAF as NRLI. Therefore, cannot rely on 
the packet type to derive the NH.

CK: deriving AFI and SAFI of nexthop is hard, but 
that's independent of this draft.

Yakov : we are in the weeds of details that should be in L3VPN WG

Someone from Cisco: Question to chairs, isn't one 
draft a subset of the other?  can the chairs 
suggest a way to resolve this?

Yakov: we aren't going to progress any of them 
until we have guidance from L3VPN.

Rahul: I don't agree the one is a subset of the other.

Sue: We're not doing anything until L3VPN does something.

Bill Fenner:  specific problem or generalizing to 
something bigger? It's a continuum.

Sue: Thank you.

- ----

Wrap up:

Sue: We are requested to review MPLS BGP GR and 
private LAN service doc.  I need reviewers to 
volunteer.  You need to read doc, see if it fits 
with existing IDR practice/implementation.

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

------- End of Forwarded Message


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