[Fwd: I-D ACTION:draft-fleischhauer-ipv4-addr-saving-00.txt]

I see nothing particularly new here -- just a rehash of the existing
ability to negotiate NCPs when and where desired -- but since it
describes PPP mechanisms directly, I'm forwarding it along to the list.

-- 
James Carlson         42.703N 71.076W         <carlsonj <at> workingcode.com>

From: I see nothing particularly new here -- just a rehash of the existing ability to negotiate NCPs when and where desired -- but since it describes PPP mechanisms directly, I'm forwarding it along to the list. -- -- James Carlson 42.703N 71.076W <carlsonj <at> workingcode.com> <Internet-Drafts <at> ietf.org>
Subject: I-D ACTION:draft-fleischhauer-ipv4-addr-saving-00.txt
Date: 2011-03-08 02:00:04 GMT

A new Internet-Draft is available from the on-line Internet-Drafts directories.

    Title         : On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios
    Author(s)     : O. Bonness, et al
    Filename      : draft-fleischhauer-ipv4-addr-saving-00.txt
    Pages         : 10
    Date          : 2011-03-07

new drafts posted for IPv6CP extensions

Two new drafts were posted for IPv6CP extensions.  The announcements are
attached.  You can see diffs from the previous version by looking here:

http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-requirements-01
http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-extensions-01

-- 
James Carlson         42.703N 71.076W         <carlsonj <at> workingcode.com>

From: Two new drafts were posted for IPv6CP extensions. The announcements are attached. You can see diffs from the previous version by looking here: http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-requirements-01 http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-extensions-01 -- -- James Carlson 42.703N 71.076W <carlsonj <at> workingcode.com> <Internet-Drafts <at> ietf.org>
Subject: I-D Action:draft-hu-pppext-ipv6cp-extensions-01.txt
Date: 2011-03-14 15:00:04 GMT

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : PPP IPv6 Control Protocol Extensions

Re: new drafts posted for IPv6CP extensions

A related draft was also posted to the RADEXT list:
http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-04

-----Original Message-----
From: pppext-bounces <at> ietf.org [mailto:pppext-bounces <at> ietf.org] On Behalf Of
James Carlson
Sent: Monday, March 14, 2011 2:31 PM
To: PPP Extensions
Subject: [Pppext] new drafts posted for IPv6CP extensions

Two new drafts were posted for IPv6CP extensions.  The announcements are
attached.  You can see diffs from the previous version by looking here:

http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-requirements-01
http://tools.ietf.org/html/draft-hu-pppext-ipv6cp-extensions-01

--

-- 
James Carlson         42.703N 71.076W         <carlsonj <at> workingcode.com>

_______________________________________________
Pppext mailing list
Pppext <at> ietf.org
https://www.ietf.org/mailman/listinfo/pppext

draft-simpson-isis-ppp-unique-00b

Sadly, I wasn't paying attention, and didn't notice there was another
IETF meeting coming up.  So, they won't let me post this draft today.

Here it is anyway for your perusal, just in case anybody is interested!

===

INTERNET-DRAFT                                               W A Simpson
                                                               DayDreamer
Intended status: Standards Track                           17 March 2011

              Generation of Unique IS-IS System Identifiers
                    draft-simpson-isis-ppp-unique-00b

Abstract

    The IS-IS routing protocol (Intermediate System to Intermediate
    System, ISO 10589) requires unique System Identifiers at the link
    layer.  A common practice has been to use an existing IEEE 802 MAC
    link-layer address.  When no unique MAC address is available, this
    document specifies automatic generation of identifiers.  It is fully
    interoperable with systems that do not support this extension.

    Additionally, the extension automatically resolves conflicts between
    System Identifiers.

Copyright Notice

    Copyright (c) 2011 IETF Trust and the persons identified as the
    document authors. All rights reserved.

Re: [rbridge] proposed TRILL IS-IS System ID text

On 2/4/11 8:01 PM, Anoop Ghanwani wrote:
> On Thu, Jan 27, 2011 at 12:34 PM, James Carlson
> <carlsonj <at> workingcode.com>  wrote:
>
>> At a minimum, I want to hear from IS-IS and TRILL experts before I go
>> ahead with proposing any new random-number-based System ID mechanism.
>> If they sign on, then I'll go ahead with it.
>>
>> But my off-the-cuff guess is that they'll have objections, and more
>> objections probably aren't helpful in getting to consensus.
>
> Coming from the TRILL part of the world, I don't think this is a problem
> that needs to be addressed in this draft.  Generating a unique System ID
> for IS-IS is an IS-IS problem, and as such should be addressed in the IS-IS
> working group.
>
> Anoop
>
After some local difficulty, I've posted to the pppext list a separate
draft.  If somebody points me at another WG list, I'll post it there too.

I'd be reasonably content to have the TRILL PPP draft reference my draft
for resolution of the issue.  Then, it can be discussed as many places
as needed.  As it is very simple and builds on existing standard's track
protocols, I doubt that it's contentious.
_______________________________________________
Pppext mailing list
Pppext <at> ietf.org
https://www.ietf.org/mailman/listinfo/pppext

Re: [rbridge] proposed TRILL IS-IS System ID text

On 3/17/11 3:31 PM, William Allen Simpson wrote:
> After some local difficulty, I've posted to the pppext list a separate
> draft. If somebody points me at another WG list, I'll post it there too.
>
> I'd be reasonably content to have the TRILL PPP draft reference my draft
> for resolution of the issue. Then, it can be discussed as many places
> as needed. As it is very simple and builds on existing standard's track
> protocols, I doubt that it's contentious.

http://www.ietf.org/mail-archive/web/pppext/current/msg00516.html

Since the IETF meeting starts tomorrow in Prague, and both TRILL and ISIS
meet on Monday, is anybody likely to be there and ask somebody over in the
ISIS WG whether they have any interest?  I'm planning on taking this
directly to RFC via Independent Submission.

So far, I've only received 2 private comments.

  1) about one reference in the PPP section.  I've checked, and that was
deprecated in [RFC1990].  So, I'll re-write to reference the earlier
decisions and language on the PPP list.  Nearly identical language
remains in [RFC1663].

  2) the 30 second timeout is too long.  That's easy to shorten, and
should probably have a random dither to avoid simultaneous changes.
How about 9-12 seconds inclusive?

It's pretty simple and uncontroversial.  But I'd still welcome any
word-smithing review!
_______________________________________________

Re: [rbridge] proposed TRILL IS-IS System ID text

Hi Bill,

On Sat, Mar 26, 2011 at 12:17 PM, William Allen Simpson
<william.allen.simpson <at> gmail.com> wrote:
> On 3/17/11 3:31 PM, William Allen Simpson wrote:
>>
>> After some local difficulty, I've posted to the pppext list a separate
>> draft. If somebody points me at another WG list, I'll post it there too.
>>
>> I'd be reasonably content to have the TRILL PPP draft reference my draft
>> for resolution of the issue. Then, it can be discussed as many places
>> as needed. As it is very simple and builds on existing standard's track
>> protocols, I doubt that it's contentious.
>
> http://www.ietf.org/mail-archive/web/pppext/current/msg00516.html

Well, the ISIS WG mailing list is isis-wg <at> ietf.org. I suppose, if you
want, I could post it there. I am also planning to attend and could
probably say something about it.

> Since the IETF meeting starts tomorrow in Prague, and both TRILL and ISIS
> meet on Monday, is anybody likely to be there and ask somebody over in the
> ISIS WG whether they have any interest?  I'm planning on taking this
> directly to RFC via Independent Submission.

There will be a brief mention of the
draft-ietf-pppext-trill-protocol-02.txt draft, along with other TRILL
relevant drafts, during the initial presentation by the chairs.

> So far, I've only received 2 private comments.

Re: draft-simpson-isis-ppp-unique-00b

Hi,

Just a couple little quick comments from my point of view.

I mentioned yesterday at the ISIS Working Group meeting that this
draft was coming.

Thanks,
Donald

On Thu, Mar 17, 2011 at 8:24 PM, William Allen Simpson
<william.allen.simpson <at> gmail.com> wrote:
>...
>
> INTERNET-DRAFT                                               W A Simpson
>                                                              DayDreamer
> Intended status: Standards Track                           17 March 2011
>
>
>             Generation of Unique IS-IS System Identifiers
>                   draft-simpson-isis-ppp-unique-00b
>
>
> Abstract
>
>   The IS-IS routing protocol (Intermediate System to Intermediate
>   System, ISO 10589) requires unique System Identifiers at the link
>   layer.  A common practice has been to use an existing IEEE 802 MAC
>   link-layer address.  When no unique MAC address is available, this
>   document specifies automatic generation of identifiers.  It is fully

Re: draft-simpson-isis-ppp-unique-00b

On 3/29/11 8:31 AM, Donald Eastlake wrote:
> I mentioned yesterday at the ISIS Working Group meeting that this
> draft was coming.
>
Tried listening, but missed the first 40 minutes as I'd thought it was
UTC+1 -- it was UTC+2.

>>    Typically, IS-IS implementations base the identifier on an existing 6
>>    octet Media Access Control (MAC) identifier defined for one of its
>>    link-layer interfaces.  The 48-bit MAC is composed of a 24-bit
>
> "... is *usually* composed ..."
> Also add a reference to [RFC3452].
>
"FEC Building Block"?  Obsoleted by: 5052, 5445?

> These days you can get an 36 bit prefix, called an Individual Address
> Block, which is cheaper than a 24 bit OUI pre-fix.
>
OK.

>>    Some systems have only point-to-point links without any conveniently
>>    available MAC, and do not have a configured identifier.  This status
>>    might change dynamically, as hot swap interfaces are added or
>>    removed.
>
> Suggest "only point-to-point links without any conveniently available
> MAC" ->  "only point-to-point or other links that do not have an
> associated MAC address"
>

Re: draft-simpson-isis-ppp-unique-00b

Hi,

On Tue, Mar 29, 2011 at 7:47 PM, William Allen Simpson
<william.allen.simpson <at> gmail.com> wrote:
> On 3/29/11 8:31 AM, Donald Eastlake wrote:
>>
>> I mentioned yesterday at the ISIS Working Group meeting that this
>> draft was coming.
>>
> Tried listening, but missed the first 40 minutes as I'd thought it was
> UTC+1 -- it was UTC+2.

It wasn't that exciting. I just told people to keep an eye out for our
draft and explained in about four sentences what its goal was.

>>>   Typically, IS-IS implementations base the identifier on an existing 6
>>>   octet Media Access Control (MAC) identifier defined for one of its
>>>   link-layer interfaces.  The 48-bit MAC is composed of a 24-bit
>>
>> "... is *usually* composed ..."
>> Also add a reference to [RFC3452].
>>
> "FEC Building Block"?  Obsoleted by: 5052, 5445?

  Sorry, that's 5342. I got the right digits, just in a random
order.... It has a definition of Individual Address Blocks.

Thanks,
Donald
=============================