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

[Ron Bonica <[e-mail]>]

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

                                -r


Scott Wainner wrote:
> I think that the following paragraph needs to be modified:
> 
>   The effect is to dynamically create an IP (or GRE) tunnel between the
>   ingress and egress PE routers.  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]
> 
> 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:
> 
>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>