Subject: [Softwires] Mesh drafts to WG LC

From: David Ward <[email-masked]>
Date: Mon, 5 May 2008 15:34:31 -0500

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.

Many thanks to the authors and reviewers.

-DWard, Alain
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 05 May 2008 15:35:09 -0700

Dave,

> small, we are going to have a 2.5 week Last Call period. It will end  

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.

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Thu, 8 May 2008 08:19:54 -0700

Hi Yakov,

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

Are you referring to nexthop validation or nexthop resolution in this
context? I consider these as different: nexthop validation is what
triggers the BGP speaker to accept the received prefixes or reject them.
Nexthop resolution is what triggers the BGP speaker to install the
prefixes
in forwarding table for active lookups. If the nexthop is not resolved,
the prefixes are put in unresolved state.

The nexthop resolution itself takes various forms and is heavily
dependent
on whether the packet needs to be tunneled or sent in native encoding
format. If the application is to send the packet tunneled, just checking
nexthop reachability (e.g. IGP information) is not sufficient and it
would
in fact be incorrect to resolve the nexthop & prefixes just based on
that
(An example is the MPLS VPN case where we need to have MPLS encaps be
available for the BGP nexthops).

Coming back to encaps SAFI discussion, I think there are two scenarios
where I sense a concern:
(1) No encaps-safi for a nexthop,
(2) encaps-safi for a nexthop, but there is no match for prefix color

Let's take the first case. We agreed before that encaps-safi is not a
MUST (e.g. GRE tuneling), at which point, it becomes a local
configuration
on how to encap.

If there is no local configuration, I still maintain that having no 
encaps-safi for a nexthop means that nexthop is unresolved. This is
because
signaling information is propagated asynchronously in the network. If
a PE receives a VPN-IPv4 UPDATE with nexthop N1 and there is no
encaps-safi
information about N1, it does not necessarily mean N1 is to be resolved
in a certain different way. It could very well mean that the encaps-SAFI
update for N1 is in transit -- so the prefixes need to be kept in
unresolved
state till N1's encap information is available. There could, of course,
be
a local config to assume a certain default encap, but in the absense of
that config, it is better to put it in unresolved state.

I consider the second to be a "special case" of the first. Local
configuration can override to derive encap information for N1, but in
the absense of that, it would be unresolved. May be the color could
carry
a notion of "strict" match vs. a "loose" match in that, if it is
signaled
as a 'loose' match, then even if the prefixes are not colored, the
nexthop is considered to be resolved for those prefixes?

- Pradosh

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Thu, 8 May 2008 10:57:14 -0700

Hi Yakov,

| As I said in my original e-mail, here is a strawman proposal of what 
| should be added to the draft.
| 
| 1. 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.
| 
| 2. Each implementation SHOULD support the following (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.

I guess I am having a bit of trouble trying to find out what is done in
control plane and what is done in data plane from the above text. There
is no difference during packet forwarding time from usual
(non-encap-safi)
cases (e.g. longest prefix match), but point 3.a above seems to suggest
otherwise (or I must have misunderstood the point).

I am also having trouble trying to find out the default policy part and
"if there is a policy" part in the text. E.g. point 4 above seems to
suggest there is a policy defined, whereas it's inside the block for
default policy definition.

I am wondering what part does not get covered by your first point, or
an augmented paragraph like the following:

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. In
the
absense of a local policy at the ingress PE, the default action is to
hold
such routes in unresolved state.

Rgds,
- Pradosh

---

From: Carlos Pignataro <[email-masked]>
Date: Sat, 24 May 2008 00:07:50 -0400

>        draft-ietf-softwire-encaps-safi-00.txt

Please find some comments on ietf-softwire-encaps-safi, I hope these are 
useful:

     Tunnel Type (2 octets): It identifies the type of the tunneling
     technology being signaled. This document defines the following types:

       - L2TPv3: Tunnel Type = 1

L2TPv3 can be encapsulated in different ways over IP (e.g., directly
over IP proto 115, and over UDP). This document refers implicitly
(without mention) to L2TPv3 over IP (the only L2TPv3 mandatory
encapsulation from RFC3931), but does not explicitly clarify it. Could
this be disambiguated, e.g., by either: i. Renaming the Tunnel Type 1 to
"L2TPv3 over IP", or ii. Providing further L2TPv3 encap details (IP vs.
UDP, etc) in the Encapsulation sub-TLV for the L2TPv3 TLV Type?

~~~~~~

      * Session ID: a 4-octet value locally assigned by the advertising
        router that serves as a lookup key in the incoming packet's
        context.

Could "non-null" be added as a constrain for the Session ID? The 
all-zeros identifies and L2TPv3 Control Packet (instead of data packet) 
when running directly over IP. From RFC3931:

    Session ID

       A 32-bit field containing a non-zero identifier for a session.
...
    L2TP over IP uses the reserved Session
    ID of zero (0) when sending control messages.
...
          Note that the control message header in this case begins after
          the all-zero Session ID when running over IP

~~~~~~

       |                        Cookie (Variable)                      |
...
       * Cookie: an optional, variable length (encoded in octets - 0 to 8
         octets) value used by L2TPv3 to check the association of a
         received data message with the session identified by the Session
         ID. The Cookie value is tightly coupled with the Session ID.

This text defining/describing the Cookie field seems to allow for any
length of cookie from 0 to 8 octets; however, from RFC3931:

       The Assigned Cookie is a 4-octet or 8-octet random value.
...
       The value's length
       (0, 32, or 64 bits) is obtained by the length of the AVP.

Should this description constrain itself to either a 0-, 4- or 8-octet 
cookie (instead of any len between 0..8 octets)?

~~~~~~

4.2. Protocol Type sub-TLV
...
    Note that the protocol type sub-TLV is optional, e.g. if the
    tunneling technology is GRE, this sub-TLV is not required.

Is this sub-TLV also optional for L2TPv3 tunneling, which encap (unlike 
GRE) does not have a PID, or is it mandatory for L2TPv3 Tunnel Type? If 
still optional, how is the encapsulated Protocol Type (tunneled payload 
PID) signaled, checked, selected/validated in the dataplane?

~~~~~~

6. Security Considerations

Shouldn't this section be augmented with the security considerations of 
the tunneling protocols used? e.g., for l2tpv3, source (and dest) 
validation (for tunneled traffic) vs. (or plus) suggested use of  the 
cookie, etc?

~~~~~~

References:

I notice this document does not reference RFC2784 + RFC2890 and RFC3931. 
It seems it should, for example draft-ietf-softwire-encaps-ipsec (that 
does not concern with defining the Tunnel Types for L2TPv3 or GRE still 
add 2784/3931 references.

Thanks,

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Wed, 28 May 2008 08:52:21 -0700

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: [email-masked] 
| [mailto:[email-masked]] 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; [email-masked]; John G. Scudder <[email-masked]>; 
| jianping; Russ White <[email-masked]>
| 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
| [email-masked]
| https://www.ietf.org/mailman/listinfo/softwires
| 
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Wed, 28 May 2008 08:55:22 -0700

Hi Carlos,

Thanks for all the comments. Responses inline. The new revision (-01)
has the changes incorporated. The draft is at
http://www.ietf.org/internet-drafts/draft-ietf-softwire-encaps-safi-01.t
xt

| 
|      Tunnel Type (2 octets): It identifies the type of the tunneling
|      technology being signaled. This document defines the 
| following types:
| 
|        - L2TPv3: Tunnel Type = 1
| 
| L2TPv3 can be encapsulated in different ways over IP (e.g., directly
| over IP proto 115, and over UDP). This document refers implicitly
| (without mention) to L2TPv3 over IP (the only L2TPv3 mandatory
| encapsulation from RFC3931), but does not explicitly clarify it. Could
| this be disambiguated, e.g., by either: i. Renaming the 
| Tunnel Type 1 to
| "L2TPv3 over IP", or ii. Providing further L2TPv3 encap 
| details (IP vs.
| UDP, etc) in the Encapsulation sub-TLV for the L2TPv3 TLV Type?

Renamed the tunnel type to be 'L2TPv3 over IP'.

|       * Session ID: a 4-octet value locally assigned by the 
| advertising
|         router that serves as a lookup key in the incoming packet's
|         context.
| 
| Could "non-null" be added as a constrain for the Session ID? The 
| all-zeros identifies and L2TPv3 Control Packet (instead of 
| data packet) 
| when running directly over IP.

Done.

| ...
|        * Cookie: an optional, variable length (encoded in 
| octets - 0 to 8
|          octets) value used by L2TPv3 to check the association of a
|          received data message with the session identified by 
| the Session
|          ID. The Cookie value is tightly coupled with the Session ID.
| 
| 
| This text defining/describing the Cookie field seems to allow for any
| length of cookie from 0 to 8 octets; however, from RFC3931:
| 
|        The Assigned Cookie is a 4-octet or 8-octet random value.

Clarified that the cookie value is as per RFC 3931.

| 
| 4.2. Protocol Type sub-TLV
| ...
|     Note that the protocol type sub-TLV is optional, e.g. if the
|     tunneling technology is GRE, this sub-TLV is not required.
| 
| Is this sub-TLV also optional for L2TPv3 tunneling, which 
| encap (unlike 
| GRE) does not have a PID, or is it mandatory for L2TPv3 
| Tunnel Type? If 
| still optional, how is the encapsulated Protocol Type 
| (tunneled payload 
| PID) signaled, checked, selected/validated in the dataplane?

Clarified the description to mean that protocol type 
sub-TLV is mandatory for L2TPv3 and optional for GRE.

| 6. Security Considerations
| 
| Shouldn't this section be augmented with the security 
| considerations of 
| the tunneling protocols used? e.g., for l2tpv3, source (and dest) 
| validation (for tunneled traffic) vs. (or plus) suggested use of  the 
| cookie, etc?

Have added the following text to this section:

"
   Security considerations applicable to Softwires can be found in the
   mesh framework [Softwires-Mesh-Frame-work]. In general, security
   issues of the tunnel protocols signalled through encapsulation SAFI
   are inherited.
"

| References:
| 
| I notice this document does not reference RFC2784 + RFC2890 
| and RFC3931. 
| It seems it should, for example 
| draft-ietf-softwire-encaps-ipsec (that 
| does not concern with defining the Tunnel Types for L2TPv3 or 
| GRE still 
| add 2784/3931 references.

Added these references.

Rgds,
- Pradosh

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 29 May 2008 11:29:16 -0400

Hi Pradosh,

Thank you for the quick responses, the updated rev -01 addresses all my 
comments.

Thanks,

--Carlos.

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Thu, 29 May 2008 08:57:44 -0700

Hi Yakov,

Thanks for the review.

| 
| The default policy MUST allow to support encapsulation that 
| is not specified in the received encapsulation SAFI. E.g., if 
| the speaker receives an "uncolored" update with BGP 
| encapsulation extended community, the default policy MUST 
| allow to select the encapsulation specified in this 
| community, even if there is no encapsulation SAFI for this 
| encapsulation.  In other words, the choice of encapsulation 
| that MUST be supported by the "default policy" should not be 
| limited to the encapsulations carried in the encapsulation 
| SAFI, but should allow any encapsulation supported by the local box.

Agreed.

| 
| With this in mind I proposed to replace the last sentence in 
| the above paragraph with the following:
| 
|      The only "default policy" necessary is to choose one of the 
|      encapsulations supported by the speaker.
| 

I am fine with the proposed text.

- Pradosh

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 29 May 2008 09:15:12 -0700

Pradosh,

> Thanks for the review.

welcome :-)

> I am fine with the proposed text.

Looking forward for the revised text.

Yakov.