Subject: [Idr] IETF67 - IDR WG minutes

From: Yakov Rekhter <[email-masked]>
Date: Mon, 20 Nov 2006 08:55:06 -0800

Folks,

Attached are the minutes of the IDR WG. Please send corrections, if any.

Yakov.
-------------------------------------------------------------------------
IDR 2006/11/08 meeting:

Taken by John Scudder and Dave Ward.

1. Document status (Yakov):

Lots of progress:
- GR to RFC editor
- Multiprotocol also on RFC editor queue.  Needs a little editorial change
   but nothing substantive.
- 6PE -- through IESG LC, IETF LC, approve announcement forthcoming.
- 4byte ASNs -- IESG comments to be incorporated.
- AS confeds -- revised ID needed, authors to do Real Soon Now.
- AS_PATHLIMIT -- early allocation procedures have worked very smoothly.

No progress on:
- ORF
- AS wide unique ID
- Avoid Best Path transition
- Prefix based ORF

2. AFI and SAFI (Yakov, Bill):

Yakov:
No IANA procedures for allocating AFIs!

Bill Fenner:
- IANA needs guidance for what their policy should be for AFI, asked IESG.
- Who are stakeholders?  Routing for sure, but must be others -- why
   is AFI 16 == DNS registered?  (Bill's guess: MIB.)
- If routing is only stakeholder, routing should propose policy.
- Other considerations -- scarce? (No, 16 bits.) potential harm from
   allocation?
- Possible policies -- specification req'd + early allocation, or FCFS

Discussion:
Acee Lindem: Should be some review of AFI, otherwise I could get an
   Acee Lindem AFI
Bill Fenner: Is that harmful though?
Yakov: But you can already get a SAFI today...
Chandra Appanna: I don't mind FCFS, but how to handle indiscriminate
   allocations?
Bill: FCFS doesn't pretend to, but could break into ranges like other
   registries, allocate half for FCFS, reserve half for later.
Kireeti: Do we have to choose one? Can't we have spaces?
Bill: We can have spaces.
Kireeti: OK let's, half for FCFS, half for Spec Req'd.
Bill: Why?
Kireeti: To prevent DoS allocations.
Kireeti: Also Spec Req'd code points are shinier and more important
   looking.
Danny McPherson: Talked about this in Paris too, and IESG was asked
   to make a general guideline about this.  In PWE3 we split into three,
   expert review req'd, FCFS, etc.
John: I don't really see a point of having two different allocation
   policies.  If you have FCFS anyway, may as well have only that.
Danny: Worry about depletion with FCFS. Challenge was not necessarily 
   an attack but, greedy alloc and potential for depletion. My experience 
   was that FCFS was seen to have the potential for abuse.

Bill: If we don't have FCFS, people will just pull numbers from
   clear blue sky.
Yakov: I suggest 1/3 or 1/2 of space reserved, then remainder is
   some mix of FCFS and maybe Spec Req'd.
Bill: OK, let's follow up on list, I'll send a strawman.

3. draft-lefaucheur-idr-v4nlri-v6nh-00.txt (Eric Rosen):

For years now we've been playing with different uses for NH of 
different AF from NLRI.  Different deployed examples --
- VPN-IPv4 with IPv4 NH (but with bizarre encoding)
- IPv6 AF with IPv4 NH using "IPv4 mapped IPv6 addres"
- And so on, e.g. l2vpn, rt-constraint, using length field to
   distinguish between v4 and v6.
- Leaves us with one odd man out: IPv4 NLRI, no way to have v6 NH,
   no obvious encoding trick to stuff in v6 NH.
- Softwire WG has requirement to carry v4 routing over v6-only single
   stack core -- analogous to "BGP-free core", v4 routing at border
   routers but not in core.
- Implies v4 NLRI with v6 addresses as NH (for tunnels across core).
- Straightforward solution is to simply declare that v4 AF can have
   v6 NH.
- Many possible encodings.  Current proposal, use length field to
   distinguish.
- Since this isn't interoperable with implemeersion: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Folks,

Attached are the minutes of the IDR WG. Please send corrections, if any.

Yakov.
-------------------------------------------------------------------------
IDR 2006/11/08 meeting:

Taken by John Scudder and Dave Ward.

1. Document status (Yakov):

Lots of progress:
- GR to RFC editor
- Multiprotocol also on RFC editor queue.  Needs a little editorial change
   but nothing substantive.
- 6PE -- through IESG LC, IETF LC, approve announcement forthcoming.
- 4byte ASNs -- IESG comments to be incorporated.
- AS confeds -- revised ID needed, authors to do Real Soon Now.
- AS_PATHLIMIT -- early allocation procedures have worked very smoothly.

No progress on:
- ORF
- AS wide unique ID
- Avoid Best Path transition
- Prefix based ORF

2. AFI and SAFI (Yakov, Bill):

Yakov:
No IANA procedures for allocating AFIs!

Bill Fenner:
- IANA needs guidance for what their policy should be for AFI, asked IESG.
- Who are stakeholders?  Routing for sure, but must be others -- why
   is AFI 16 == DNS registered?  (Bill's guess: MIB.)
- If routing is only stakeholder, routing should propose policy.
- Other considerations -- scarce? (No, 16 bits.) potential harm from
   allocation?
- Possible policies -- specification req'd + early allocation, or FCFS

Discussion:
Acee Lindem: Should be some review of AFI, otherwise I could get an
   Acee Lindem AFI
Bill Fenner: Is that harmful though?
Yakov: But you can already get a SAFI today...
Chandra Appanna: I don't mind FCFS, but how to handle indiscriminate
   allocations?
Bill: FCFS doesn't pretend to, but could break into ranges like other
   registries, allocate half for FCFS, reserve half for later.
Kireeti: Do we have to choose one? Can't we have spaces?
Bill: We can have spaces.
Kireeti: OK let's, half for FCFS, half for Spec Req'd.
Bill: Why?
Kireeti: To prevent DoS allocations.
Kireeti: Also Spec Req'd code points are shinier and more important
   looking.
Danny McPherson: Talked about this in Paris too, and IESG was asked
   to make a general guideline about this.  In PWE3 we split into three,
   expert review req'd, FCFS, etc.
John: I don't really see a point of having two different allocation
   policies.  If you have FCFS anyway, may as well have only that.
Danny: Worry about depletion with FCFS. Challenge was not necessarily 
   an attack but, greedy alloc and potential for depletion. My experience 
   was that FCFS was seen to have the potential for abuse.

Bill: If we don't have FCFS, people will just pull numbers from
   clear blue sky.
Yakov: I suggest 1/3 or 1/2 of space reserved, then remainder is
   some mix of FCFS and maybe Spec Req'd.
Bill: OK, let's follow up on list, I'll send a strawman.

3. draft-lefaucheur-idr-v4nlri-v6nh-00.txt (Eric Rosen):

For years now we've been playing with different uses for NH of 
different AF from NLRI.  Different deployed examples --
- VPN-IPv4 with IPv4 NH (but with bizarre encoding)
- IPv6 AF with IPv4 NH using "IPv4 mapped IPv6 addres"
- And so on, e.g. l2vpn, rt-constraint, using length field to
   distinguish between v4 and v6.
- Leaves us with one odd man out: IPv4 NLRI, no way to have v6 NH,
   no obvious encoding trick to stuff in v6 NH.
- Softwire WG has requirement to carry v4 routing over v6-only single
   stack core -- analogous to "BGP-free core", v4 routing at border
   routers but not in core.
- Implies v4 NLRI with v6 addresses as NH (for tunnels across core).
- Straightforward solution is to simply declare that v4 AF can have
   v6 NH.
- Many possible encodings.  Current proposal, use length field to
   distinguish.
- Since this isn't interoperable with implementations that don't
   understand v6 NH, use BGP capability to make sure you don't send
   such next hops to peers that don't understand them.
- Other options considered:
   - TLV: better solution in general.  Slightly more complex encoding.
     Architecturally "purer".  But, we already have hacks for every
     other option in the matrix of NLRI/NH combinations, so since we
     just have this one v4/v6 case, might as well do the expedient
     thing.
   - New AFI/SAFI for 4/6 case:  Operationally more complicated,
     creates implementation hassles.
- Is it even needed?  For example, you could have v4-free core by having
   configured overlay tunnel topology, then run v4 routing protocols
   over it.
   - This is a softwire problem, not an IDR problem, softwires is
     proposing requirements
   - In general, overlay model seems more painful!

Discussion:
Yakov: I don't think it's purely a softwire problem.  2547 over IPv6
   also needs to be solved -- and your proposal solves it!
Eric: Yep, and for the same reason 6PE is useful for softwires.  Great!
Yakov: What do you want to do with it?
Eric: Make it an RFC.
Yakov: Oh come on.
Eric: Make it a WG doc.  Shall we?
Yakov: How many have read it?  (Show of hands, some.)  Of those who've
   read it, how many would object to making it a WG doc?  (~1 hand)
Yakov:  Eric-Francois to make request to list after posting revision 
   of the draft

4. draft-pmohapat-idr-info-safi-00.txt (Eric Rosen):
- Softwire problem requires v4 packets to be tunneled through v6 core
   and vice-versa.
- Of course they should just use MPLS but WG wants to do it the
   hard way.
- So, need to be able to pick an encapsulation.  Not only that, but
   to make it more complex, desire to have various policies for what
   tunnels are used for what destinations, etc.
- At least want to be able to categorize routers into classes, to which
   tunneling policies can be applied.
- Some IP encaps (GRE, L2TPv3) lack appropriate native signalling
   protocols for multipoint-to-point tunnels.
- Hence proposal: New SAFI, "Info-SAFI" (everyone agrees choice of name
   is poor...)
- Carries:
   - Address of BGP speaker, embedded in NLRI
   - Characteristics of speaker, as communities
   - For signalled tunnels, new attribute with signalling info
   - Allows multiple info-SAFIs per speaker
- Obvious alternative:  Just use a /32 identifying speaker, attach
   attributes to that.
- Why not?
   - Route distribution constraints might be different
   - Don't want trouble with summarization policies
- Isn't:
   - Tunnel-SAFI -- no hidden infrastructure, not naming tunnels, not
     replacing NH with tunnels
   - Not "all purpose use BGP to send any random info about anything"
     scheme

Discussion:
Chandra: Range of info-SAFIs, or just one?
Eric: Just one. In the info-safi there are multiple NRLI's per speaker - good
   clarification
Chandra: Why even bother spec'ing, you could have multiple SAFIs per
   speaker, what's special about info-SAFI?
Eric: Huh?
Eric: Oh, what I meant is, there are multiple *NLRI* per speaker
   within the info-SAFI.
Yakov: GRE doesn't have signaling protocol and only need one if you require
   key. We know GRE works today w/o any of this if key is not used. If you want
   to mark certain routes to go over GRE tunnel and you want to use a key; what
   does this proposal buy you vs just carry GRE key with the routes.
Eric: I assumed while working this out that we wanted to do it
   efficiently -- just advertise the BGP speaker's properties ONCE,
   instead of re-advertising them again and again (once per update).
   Not clear whether this is the right tradeoff or not -- a little
   extra complexity for a little extra efficiency.  Consider though,
   that if you change the key or something, you would have to readvertise
   your whole RIB.
Yakov: Good point about L2TPv3.  Why not just think of your proposal
   as just an L2TPv3 signalling protocol for mp2p tunnels?  I think that 
   would be fine.
   If we need it for GRE, get another SAFI. It fits into model we have 
   today for MPLS where wentations that don't
   understand v6 NH, use BGP capability to make sure you don't send
   such next hops to peers that don't understand them.
- Other options considered:
   - TLV: better solution in general.  Slightly more complex encoding.
     Architecturally "purer".  But, we already have hacks for every
     other option in the matrix of NLRI/NH combinations, so since we
     just have this one v4/v6 case, might as well do the expedient
     thing.
   - New AFI/SAFI for 4/6 case:  Operationally more complicated,
     creates implementation hassles.
- Is it even needed?  For example, you could have v4-free core by having
   configured overlay tunnel topology, then run v4 routing protocols
   over it.
   - This is a softwire problem, not an IDR problem, softwires is
     proposing requirements
   - In general, overlay model seems more painful!

Discussion:
Yakov: I don't think it's purely a softwire problem.  2547 over IPv6
   also needs to be solved -- and your proposal solves it!
Eric: Yep, and for the same reason 6PE is useful for softwires.  Great!
Yakov: What do you want to do with it?
Eric: Make it an RFC.
Yakov: Oh come on.
Eric: Make it a WG doc.  Shall we?
Yakov: How many have read it?  (Show of hands, some.)  Of those who've
   read it, how many would object to making it a WG doc?  (~1 hand)
Yakov:  Eric-Francois to make request to list after posting revision 
   of the draft

4. draft-pmohapat-idr-info-safi-00.txt (Eric Rosen):
- Softwire problem requires v4 packets to be tunneled through v6 core
   and vice-versa.
- Of course they should just use MPLS but WG wants to do it the
   hard way.
- So, need to be able to pick an encapsulation.  Not only that, but
   to make it more complex, desire to have various policies for what
   tunnels are used for what destinations, etc.
- At least want to be able to categorize routers into classes, to which
   tunneling policies can be applied.
- Some IP encaps (GRE, L2TPv3) lack appropriate native signalling
   protocols for multipoint-to-point tunnels.
- Hence proposal: New SAFI, "Info-SAFI" (everyone agrees choice of name
   is poor...)
- Carries:
   - Address of BGP speaker, embedded in NLRI
   - Characteristics of speaker, as communities
   - For signalled tunnels, new attribute with signalling info
   - Allows multiple info-SAFIs per speaker
- Obvious alternative:  Just use a /32 identifying speaker, attach
   attributes to that.
- Why not?
   - Route distribution constraints might be different
   - Don't want trouble with summarization policies
- Isn't:
   - Tunnel-SAFI -- no hidden infrastructure, not naming tunnels, not
     replacing NH with tunnels
   - Not "all purpose use BGP to send any random info about anything"
     scheme

Discussion:
Chandra: Range of info-SAFIs, or just one?
Eric: Just one. In the info-safi there are multiple NRLI's per speaker - good
   clarification
Chandra: Why even bother spec'ing, you could have multiple SAFIs per
   speaker, what's special about info-SAFI?
Eric: Huh?
Eric: Oh, what I meant is, there are multiple *NLRI* per speaker
   within the info-SAFI.
Yakov: GRE doesn't have signaling protocol and only need one if you require
   key. We know GRE works today w/o any of this if key is not used. If you want
   to mark certain routes to go over GRE tunnel and you want to use a key; what
   does this proposal buy you vs just carry GRE key with the routes.
Eric: I assumed while working this out that we wanted to do it
   efficiently -- just advertise the BGP speaker's properties ONCE,
   instead of re-advertising them again and again (once per update).
   Not clear whether this is the right tradeoff or not -- a little
   extra complexity for a little extra efficiency.  Consider though,
   that if you change the key or something, you would have to readvertise
   your whole RIB.
Yakov: Good point about L2TPv3.  Why not just think of your proposal
   as just an L2TPv3 signalling protocol for mp2p tunnels?  I think that 
   would be fine.
   If we need it for GRE, get another SAFI. It fits into model we have 
   today for MPLS where we have a distinct AFI/SAFI for setting up mp2p LSPs 
   with BGP.
Chandra: I understand that to carry the tunneling info we need a SAFI,
   but as for attributes of a speaker you exchange them in capabilities.
Eric: I'll answer Yakov's question first.  It's not clear to me
   if it's better or worse to have one SAFI for all tunnel signalling,
   or one for each technology.  I'm not sure how to compare them.
Yakov: If you do this specific per tunnel encap, you only carry that info.
   For another you use another. Avoids attr clash and errors. Diff tunneling
   protocols have different things.
Yakov: Regarding Chandra's question, I think "characteristic of BGP
   speaker" are things we already advertise, and we don't need a
   info-SAFI!
Eric: Problem is desire to divide routers into classes based on, e.g.,
   what kind of tunneling technologies they support.
Yakov: That doesn't sound like general characteristics of BGP speakers.
   That sounds like just characteristics wrt tunnels.
Eric: How do you think you're actually going to restrict it?
   Communities are general things.  Once you have an update message,
   you can put communities in it.
Yakov: But the point is, those communities would be embedded in
   BGP update that carries L2TPv3 tunnel info!
Eric: So how do you think you'd signal stuff like tunneling technology
   preference?
Yakov: Color each route with a community.
Eric: Seems pretty inefficient when you change an attribute.
Eric: So suppose we change the name to tunnel signalling SAFI and leave
   it the same otherwise?
Yakov: That's what it is!
Chandra: To carry tunnel info you need a safi but, you say "attributes of a
speaker" are those that send in dyn cap at OPEN. So, I am confused
Rajiv Asari: I agree with Yakov.  Suppose next I want to stick
   for example compression info out?
Yakov: Right, what happens if other end doesn't understand?
John Scudder: You can do this with an optional attribute.
Yakov: What do you want to do with the doc?
Eric: Not ready for WG doc.
Chandra: Probably not ready for WG doc.
Yakov: Please discuss on mailing list.

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

 have a distinct AFI/SAFI for setting up mp2p LSPs 
   with BGP.
Chandra: I understand that to carry the tunneling info we need a SAFI,
   but as for attributes of a speaker you exchange them in capabilities.
Eric: I'll answer Yakov's question first.  It's not clear to me
   if it's better or worse to have one SAFI for all tunnel signalling,
   or one for each technology.  I'm not sure how to compare them.
Yakov: If you do this specific per tunnel encap, you only carry that info.
   For another you use another. Avoids attr clash and errors. Diff tunneling
   protocols have different things.
Yakov: Regarding Chandra's question, I think "characteristic of BGP
   speaker" are things we already advertise, and we don't need a
   info-SAFI!
Eric: Problem is desire to divide routers into classes based on, e.g.,
   what kind of tunneling technologies they support.
Yakov: That doesn't sound like general characteristics of BGP speakers.
   That sounds like just characteristics wrt tunnels.
Eric: How do you think you're actually going to restrict it?
   Communities are general things.  Once you have an update message,
   you can put communities in it.
Yakov: But the point is, those communities would be embedded in
   BGP update that carries L2TPv3 tunnel info!
Eric: So how do you think you'd signal stuff like tunneling technology
   preference?
Yakov: Color each route with a community.
Eric: Seems pretty inefficient when you change an attribute.
Eric: So suppose we change the name to tunnel signalling SAFI and leave
   it the same otherwise?
Yakov: That's what it is!
Chandra: To carry tunnel info you need a safi but, you say "attributes of a
speaker" are those that send in dyn cap at OPEN. So, I am confused
Rajiv Asari: I agree with Yakov.  Suppose next I want to stick
   for example compression info out?
Yakov: Right, what happens if other end doesn't understand?
John Scudder: You can do this with an optional attribute.
Yakov: What do you want to do with the doc?
Eric: Not ready for WG doc.
Chandra: Probably not ready for WG doc.
Yakov: Please discuss on mailing list.

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