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

From: Ron Bonica <[email-masked]>
Date: Mon, 01 Aug 2005 01:01:02 -0400

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 <[email-masked]>
>>> Subject: draft-ietf-l3vpn-gre-ip-2547-04.txt.
>>> To: [email-masked]
>>> Message-ID: <[email-masked]>
>>> 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
>>>
>>>
>>>
>>
>>
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 01 Aug 2005 01:43:45 -0700

Hi Ron,

Draft-ietf-l3vpn-gre-ip-2547-04 just specifies the encapsulation options 
assuming peers are manually configured. IMHO the day already came long 
time back (the moment we started to give ability for single side tunnel 
provisioning) to require automated way for peers to know what the other 
end is capable of decapsulating.

In that light draft-ietf-l3vpn-gre-ip-2547-04 does not seems like easy 
to deploy in large scale today making it an incomplete spec.

Cheers,
R.

>> 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.
>>
>> the Next Hop address without reverting back to statically configuring 
>> IP tunnel end-points.
>>
>>>> Seems that some form of signaling is required which is not defined 
>>>> in this
>>>> draft.
>>>>
>>>> Scott Wainner
>>>>
>>>>
>>>>
>>>> Message: 1

---

From: Scott Wainner <[email-masked]>
Date: Mon, 01 Aug 2005 09:06:59 -0400

I think that the following paragraph needs to be modified:

   ingress and egress PE routers.  No apriori configuration of the

to:

   The IP address of the remote tunnel endpoints MAY be inferred from 
the Network Address of the Next Hop field of the MP_REACH_NLRI BGP 
attribute [4].  Note that the set of Next Hop Network Addresses is not 
known in advance, but is learned dynamically via the BGP distribution of 
VPN-IP routes.  Assuming a consistent set of tunnel capabilities exist 
between all the PE's and ASBR's, no apriori configuration of the remote 
tunnel endpoints is needed.  The entire set of PE and ASBR routers MUST 
have the same tunnel capabilities if the dynamic creation of IP (or GRE) 
tunnels is desired.  The preference to use an IP (or GRE) tunnel MUST be 
configured.  A set of PE's using two or more tunnel mechanisms (i.e. 
LSP, GRE, IP, etc.) MUST determine the tunnel type on a per peer basis.  
The automatic association of tunnel capabilities on a per peer basis is 
for future study.  Note that these tunnels SHOULD NOT be IGP-visible 
links and routing adjacencies SHOULD NOT be supported across these tunnel.

Scott Wainner

Ron Bonica wrote:

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

---

From: Ron Bonica <[email-masked]>
Date: Tue, 02 Aug 2005 03:59:13 -0400

Agreed. I will make this change in the next version of the draft.

                                -r

Scott Wainner wrote:
>   The IP address of the remote tunnel endpoints MAY be inferred from the 
> Network Address of the Next Hop field of the MP_REACH_NLRI BGP attribute 
> [4].  Note that the set of Next Hop Network Addresses is not known in 
> advance, but is learned dynamically via the BGP distribution of VPN-IP 
> routes.  Assuming a consistent set of tunnel capabilities exist between 
> all the PE's and ASBR's, no apriori configuration of the remote tunnel 
> endpoints is needed.  The entire set of PE and ASBR routers MUST have 
> the same tunnel capabilities if the dynamic creation of IP (or GRE)