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

[Scott Wainner <[e-mail]>]

Robert Raszuk wrote:

> 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 


or alternatively ..
http://www.ietf.org/internet-drafts/draft-nalawade-kapoor-tunnel-safi-03.txt

Nevertheless, something must be signaled by the egress PE.

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

Certainly, a provisioning tool could specify the use of GRE, IP, or LSP 
encap; however, it would have to be done on a per peer basis.

In addition,  a distinct tunnel end-point cannot be distinguished from 
the Next Hop address without reverting back to statically configuring IP 
tunnel end-points.

Seems these requirements defeat the purpose of the draft.

Scott

>
>
> 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
>>
>>
>>
>
>