In-line
On Thu, Mar 14, 2013 at 1:50 PM, Robert Raszuk <[email protected]> wrote:
>> I do see setting an MPLS label as a characteristic of a next-hop. The
>> concern will be describing capabilities reasonably without a rat-hole.
>
> As I said transport label yes .. VPN label no. Also how about IP GRE
> /IPv6 and other encapsulations ? This is prerequisite for any service
> or application today.
[Alia] For the VPN label, I think that depends - I could see a
VPN-specific RIB that outputs the VPN label and transport label. And
YES, of course, other encapsulations are needed and of interest.
There's capability negotiation.
In the Framework draft Sec 4.1.1:
" Encapsulation: Associated with each primary next-hop can be
details on the type of encapsulation for the packet. Such
encapsulation could be MPLS, GRE, etc. as supported by the
router.
"
WRITE UP YOUR USE-CASES and DESCRIBE what functionality you need!
>> This is doing L3 routing - so VLAN matching seems out; while there may
>> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet.
>
> I think you have missed my point. I am talking about L3. Imagine L3VPN
> PE ... I want to configure the service using I2RS ... you have had use
> case for this even presented today. So I must match on the incoming
> interface (physical or logical) to make sure propor RIB table is used
> for packet lookup.
[Alia] Sure - you need to be able to write to different tables in the
RIB - of course. Look in the framework draft - in Sec 4.1.1
" Route Table Context: There can be different route table contexts in
the RIB. Examples include multiple protocols (e.g. IPv4, IPv6),
multiple topologies, different uses, and multiple networks (e.g.
VRF tables for VPNs). Appropriate application-level abstractions
are required to describe the desired route table context.
"
Best Regards,
Alia
P.S. How was the remote participation?
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
