Subject: Re: [Idr] Revised proposed IDR charter

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Feb 2010 10:05:31 +0200

The new charter text looks good to me.

Jari

---

From: Ross Callon <[email-masked]>
Date: Tue, 2 Feb 2010 13:31:44 -0500

Danny;

The text "...review extensions made to BGP in other working groups at least at WG document adoption and during working group last calls" implies that the call (in a different working group) for adoption of a document that has significant implications on BGP would be copied to the IDR working group. Also, WG last calls would also be copied to the IDR working group. This should make life easier when documents that have implications on BGP get to the IESG for review, and the routing ADs (or others) ask the obvious question: "What does the IDR working group think of this?". 

In terms of groups that are working on experimental specifications, your use of the word "theoretically" may be particularly appropriate. There is quite a range of intentions that over the years have been attached to documents whose status is listed as "experimental". If there is a proposal which has some likelihood of being deployed in the Internet and thereby having significant impact on how BGP operates in the Internet, then however it is labeled it is appropriate for the proposal to be looked at by IDR. 

"Oversight" and "review" doesn't imply a tyrannical ability to stop all work. It does mean that they get to comment. As is usual in the IETF, we can expect that most proposals will go forward with little or no controversy (you co-chair a WG which may be an exception), and that when controversy does show up the WG chairs, and if necessary the ADs, will need to get together and look for rough consensus. 

In your case as co-chair of L3VPN, this means that for those L3VPN protocol specifications that have significant implications on IDR, then in the future you should copy the requests for WG adoption and the WG last calls to the IDR list. Given the considerable overlap between L3VPN and IDR participants, this is not all that likely to change the results, but is nonetheless a sensible step. 

Your other more detailed comments at the end of your email strike me as good points to bring up during IDR discussion of specific proposals, but I don't see what we would add differently into the proposed charter. 

thanks, Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Danny McPherson
Sent: 01 February 2010 02:59
To: John Scudder
Cc: idr List; [email-masked]; [email-masked]
Subject: Re: [Idr] Revised proposed IDR charter

On Jan 28, 2010, at 1:53 AM, John G. Scudder wrote:

> The IDR working group also has an oversight role for all extensions made
> to BGP for other uses that may be developed in other working groups. IDR 
> will review extensions made to BGP in other working groups at least at 
> WG document adoption and during working group last calls. The IDR working 
> group will also provide advice and guidance on BGP to other working groups
> as requested. In some cases the IDR WG chairs may work with the chairs of
> other working groups and the IESG to move BGP work into the IDR WG instead 
> of the another WG.

How is it the IDR WG intends to be involved in WG document 
adoption in other WGs (e.g., PWE3, L2VPN, L3VPN, etc..) from 
a process perspective?  I can understand how cross-WG LCs 
function, but not the adoption process.  

Also, does this include WGs that are theoretically working only 
in experimental mode?  For example, if LISP or some other
IRTF-RRG-work-gone-IETF-WG were to find it's way into modifying
(or otherwise employing) BGP, then IDR gets veto power on document 
adoption?  This seems a bit tyrannical to me.

> Work Items:
> 
> The IDR working group will work on correctness, robustness and
> scalability of the BGP protocol, as well as clarity and accuracy of the
> BGP document set.  The group will also work on extensions beyond these
> areas when specifically added to the charter.  The current additional
> work items are:
> 
> - Relax the definition of BGP identifiers to only require AS-wide
>  uniqueness. This change must be made in a backward compatible way.
> 
> - Specify a means to non-disruptively introduce new BGP Capabilities 
>  to an existing BGP session.
> 
> - Upgrade of the base BGP specification to Full Standard
> 
> - Define AS_PATH based Outbound Route Filtering.
> 
> - MIB v2 for BGP-4
> 
> - Augment the BGP multiprotocol extensions to support the use of
>  multiple concurrent sessions between a given pair of BGP speakers.
>  Each session is used to transport routes related by some session-
>  based attribute such as AFI/SAFI. This will provide an alternative
>  to the MP-BGP approach of multiplexing all routes onto a single
>  connection.
> 
> - Support for four-octet AS Numbers in BGP.
> 
> - Revisions to the BGP 'Minimum Route Advertisement Interval'
>  deprecating the previously recommended values and allowing for
>  withdrawals to be exempted from the MRAI.

> - Advertisement of multiple paths for the same address prefix without
>  the new paths implicitly replacing any previous ones. Each path is
>  identified by a path identifier in addition to the address prefix.
> 
> - Revised error handling rules for optional transitive BGP attributes
>  so that a BGP speaker is no longer required to reset the session
>  over which a malformed attribute is received. Provide guidelines
>  for authors of documents that define new optional transitive
>  attributes, and re-assess procedures for existing optional
>  transitive attributes
> 
> - Specify Link Bandwidth Extended Community for use in unequal cost
>  load balancing.
> 
> - The definition of an "Accumulated IGP Metric" attribute for BGP
>  to report the sum of the metric of each link along the path.
>  This attribute is for use in a restricted environment where:
>  - all ASes are subject to the administrative control
>  - some form of tunneling is used to deliver a packet to its next
>    BGP hop
>  - where the path for a route leads outside the AS to which the
>    BGP speaker adding the attribute belongs.

What's a restrictive environment again and how do we *guarantee* 
this in BGP?

> - Advertisement of the best external route in BGP to assist with
>  resolution of the next hop in the chosen data plane.

Any chance we could add something here about minimizing BGP state, 
everyone one of the options above aims to expand the number of 
unique routes, whereas RRG and all the rest of the world are working
on scalability - all of this stuff seems to only lead to additional 
state and churn to me.

-danny

> Goals and Milestones:
> 
> Done  Submit to BGP Capability Advertisement to the IESG
> Done  Submit BGP Security Vulnerabilities Analysis to IESG as an
>      Informational
> Done  Submit BGP4 MIB to IESG as a Proposed Standard
> Done  Submit BGP4 document to IESG as a Draft Standard
> Done  Submit Extended Communities draft to IESG as a Proposed Standard
> Done  Submit BGP Graceful Restart to IESG as a Proposed Standard
> Done  Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a
>      Draft Standard
> Done  Submit Subcodes for BGP Cease Notification Message to IESG as a
>      Proposed Standard
> Done  Submit 4-byte AS ID to IESG as a Proposed Standard
> Done  Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as
>      a Proposed Standard
> Done  Prefix and ASpath ORF draft to IESG as a Proposed Standard
> Aug 2010 Submit AS-wide Unique BGP Identifier for BGP-4 as a Proposed
>         Standard
> Aug 2010 Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard
> Aug 2010 ASpath ORF draft to IESG as a Proposed Standard
> Aug 2010 Submit MIB v2 for BGP-4 as a Proposed Standard
> Nov 2010 BGP Support for Four-octet AS Number Space (revised version)
> Nov 2010 Revisions to the BGP 'Minimum Route Advertisement Interval'
> Nov 2010 Advertisement of Multiple Paths in BGP
> Nov 2010 BGP Link Bandwidth Extended Community
> Nov 2010 Advertisement of the best external route in BGP
> Dec 2010 Submit Multisession BGP as a Proposed Standard
> Dec 2010 Error Handling for Optional Transitive BGP Attributes
> Dec 2010 Revise WG charter
> Mar 2011 The Accumulated IGP Metric Attribute for BGP
> Mar 2011 Base BGP specification (RFC 4271) as Full Standard
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

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

---

From: John Leslie <[email-masked]>
Date: Tue, 2 Feb 2010 21:07:28 -0500

Ross Callon <[email-masked]> wrote:
> To: Danny McPherson <[email-masked]>
]] On Jan 28, 2010, at 1:53 AM, John G. Scudder wrote:
]] 
]]] The IDR working group also has an oversight role for all extensions
]]] made to BGP for other uses that may be developed in other working
]]] groups. IDR will review extensions made to BGP in other working
]]] groups at least at WG document adoption and during working group
]]] last calls. The IDR working group will also provide advice and
]]] guidance on BGP to other working groups as requested. In some cases
]]] the IDR WG chairs may work with the chairs of other working groups
]]] and the IESG to move BGP work into the IDR WG instead of the another
]]] WG.
]] 
]] How is it the IDR WG intends to be involved in WG document adoption
]] in other WGs (e.g., PWE3, L2VPN, L3VPN, etc..) from a process
]] perspective? I can understand how cross-WG LCs function, but not the
]] adoption process.
> 
> The text "...review extensions made to BGP in other working groups at
> least at WG document adoption and during working group last calls"
> implies that the call (in a different working group) for adoption of
> a document that has significant implications on BGP would be copied to
> the IDR working group. Also, WG last calls would also be copied to the
> IDR working group. This should make life easier when documents that
> have implications on BGP get to the IESG for review, and the routing
> ADs (or others) ask the obvious question: "What does the IDR working
> group think of this?". 

   While this may answer Danny to the extent of what is intended, IMHO
it doesn't answer in terms of how this is formalized. WGCs are not
expected to read every charter of every other WG to find things like
this. The best of intents can get lost in just a few years...

   More fundamentally, this description of the intended effect is not
consistent with the initial statement:
" 
" The IDR working group also has an oversight role for all extensions     
" made to BGP for other uses that may be developed in other working 
" groups.

   What Ross describes is more a liaison role than an "oversight" role.

   And I really don't know of a practical way to implement an "oversight"
role _by_ a WG (as opposed to an individual).

   Nor do I believe this is the appropriate role.

   BGP, alas, _is_ a bit fragile. I get very nervous when I hear folks
wanting to piggyback something on _the_same_ BGP session that we use
to propagate routes.

   But someone wanting to use the BGP _protocol_ to establish entirely
separate sessions doesn't worry me. If we've done our job right in
describing the protocol, there should be nothing to worry about.

   I'd be much more comfortable if the charter talked of a blocking
role for a few dangerous things like piggybacking sessions, rather than
an "oversight" role so murkily defined. But in practice, I think the
blocking role needs to be written into the BGP specs, not put in a
charter which may not get read at an appropriate time.

> "Oversight" and "review" doesn't imply a tyrannical ability to stop
> all work. It does mean that they get to comment. As is usual in the
> IETF, we can expect that most proposals will go forward with little
> or no controversy (you co-chair a WG which may be an exception), and
> that when controversy does show up the WG chairs, and if necessary
> the ADs, will need to get together and look for rough consensus. 

   That indeed is the meaning of "review" (leaving aside the issue of
what magic makes it happen at all).

   That is not the usual meaning of "oversight." "Oversight" usually
means a duty to set conditions which must be fulfilled. (Whether such
a duty/power is "tyrannical" is a semantic question I choose not to
pursue.)

   I personally doubt this proposed charter language will accomplish
a useful goal. I instead believe any revision to the BGP specs should
lay out what the problems might be, and outline a process to follow
such as the one Ross outlined.

--
John Leslie <[email-masked]>

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 3 Feb 2010 13:26:56 +0200

I think Ross is addressing your other questions, but I'll add a little on these two:

On Feb 1, 2010, at 9:58 AM, Danny McPherson wrote:
> What's a restrictive environment again

It's defined by the three bullets immediately following the "restricted environment" line.  Seems clear to me.

> and how do we *guarantee* 
> this in BGP?

I see it as an applicability statement, not a statement of technical guarantee.  As you know, there many things in BGP that aren't *guaranteed* but depend on correct deployment practices.

> on scalability - all of this stuff seems to only lead to additional 

You've commented on the list of work items, I'm not aware of a specific work item that's been brought to the group such as you describe.  We already have "scalability" called out in the proposed revision, and what you describe would fall directly under that umbrella.  If you have something to propose, by all means please submit a draft.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 3 Feb 2010 13:40:37 +0200

> on scalability - all of this stuff seems to only lead to additional 

One more thing -- you say "all of this stuff seems to only lead to additional state and churn".  I would say rather, that state and churn are to some extent two different axes of the optimization space.  You can reduce state (imagine a route reflector hierarchy with no redundancy) but at the cost of greater churn (many messages exchanged both through that hierarchy and externally while converging to a new best path).  Or you can accept additional state (think of a flat IBGP mesh) which reduces churn because backup paths may already be present.  The challenge would seem to be finding the sweet spot in the optimization space.  Analysis on this has been presented at IDR, as recently as last meeting (the add-path mode analysis).  

In general, a lot of work I'm aware of (in IDR and elsewhere) on maximizing connectivity trades state for stability or restoration time.  If you have some analysis which supports the counterproposal that state and churn are positively coupled (either in general, or in specific proposals) it would be great if you wrote a draft laying out the details.

I'd also like to propose that as a basic goal, "maximizing global connectivity" is more fundamental than "reducing churn".  One may imply the other, but you know what they say about unquestioned assumptions.

--John

---

From: Danny McPherson <[email-masked]>
Date: Wed, 3 Feb 2010 04:59:03 -0700

> I see it as an applicability statement, not a statement of technical guarantee.  As you know, there many things in BGP that aren't *guaranteed* but depend on correct deployment practices.

Right, but assumptions about "restricted environments" and 
"correct deployment" in a global routing system protocol 
often results in negative systemic effects.  We've seen this 
several times already with 32-bit ASNs.  

Perhaps the charter should say "avoid extensions that require
restricted environments or correct deployment".  But alas, 
that's apparently not practical here..

-danny

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 3 Feb 2010 14:02:51 +0200

> several times already with 32-bit ASNs.  

Can you be more specific?  The 32-bit ASN issues I can think of were software bugs, not deployment issues.

--John

---

From: Danny McPherson <[email-masked]>
Date: Wed, 3 Feb 2010 05:15:18 -0700

> Can you be more specific?  The 32-bit ASN issues I can think of were software bugs, not deployment issues.

Fair point..  I just believe that, as you stated in another email, 
if "maximizing global connectivity" is a goal, then defining extensions 
that allow for software bugs to introduce systemic instability, or 
require "correct deployment", or that deployment be scoped to "restricted 
environments", this makes me uneasy.

Then again, perhaps I'm just being overly apprehensive.  I've 
stated my concerns...

-danny

---

From: Eric Rosen <[email-masked]>
Date: Wed, 03 Feb 2010 11:03:32 -0500

With regard to the paragraph:

        The IDR working group also has an oversight role for all extensions
        made to BGP for other uses that may be developed in other working
        groups. IDR will review extensions made to BGP in other working
        groups at least at WG document adoption and during working group
        last calls. The IDR working group will also provide advice and
        guidance on BGP to other working groups as requested. In some cases
        the IDR WG chairs may work with the chairs of other working groups
        and the IESG to move BGP work into the IDR WG instead of the another
        WG.

I'd suggest omitting the first and last sentences.  The first sentence adds
no content, it just provides something to fight about (what does "oversight"
mean, exactly?).  The last sentence doesn't seem to add anything either, as
WG chairs may negotiate at any time to move stuff from one WG to another.
Historically, however, IDR has been more likely to give stuff away than to
take stuff in.

On the issue of whether it is IDR's job to "protect the Internet" by
blocking other WGs from augmenting the use of BGP (or particular BGP
sessions), that fight has been fought and lost multiple times in the past
dozen years.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 3 Feb 2010 18:51:42 +0000

On Wed, Feb 03, 2010 at 11:03:32AM -0500, Eric Rosen wrote:
> mean, exactly?).

I would agree with Eric about omitting the first sentence.  I disagree with his
comment on the last sentence.

> sessions), that fight has been fought and lost multiple times in the past

I believe this is less an issue of "protecting the Internet" and more a matter
of maximizing interoperability.  The day a given BGP protocol based spec
deviates enough from the domain IDR cares about is the day that spec should be
forked and the protocol run on a different TCP port.  At that point, it becomes
that working group's responsibility to provide an interoperability mechanism if
some sort of interoperability is desired.

I bowed very quickly out of the MPLS-TP work but I believe that illustrates
what happens when one group takes another's protocol and decides to do their
own thing.  Let's not have that level of squabble within IETF.

Scalability and session survivability are perhaps another matter.  The new
charter helps address that with the following work item:
- Augment the BGP multiprotocol extensions to support the use of                                                              
  multiple concurrent sessions between a given pair of BGP speakers.  

With the addition of that work item, my two major concerns about IDR's
shepherding role for BGP are satisfied:
- Be interoperable
- If you're going to cram something into BGP that's interoperable but may have
  scaling issues for the wider Internet, give me a way to separate that stuff
  so we can keep global IP connectivity working well.

-- Jeff

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Feb 2010 15:02:44 +0200

John, Danny,

on scalability

I am in the same camp as Danny here. I saw John's response that this is
already covered by the general scalability work and that no specific
proposals have been submitted to date.

I think scalability (including state) is very important. If the WG does
not have a current proposals that relate to minimization of state,
perhaps you could add a milestone to determine what can be done about
it?

Jari

---

From: Ross Callon <[email-masked]>
Date: Thu, 4 Feb 2010 21:44:42 -0500

>> I'd suggest omitting the first and last sentences.  The first sentence 
>> adds no content, it just provides something to fight about (what does
>> "oversight" mean, exactly?).
>
> I would agree with Eric about omitting the first sentence.  I disagree
> with his comment on the last sentence.

The last sentence pretty much summarizes normal process when two working groups disagree on where work should be done -- the WG chairs and ADs get together and figure something out. Thus it really doesn't add much (and of course the work might be moved in the other direction as well). 

Ross

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Feb 2010 16:08:04 -0500

Jeff:

This note is **not** about word-smithing the charter, but your concerns 
regarding IDR's actions .

It would be good to have some proposals on exactly what it means to:
" BGP that's interoperable but may have scaling issues for the wider 
Internet."

We've chatted about what this mean for years, but "scaling issues for wider 
Internet" has lacked specific ideas.

While the IRTF and LISP work has suggested some parameters, I'm interested 
if you, Danny or Eric have a proposal or a paper you might reference.

Thanks,

Sue Hares

----- Original Message ----- 
From: "Jeffrey Haas" <[email-masked]>
To: "Eric Rosen" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 03, 2010 1:51 PM
Subject: Re: [Idr] Revised proposed IDR charter

>> adds