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

[Ron Bonica <[e-mail]>]

Scott, Robert,

Can we agree for now that draft-ietf-l3vpn-gre-ip-2547-04 is OK as is,
and that we can save the discussion below for the day when we address
automated signaling?

                              Ron


Scott Wainner wrote:
> 
> 
> 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
>>>
>>>
>>>
>>
>>
>