[Idr] Prelim minutes for IDR

Folks,

Attached are the minutes. The deadline for any corrections is
March 30, 2008.

Yakov.
- -----

Working group status:  

No new working group items.  Moved one doc from this
working group to softwires wg to reflect comments from last wg.

- -----

Presentations:

draft-dickson-idr-second-best:
Brian Dickson

Originally about second best and backup routes.  

Removed the "backup_only" mechanism from the I-D prior to the meeting in the
protocol extension since it appears to not be strictly necessary.  Will propose
backup_only as a well known community instead.

Provides a solution to path hunting and intended to fix persistent oscillations
.

Requires additional adj-rib-in (memory).
Extra initialization costs.
Update processing will be often reduced.
Reducing path hunting reduces update frequency. and thus total cost.
No impact to FIB size.

Basic idea, pick local second best and send both best and second-best.
When the best route is withdrawn use the second best.  
Calculation of new best deferred until we get a new second best.

The second best route must always be feasible.

Comparison with draft-walton:
- - It [walton] only addresses oscillation.
- - It requires more than 2 instances.
- - It doesn't affect path hunting.

Comparison with draft-filsfils
- - Cute hack for fast convergence for one case.
- - Requires multipath-bgp and carrying peering network in IGP.
- - Only affects local convergence.  Does not affect path hunting
- - Needs comparison to second best in specific scenarios.

Comparison with sigcomm2000 paper example.
- - 4 router full mesh topology.
- - [See slides.]

Summary:
- - Incremental to current bgp standard.
- - Uses extra memory.
- - Reduces CPU usage.
- - Faster local and global convergence.

Questions:
Ilijitsch van Beijnum: Implementing this is a fair amount of work. Instead of
going from 1 to 2 paths, why not go to multiple paths?

Brian Dickson: That seems like a reasonable suggestion. It seems like something
that would have to be negotiated between neighbors.  Inter-vendor,
inter-implementation issue.  Would require additional changes to proposal.

John Scudder:  I was going to make almost to make the same comment.  N is more
attractive than 2.  Disagrees with BD that it is a big design change. Wanted to
point out - ... add path authors here?  Draft-walton requires more than 2
instances - it does permit more routes.  Thinks encoding more attractive.
Innovation in your proposal is what is done with path selection rather than
encoding.  You should look at the draft-walton again

BD: There were choices for encoding for withdrawals the way he did it.

JS: Walton also withdraws the correct path.  You also sorted the paths? Doesn't
seem that crucial in the implementation

BD: The reasoning between the choice of sorting is that when you get to choices
of best path, you know that you've withdrawn the best path.  It's a mark and
sweep update process. Cleaner for bulk withdrawals.

David Ward: Another take on "we need more than two".  I don't think an
attribute is a way to encode this.
 1. Just send me multiple paths - let me choose. 
 2. Don't get caught using an attribute so we have ordering issues.

Yakov Rekhter: I don't think it would work the way you said -

DW: Knowing your choice of second best isn't useful?

YR: Knowing your second best is what we want to do here.

DW: I don't want my second bests getting thrashed in the control place.

Chandra: Just make this N.  Beyond 2, the churn in next bests is bad.

BD - for every extra value, you have to run your path selection.  This is very
inefficient.

Continue discussion on mailing list.

A poll of the room thinks we should:
1. Solve the multiple path issue.
2. Uncertain response as to marking them first, second, third best....
3. Doesn't think we should adopt this particular proposal (yet)

- -----

draft-chakrabarti-idr-rfc4893-mod-00 (4 byte AS)
Samita Chakrabarti 

[Slide commentary]
Unclear about what to do when processing some of the messages.

- - Proposal for handling as_path/as4_path
- - Proposal for additional clarification text
- - Proposal for specifying a open message notification - use an existing code.

What problem does it address:
- - Lack of clarity.
- - Unclear spec = inconsistent implementation.
- - Leads to interoperability issues.
- - Human error is unavoidable - diagnostic info can help.
- - Scenarios for transition.

Change requests:
- - Open message - AS_TRANS values on transmit only.
- - Provide text for handling the receive case:
  + When AS4 capability is present, new BGP uses the cap and ignores open
    message AS.
  + If new BGP receives OPEN without AS4 capability it must use open message
    AS. if AS number is as_trans it sends notification.

Old BGP implementation ignores AS4 capability.

Section 4.2.1:
What happens when old BGP peers with multiple AS with AS-TRANS?

Proposed text:
Careful considerations are required such that it does not affect the routing
path of the traffic due to some local policy on AS number at the old BGP
speaker.  during transition to new BGP speaker from an old bgp speaker, the
above scenario should be avoided.

Comment from Enke Chen:
RFC 2270 should be provided as guidance.

Proposal for handling AS4 attributes:
- - Always have AS_PATH as AS4_PATH from BGP [don't recompute AS_PATH]
- - No overloading of AS_PATH as in RFC 4893
- - No conversion of AS4_PATH and AS4_AGGREGATOR 
- - Path length computed from AS_PATH

Comments from Enke Chen and Geoff Huston
- - Too late since there are implementations.
- - Similar proposal was discussed and discarded.

Proposal for notification:
- - Notification code 2 and subcode 2

Transition cases:
- - Point out cases where special care is needed.
- - Possible ambiguity in originating AS.
- - AS override at PE.
- - PE routers must be converted to NBGP before CEs.

Conclusion:
- - Request wg to adopt proposals for clarifications and changes

Questions:
None.

How many read draft? [Some]
No one thinks we should do an update.

Will take adoption question to mailing list.

- -----

draft-van-beijnum-idr-iac-00
Iljitsch van Beijnum

inter-as-cost

Problem: 
- - No good inter-AS metric in bgp.
- - No easy inbound traffic engineering.
- - MED is one hop.
- - Origin - not updated in transit.
- - Only have the AS path length.

AS path length:
- - Increases with every hop.
- - AS hierarchy is Too Flat.

IAC
- - Metric that is increased at every hop.
- - Needs to be compatible with existing implementation.

Solution:
- - iaclocal: Uses path length plus IAC attribute.
- - More granular than AS path length.

Compatibility 
- - Don't want routers to suddenly change path selection after update.
- - Solution: multiplier value.
- - Deploy gradually in existing networks.

Deployment
- - Optional transitive attribute.
- - Just won't increment/decrement if not recognized.

Questions?

Yakov Rekhter: draft-ietf-idr-bgp-dpa-05

It was a WG doc. just died out. (simple)
draft-ietf-idr-bgp-metrics-00. WG and died. ("baroque" complexity)

Take the past into consideration.

Danny McPherson: Affects scalability of bgp due to yet another item in BGP.

YR: One of these was un-deployable.  It had  persistent forwarding loops due to
not being incrementally deployable.

John Scudder: Incremental deployment observation that with these sorts of
things - sites that are doing as path padding would still do so.  What's the
plausible path where people are using IAC instead?

IvB: Depends on what these people want to accomplish.

Rudiger Volk:  Operators may not want to respect this value.  That's not to say
that this isn't deployable, but it's not straight forward.

Brian Dickson: In the preamble - the origin attribute isn't usable?  I've used
it?

IvB: Some vendor decided uses this in path selection.  You wouldn't normally
use this as an inter-as metric.

BD: The sender is setting this value differentially.  It's respected everywhere
and it affects path selection.

IvB: It has no fine grained influence.  It's a very blunt tool.

BD: More subtle than LOCAL_PREF or AS path padding.

IvB:  You don't update every hop.

BD: That's a good thing.  If this thing is an optional attribute - and can be
configured to be ignored - this may achieve desired results.

IvB: If someone in the middle has a different opinion they'll either not
re-advertise or they'll change the IAC value themselves.

Sue Hares: You should examine the discussion on the DPA attribute.

BD: Don't know if we're seeing good analysis as to what different types of
people are trying to accomplish with AS path padding.

YR: What should the working group to do with draft?

IvB: Talk about whether this is interesting or not?

YR: Support for general idea?  [Some]
Support for this specific idea of a metric?  [Some]

Get more discussion going in the mailing list for more feedback.

- -----

draft-ietf-idr-bgp4-mib2-06.txt
Jeffrey Haas

BGP MIBv2 update

- - Brief history of what went on with BGP MIBs during standardization process.
- - New v2MIB stalled while completing v1MIB during standardization.
- - Author unavailable for IETF work for a while.  MIB at that time wasn't
  in a state suitable for wide implementation.
- - Last year working group decided to drop this working group item if there
  was no progress.
- - As of today, there's a Juniper implementation of -04 of this draft.
- - Author says current draft incorporates all previous comments, is 
  integrated into base BGP MIB and ready for widespread implementation.
  Asks that the working group item be left up for another two sessions.

Discussion:

Yakov Rekhter: We had this on the working group chair for more than 7 years.
Last year we agreed that it would only last one more year.  Shall we continue?

David Ward (Area Director): I have no objection if there is active work on the
MIB.  Jeff has done the active work on the MIB so we should do a last call.

Jeffrey Haas: I have cleaned up the MIB and it is ready to implement.

YR: We need an implementation to progress the draft.  Juniper has an enterprise
MIB that derives from the MIB.

DW: We should have a last call on the document and progress it.

JH: We should get two MIB doctors to look at the MIB and review it. 

DW: We can do "last call" and then have the MIB Doctors look at it.

JH: The MIB doctors churned a bit on the original draft.

Sue Hares: The MIB doctors also churned a bit on RFC 4273.

DW: Jeff Haas should send a note requesting a MIB doctor review.

YR: After the MIB doctor review, this document will go to final review.

- -----

draft-manral-idr-mpls-explicit-null-00
Samita Chakrabarti 

6PE-ALT

[Slides]

- - No change to protocol is required.
- - Adds a new afi/safi combination to bgp
- - Each route is at ached to a label and exchanged
- - Use of this label: allows PHP, IPv4 explicit NULL label is used in last hop
- - One IPv6 lookup can be prevented.

RFC4798 gives reason to have 2 labels.

6PE-ALT 
- - Uses IPv6 explicit null as VPN inner label.
- - Changes required:
  + Allows load balancing by using v4 null and v6 null
  + Ask IANA for another set o explicit null labels.

Advantages:
- - No additional signaling required.
- - Memory savings of 8 bytes for every route (IPv6 null).
- - Lookup faster.
- - Any router having BGP IPv6 support can become 6PE router.
- - Same functionality as 6PE in data plane.
- - No different inter-provider changes affecting eBGP like 6PE.

Feedback from v6ops and idr
- - Lighter weight approach and can be used along with 6PE.

Questions?

Eric Rosen: Chances of getting new reserved label from IANA is very small
(approaching zero).  6PE is already deployed.  There are no advantage to moving
to this?

Yakov Rekhter: MPLS WG MUST buy into explicit null labels.  Bounce this off
mpls first.

?? - said on list - not a good idea.  Solves a solved problem.  6PE put in two
options for a good reason.  The extra signaling isn't that big of a deal.  The
AFI/SAFI was previously existing.  Not advertising the extra label isn't that
big of a deal.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr