Re: 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:

Re: Revised proposed IDR charter

The new charter text looks good to me.

Jari

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Error handling in draft-ietf-idr-dynamic-cap-10.txt

Hi,

although draft-ietf-idr-dynamic-cap-10 contains some guidelines for
error handling, there is still possibility for having two conformant but
different implementations. Consider initiator of capability update
message requests removal (Action bit set to 1) of a capability, which
was not previously advertised. Current draft leaves it up to receiver
implementation to decide either to silently ignore such capability or to
send notification back to originator. Shouldn't behaviour in this
situation be explicitly defined as to avoid ambiguity? I think ideally
receiver of such confusing message should send undistruptive feedback,
but that would require implementation of not-yet-standardized
draft-ietf-idr-advisory. What's WG opinion on this?

Kind regards,
iLya
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

I-D Action:draft-ietf-idr-bgp4-mibv2-tc-mib-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway
Protocol (BGP-4)
	Author(s)       : J. Haas
	Filename        : draft-ietf-idr-bgp4-mibv2-tc-mib-01.txt
	Pages           : 6
	Date            : 2010-02-01

This memo defines a portion of the Management Information Base (MIB)
which defines Textual Conventions for the management of BGP-4.  The
intent is that these textual conventions will be used in BGP-related
MIB modules that would otherwise define their own representations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Idr mailing list
Idr <at> ietf.org

I-D Action:draft-ietf-idr-bgp4-mibv2-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version
	Author(s)       : J. Haas
	Filename        : draft-ietf-idr-bgp4-mibv2-10.txt
	Pages           : 45
	Date            : 2010-02-01

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols.  In particular it defines
objects for managing the Border Gateway Protocol, Version 4.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Re: Revised proposed IDR charter

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

Re: Revised proposed IDR charter

Ross Callon <rcallon <at> juniper.net> wrote:
> To: Danny McPherson <danny <at> tcb.net>
]] 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

Re: Revised proposed IDR charter

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:
>> - 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

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.

>> - 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 

Re: Revised proposed IDR charter

On Feb 1, 2010, at 9:58 AM, Danny McPherson wrote:
>> - 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.

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
_______________________________________________
Idr mailing list

Re: Revised proposed IDR charter

On Feb 3, 2010, at 4:26 AM, John G. Scudder wrote:
> 
> 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

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr