Re: [Softwires] softwires-encaps-safi

Hi Yakov,

We have posted another version of the draft that attempts to
address the below concerns. The draft is at
http://www.ietf.org/internet-drafts/draft-ietf-softwire-encaps-safi-01.t
xt

Among the changes are the following:

(1) Added section 4.3 to describe how the color is to be encoded
    as a sub-tlv in the encaps-SAFI. The section also defines a
    new opaque extended community for color that is to be attached
    to payload prefix UPDATE messages.

(2) Added text to section 4.4 to describe the behavior wrt nexthop
    resolution and colors. The following is the excerpt:

   "
   If a BGP speaker originates an update for prefix P with color C and
   with itself as the next hop, then it MUST also originate an encaps-
   SAFI update which contains the color C.

   Suppose that a BGP speaker receives an update for prefix P with color
   C, that the BGP decision procedure has selected the route in that
   update as the best route to P, that the next hop is node N, but that
   an encapsulation SAFI update originating from node N containing color
   C has not been received. In this case, no route to P will be
   installed in the forwarding table unless and until the corresponding
   encapsulation SAFI update is received, or the BGP decision process
   selects a different route.

   Suppose that a BGP speaker receives an "uncolored" update for prefix
   P, with next hop N, and that the BGP speaker has also received an
   encapsulation SAFI originated by N, specifying one or more
   encapsulations that may or may not be colored. In this case, the
   choice of encapsulation is a matter of local policy. The only
   "default policy" necessary is to choose one of the specified
   encapsulations.
   "

   Hope this clarifies the point.

Comments and feedback welcome.

Rgds,
- Pradosh

| -----Original Message-----
| From: softwires-bounces@ietf.org 
| [mailto:softwires-bounces@ietf.org] On Behalf Of Yakov Rekhter
| Sent: Monday, May 05, 2008 3:35 PM
| To: David Ward
| Cc: Francois Le Faucheur (flefauch); Alain Durand; Jari 
| Arkko; softwires@ietf.org; John G. Scudder <jgs@juniper.net>; 
| jianping; Russ White <riw@cisco.com>
| Subject: Re: [Softwires] softwires-encaps-safi
| 
| Dave,
| 
| > All -
| > 	We'd like to LC the suite of mesh related documents at 
| one time since 
| > they are all dependent on each other:
| > 
| >        draft-ietf-softwire-mesh-framework-04.txt
| >        draft-ietf-softwire-v4nlri-v6nh-01.txt
| >        draft-ietf-softwire-encaps-safi-00.txt
| >        draft-ietf-softwire-encaps-ipsec-01.txt
| > 
| > 
| > For this last call, if you have comments or nits please have the 
| > subject line include the draft title. For example Subject: 
| softwire- 
| > encaps-safi (as appropriate) so that your email clearly specifies 
| > which draft you are commenting on. Given that everyone is 
| so familiar 
| > w/ the set of specifications and the delta to this rev is rather 
| > small, we are going to have a 2.5 week Last Call period. It 
| will end 
| > May 23, 2008.
| 
| I think that one area of the document needs further clarification.
| 
| The following covers the discussion I had a while ago with 
| the authors.
| 
| From 4.3:
| 
|    Additionally, the Encapsulation SAFI UPDATE message can contain a
|    community or extended-community as a way to color the corresponding
|    tunnel TLV(s).  The same community or extended community 
| can then be
|    attached to the UPDATE messages that contain payload prefixes. This
|    way, the BGP speaker can express the fact that it expects 
| the packets
|    corresponding to these payload prefixes to be received with a
|    particular tunnel encapsulation header.
| 
| With this in mind consider a scenario where a PE receives an 
| encaps-safi update for a tunnel destined to address A1, and 
| this update is "colored" with a particular community C. The 
| PE also receives an VPN-IPv4 update that carries the same 
| community C, but its next hop is not A1, but A2.
| 
| What should the PE do when resolving the next hop towards 
| VPN-IPv4 routes ?
| 
| One could argue that if the nexthop address in a VPN-IPv4 
| update does not match any of the addresses from an 
| encaps-safi update, the nexthop can not get resolved. In 
| other words, this should be treated as a misconfig -- i.e.  
| there is no way to reach that nexthop using a tunnel encap 
| (unless there is some local config forcing to use an encap).
| 
| However, this argument is incorrect, as just because the 
| nexthop address in the VPN-IPv4 update does not match any of 
| the addresses from an encap-safi update does not really mean 
| that "the next hop can not get resolved".  In other words, 
| just because there is no way to reach the nexthop using the 
| tunnel carried in the encap-safi, does not mean that there is 
| no way to that nexthop.
| 
| Another alternative could be as follows:
| 
| 1. Next hop resolution is done as usual, with no regard to color.
|  
| 2. If  the next hop corresponds to  two encaps-safis, one red 
|  and one blue,
| then:
| 
|     - if the destination address matches a red prefix, use 
| the red encaps
|  
|     - if the destination address matches a blue prefix, use 
| the blue encaps
|  
|     - if the  destination prefix  is not colored,  and there 
| is  no uncolored
|       encaps-safi,  then  we have  a  config error  and  the  
| packet will  be
|       dropped.
| 
| In this alternative the last item seems incorrect - it should 
| be up to the ingress PE to decide whether to forward or to 
| drop (it is a matter of policy).
| 
| Moreover, there is a case that is not covered by the above. 
| Namely, where the Next Hop does not match any of the 
| addresses from the encap-safi updates.  In this case one can 
| not say that the next hop can not get resolved; it can not 
| get resolved *only* via available encap-safi. 
| 
| With all this in mind perhaps the spec should say that if 
| after the next hop resolution, the next hop does not have any 
| encaps info, or does not have encaps info that matches the 
| color of the prefix, then disposition of the packet is a 
| matter of policy on the ingress PE.
| 
| Of course, the next question to ask is what is the default 
| policy that every vendor SHOULD support. Here is a strawman 
| proposal for such default policy:
| 
| 1. Perform the usual procedures for finding the next hop, call it N.
|  
| 2. If no next hop is found, drop the packet and exit.
| 
| 3. If the policy is that there must be a color-matching 
| encaps-safi, then
|  
|     a. If there is none, remove from consideration all routes 
| whose next hop
|        is N, and go to 1.
|  
|     b. If there is a color-matching encaps-safi, tunnel the 
| packet according-
|        ly and exit.
| 
| 4. If the  policy  is  that there  does  not need  to  be a  
| color-matching
|    encaps-safi, then do whatever the policy says.
| 
| Yakov.
| _______________________________________________
| Softwires mailing list
| Softwires@ietf.org
| https://www.ietf.org/mailman/listinfo/softwires
| 
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires