Re: draft-ietf-l3vpn-gre-ip-2547-04.txt

[Robert Raszuk <[e-mail]>]

Scott,

The question is valid and the automated solution to the problem has been 
proposed many times :)

Just for the reference please look at the below draft:

http://community.roxen.com/developers/idocs/drafts/draft-raggarwa-ppvpn-tunnel-encap-sig-01.html

Before we finalize the automated way the provisioning tools are 
responsible for selecting the encapsulation of choice.

Cheers,
R.



> In reviewing draft-ietf-l3vpn-gre-ip-2547-04.txt, I noted the following 
> that requires some clarification:
> 
>> 4.1  MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE
>>
>>   The following description is not meant to specify an implementation
>>   strategy; any implementation procedure which produces the same result
>>   is acceptable.
>>
>>   When an ingress PE router receives a packet from a CE router, it
>>   looks up the packet's destination IP address in a VRF that is
>>   associated with packet's ingress attachment circuit.  This enables
>>   the (ingress) PE router to find a VPN-IP route.  The VPN-IP route
>>   will have an associated VPN route label and an associated BGP Next
>>   Hop. The label is pushed on the packet.  Then an IP (or IP+GRE)
>>   encapsulation header is prepended to the packet, creating an
>>   MPLS-in-IP (or MPLS-in-GRE) encapsulated packet.
> 
> 
> It appears that the ingress PE can choose to use MPLS-in-IP or MPLS-in-
> GRE implying that the egress MUST be able to perform both forms of
> decapsulation.  If the egress PE can only perform one form of 
> decapsulation,
> how does the ingress PE determine which form of encapsulation is preferred
> or required?
> 
>                                                       The IP source
> 
>>   address field of the encapsulation header will be an address of the
>>   ingress PE router itself.  The IP destination address field of the
>>   encapsulation header will contain the value of the associated BGP
>>   Next Hop; this will be an IP address of the egress PE router.  QoS
>>   information can be copied from the VPN packet to the GRE/IP tunnel
>>   header so that required forwarding behaviors can be maintained at
>>   each hop along the forwarding path.
> 
> 
>>   The effect is to dynamically create an IP (or GRE) tunnel between the
>>   ingress and egress PE routers.
> 
> 
> Presumably, the ingress PE and/or egress PE are also capable of forwarding
> packets via label switched paths (either between themselves or to other
> PE's or ASBR's).  In a mixed environment, its conceivable that two PE's
> could only communicate via GRE or IP while a third could use an LSP to the
> one or the other PE.   What means does the ingress PE use to determine
> that the LSP should be used verses the GRE or IP encap?
> 
>>                                     No apriori configuration of the
>>   remote tunnel endpoints is needed.  Note that these tunnels SHOULD
>>   NOT be IGP-visible links, and routing adjacencies SHOULD NOT be
>>   supported across these tunnel.  Note also that the set of remote
>>   tunnel endpoints is not known in advance, but is learned dynamically
>>   via the BGP distribution of VPN-IP routes.  The IP address of the
>>   remote tunnel endpoints is carried in the Network Address of the Next
>>   Hop field of the MP_REACH_NLRI BGP attribute [4]
> 
> 
> This model assumes that the Network Address of the Next Hop field is the
> destination tunnel address.  This may or may not be true.  The provider
> may in fact want the externally accessible tunnel address to be distinct
> from the Next Hop address for a variety of reasons including security,
> transitive tunnels, etc.  How does the egress PE indicate to the ingress
> PE that the tunnel should NOT be built to the Next Hop address, but to
> a designated tunnel address assigned on the egress PE?  Likewise, how
> does an ASBR determine that traffic to prefixes to a peer ASBR should
> not be tunneled while prefixes to a peer PE should be tunneled.
> 
> Seems that some form of signaling is required which is not defined in this
> draft.
> 
> Scott Wainner
> 
> 
> 
> Message: 1
> Date: Fri, 22 Jul 2005 17:31:30 -0700 (PDT)
> From: Rick Wilder <[e-mail]>
> Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt.
> To: [e-mail]
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> L3VPN participants,
> 
> 
> This begins a two-week last call for comments on 
> draft-ietf-l3vpn-gre-ip-2547-04.txt.
> 
> Rick
> 
> 
>