Re: v6 deagg

[Måns Nilsson]

Subject: Re: v6 deagg Date: Sat, Feb 21, 2015 at 01:48:48PM +0100 Quoting 
Sander Steffann (san...@steffann.nl):

> > However, apparently there is no such process or intention available
> > from the RIR in question (RIPE), short of explicitly asking for that
> > specific prefix.
> 
> So you asked to grow the /48 to a /47? Was it accepted? Or did you want the 
> RIR to automatically grow your first assignment when you request a second one 
> without you having to ask?

So far have just discussed it with my LIR, but will reinit this. 
 
> > Of course this does not help every case, but supporting aggregation
> > where possible certainly ought to be in-scope for most policy-making
> > bodies in this area.
> 
> Then please take this to the appropriate policy-making body: 
> address-policy...@ripe.net :-)

Considering this as well. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
... this must be what it's like to be a COLLEGE GRADUATE!!


signature.asc
Description: Digital signature

Re: draft-ietf-mpls-ldp-ipv6-16

[Rogers, Josh]

RFC7349 is a nice summary of everything we¹re still missing wrt MPLS and
is relatively recent so should be close to up to date.  In addition to the
MPLS shortcomings, it also touches on recent IGP updates:


>3.2.3.1.  Interior Gateway Protocol (IGP)
>
>   RFC 3630 [RFC3630] specifies a method of adding traffic engineering
>   capabilities to OSPF Version 2.  New TLVs and sub-TLVs were added in
>   RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF
>   Version 3.
>
>   RFC 5305 [RFC5305] specifies a method of adding traffic engineering
>   capabilities to IS-IS.  New TLVs and sub-TLVs were added in RFC 6119
>   [RFC6119] to extend TE capabilities to IPv6 networks.
>
>   Gap: None.

When you talk to your vendor, ask what code will support these RFC¹s.


-Josh



>On 2/21/15, 6:00 AM, "nanog-requ...@nanog.org" 
>wrote:
>
>>--
>>
>>Message: 1
>>Date: Fri, 20 Feb 2015 09:00:07 -0500
>>From: Tim Durack 
>>To: Saku Ytti 
>>Cc: "nanog@nanog.org" , Juniper-Nsp
>>  , "cisco-...@puck.nether.net"
>>  
>>Subject: Re: draft-ietf-mpls-ldp-ipv6-16
>>Message-ID:
>>  
>>Content-Type: text/plain; charset=UTF-8
>>
>>On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti  wrote:
>>
>>>On (2015-02-19 11:06 -0500), Tim Durack wrote:
>>>
 What is the chance of getting working code this decade? I would quite
>>>like
 to play with this new fangled IPv6 widget...

 (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last
 piece for me.)
>>>
>>>Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to
>>>accept
>>>IPv6 next-hop in BGP LU, but probably does not work out-of-the-box?
>>>Isn't Segment Routing implementation day1 IPV4+IPV6 in XR?
>>>
>>>--
>>>   ++ytti
>>>
>>
>>I would gladly take OSPFv2/OSPFv3/ISIS+SR over LDP, but I'm seeing that
>>is
>>not all that is needed.
>>
>>I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working
>>over IPv6.
>>
>>IPv6 control plane this decade may yet be optimistic.
>>
>>--
>>Tim:>
>>
>


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: v6 deagg

[William Herrin]

On Thu, Feb 19, 2015 at 10:07 PM, Randy Bush  wrote:
> but then we considered that v6 allocations seem to be /32s, and the
> longest propagating route seems to be /48, leaving 16 bits with which
> the deaggregators can play.  while in v4 it was /24s out of a /19 or
> /20, four or five bits.
>
> this does not bode well.

Howdy,

I took a look at what it might take to keep TE-based disaggregation
under control back in 2009. This is what I came up with:

http://lists.arin.net/pipermail/arin-ppml/2009-June/014351.html

Needless to say, the sparse allocation expandable netmask strategy
we're using instead doesn't have many levers we can grab for control.

Regards,
Bill Herrin




-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: v6 deagg

[Sander Steffann]

Hi Mans,

> I'm working at one of those organisations who have a /48 and am announcing
> it into DFZ. We have a situation where I might have another site with
> separate connectivity to the DFZ (but there is internal networking)
> which would entitle me to another /48 according to RIR rules.

Correct.

> I did ask my LIR whether there is any thought given to the possibility of
> getting the next higher prefix, thus creating a /47. They did understand
> the "why" perfectly well, of course.
> 
> However, apparently there is no such process or intention available
> from the RIR in question (RIPE), short of explicitly asking for that
> specific prefix.

So you asked to grow the /48 to a /47? Was it accepted? Or did you want the RIR 
to automatically grow your first assignment when you request a second one 
without you having to ask?

> Of course this does not help every case, but supporting aggregation
> where possible certainly ought to be in-scope for most policy-making
> bodies in this area.

Then please take this to the appropriate policy-making body: 
address-policy...@ripe.net :-)

Cheers!
Sander

Re: v6 deagg

[Måns Nilsson]

Subject: Re: v6 deagg Date: Fri, Feb 20, 2015 at 10:42:03AM +0100 Quoting 
Mikael Abrahamsson (swm...@swm.pp.se):
 
> From a technical point of view, I have little interest in my router
> handling the fact that an office at the other side of the planet
> shut down their router, and learning this via DFZ.

I'm working at one of those organisations who have a /48 and am announcing
it into DFZ. We have a situation where I might have another site with
separate connectivity to the DFZ (but there is internal networking)
which would entitle me to another /48 according to RIR rules. 

I did ask my LIR whether there is any thought given to the possibility of
getting the next higher prefix, thus creating a /47. They did understand
the "why" perfectly well, of course.

However, apparently there is no such process or intention available
from the RIR in question (RIPE), short of explicitly asking for that
specific prefix.

Of course this does not help every case, but supporting aggregation
where possible certainly ought to be in-scope for most policy-making
bodies in this area.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
I'm wearing PAMPERS!!


signature.asc
Description: Digital signature