Re: [Idr] 6PE-Alt draft

["Vishwas Manral" <[e-mail]>]

Hi Francois,

As the 6PE-Alt does not require any additional functionality from
BGP-IPv6 (yes that is the signaling required - but that is the same
required for normal BGP IPv6. For 6PE we use a new AFI/ SAFI and send
labels uselessly. So please do not say that the claim no signaling
changes are required for 6PE-Alt  is a stretch), and that is why we
have inter-operable implementations of 6PE-Alt too. It is not about
interoperable implmentations alone though. I however am surprised how
this simple mechanism was not captured earlier in the review or coding
process.

We do not need to transport labels at all which are now being
transported. Also as the peer decides the label I use, we may have to
configure different labels from different peers (thus using bigger
keys/ more memory in the tables and a lot of other overload). There is
a lot of overhead of signaling and dataplane without any necessity.

I also have issues with the 6VPE RFC too but let us tackle issues one at a time.

Thanks,
Vishwas

On Jan 31, 2008 8:56 AM, Francois Le Faucheur IMAP <[e-mail]> wrote:
>
> Hi,
>
> FYI, here is a note posted on the v6ops list where that topic was brought up
> first by Vishwas.
>
>
>
> Begin forwarded message:
> From: Francois Le Faucheur IMAP <[e-mail]>
> Date: 31 January 2008 17:53:54 GMT+01:00
> To: Vishwas Manral <[e-mail]>
> Cc: Francois Le Faucheur IMAP <[e-mail]>, [e-mail],
> "Jeremy De Clercq" <[e-mail]>, "Ooms Dirk"
> <[e-mail]>, [e-mail]
> Subject: Re: 6PE-Alt
>
>
> On 31 Jan 2008, at 15:25, Vishwas Manral wrote:
>
>
> Hi Francois,
>
> The document I have written does not use signaling
>
> It is a bit of a stretch to claim that 6PE-Alt does not use signaling.
> 6PE-Alt and 6PE both use MP-BGP to signal IPv6 reachability.  6PE-Alt would
> simply save you one field (the label value) inside the same advertisement.
>
> On the other hand, 6PE-Alt would restrict operations to only one of the
> options allowed in 6PE. The reasons 6PE allowed multiple label allocation is
> precisely because different PEs may want to use different label allocation
> policies.  For example, one 6PE router may prefer to allocate per-prefix
> label in order to be able to forward packets via label switching as opposed
> to performing IPv6 lookup. 6PE allows each PR router to use whatever label
> allocation scheme it sees best.
>
>
>
> and does not define
> a new AFI/SAFI functionality to achieve the 6PE.
>
> It is a bit of a stretch to imply that 6PE defines a new AFI/SAFI.
> 6PE uses the IPv6 AFI and the SAFI defined in RFC3107 (which for memory
> dates back from 2001) precisely for the purpose of binding an MPLS label
> when advertising IPv6 reachability.
>
>
>
> The difference is obvious, we get the same functionality
>
> my impression is that you get a restricted subset of the functionality (ie
> forcing every router to use that single label allocation scheme). This had
> been discussed before and decided that such a restriction was undesirable
> and unnecessary.
>
>
> without
> adding any new signaling mechanism.
>
> my impression is that both use the same MP-BGP signaling mechanism except
> one would save a few bytes in the same MP-BGP advertisements.
>
> There are multiple interoperable implementations of 6PE today and am not
> aware of significant issues with the current 6PE control plane.
>
> Cheers
>
> Francois
>
>
>
>
>
>
> On 31 Jan 2008, at 16:00, Vishwas Manral wrote:
>
> Hi Jan,
>
> I am CC'ing the authors of the 6PE draft to get their views. Let me
> explain the draft in greater detail however.
>
> In 6PE, MP-BGP SAFI family label is used to exchange routes between 2
> 6PE routers (a new AFI/ SAFI combination is defined). Each route is
> attached with a label (which may be the IPv6 Explicit NULL label). In
> the data-plane this label is used as the inner label and the other
> label is the tunnel label, which gets the packet from source PE to
> destination PE. Once the packet gets to the destination PE, the inner
> label is looked up and a POP operation is done on it and the IPv6
> header is looked up in the routing table.
>
> With 6PE-Alt, no additional signaling mechanism is required. All we
> need to do is instead of using the signaled label as the inner label,
> we use the IPv6 Explicit NULL label. The same operations happen as 6PE
> without any explicit signaling of the labels with each route. It helps
> prevent all the excess signaling and still providing the exact same
> functionality. We are using the meaning implied in the "Explicit NULL
> Label". We do not need to signal anything here.
>
> As an alternate, if you notice in IPv6, the end sites/ devices will
> become IPv6 and the network may still have IPv4. If the assumption
> that each device in the IPv6 networks has a Global IPv6 address (not
> that IPv6 site local has been deprecated), we can do without the
> entire BGP MPLS IPv6 VPN functionality.
>
> Thanks,
> Vishwas
>
> On Jan 31, 2008 6:31 AM, Vishwas Manral <[e-mail]> wrote:
> Hi Jan,
>
> You may be missing the scope of the document. There is a discussion in
> the v6ops group too which .
>
> The idea is simple. We do not need to define a new AFI/ SAFI
> combination to achieve the 6PE functionality. We can just use the
> meaning implied in the IPv6 Explicit NULL label. The 6PE RFC does talk
> about allowing signaling for the Explicit NULL label in which case the
> dataplane functionality becomes just the same, but in 6PE even that is
> signaled using BGP extensions defined in RFC3107.
>
> Thanks,
> Vishwas
>
>
> On Jan 31, 2008 2:14 AM, Jan Novak <[e-mail]> wrote:
>
>
> Hi,
>
> Just out of curiosity - lets say you have two IPv4 VPNs with
> overlapping set of Pes and both of them want to provide 6PE
> service.
> When the explicit-null encapsulated packets from two different
> VPNs (but same PE) arrive to the other side PE - how do you
> decide which is which - e.g. which packet should be shipped to
> which VPN ??
>
> Jan
>
>
> _________________________________________________________________
> Telly addicts unite!
> http://www.searchgamesbox.com/tvtown.shtml
>
>
>

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