To: Robert Raszuk <robert@raszuk.net>
Cc: "bess@ietf.org" <bess@ietf.org>, draft-dawra-idr-srv6-vpn.authors@ietf.org,
 spring@ietf.org
References: <afb80dad-4f6a-332f-bb3a-4641a3c61a77@juniper.net>
 <CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <7dd8f2db-72dd-da17-6dc7-39f6ab44f543@juniper.net>
Date: Tue, 2 Jan 2018 09:10:45 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------54A25299DC12F9DDE693C821"
Content-Language: en-US
Received-SPF: None (protection.outlook.com: juniper.net does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jan 2018 14:10:50.2790 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 02559f55-eb80-4058-5013-08d551eaa15a
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2295
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, ,
 definitions=2018-01-02_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam
 score=0 priorityscore=1501
 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0
 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0
 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-1711220000 definitions=main-1801020210
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/WnOsGxpE6fL8U9LSfmqMO6RwzDs>
Subject: Re: [bess] Comments on draft-dawra-idr-srv6-vpn-03
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>,
 <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>,
 <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jan 2018 14:10:59 -0000

This is a multi-part message in MIME format.
--------------54A25299DC12F9DDE693C821
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 12/28/2017 1:55 PM, Robert Raszuk wrote:
> Ok let's start all over :)

 From the draft:

The SRv6 VPN SID MAY be routable within the AS of the egress-PE and
   serves the dual purpose of providing reachability between ingress-PE
   and egress-PE while also encoding the VPN identifier.

I took this to mean that  a single IPv6 address could cause the backbone 
to forward the packet to the egress-PE and cause the egress-PE to look 
up the payload's IP address in a VRF which is identified by that same 
IPv6 address.  Did I misunderstand that?

>     **** This suggests that an IPv6 address has to be assigned to each
>     VRF (for
>     **** per-VRF "labeling"), or even to each CE (for per-CE labeling).
>
>
> ​No one suggests that. VPN SID is not IPv6 address .. it is part of v6 
> SID which when appended to IPv6 prefix forms a complete SRv6 SID. 
> Semantics does matter here. ​

Given the above quote from the draft, I'm not sure what is wrong with 
what I said.

>
>     **** If those addresses are routable, doesn't this create a
>     security issue
>     **** as discussed in RFC 4023 Section 8.2?
>
>
> ​PE's loopback address say /64 being routable causes any security risk ? ​

Please see the reference.

>
>     **** The phrase "only has local significance" suggests that these
>     SIDs are
>     **** not routable. But later on there is a suggestion that they are
>     **** routable, or at least that they might be.
>
>
> ​Again SIDs are not routable and they have only local significance - 
> true. ​They are prepended to say loopback address to form IPv6 SID.
>
>     **** So there are a number of options:
>     **** - not routable
>     **** - globally routable
>     **** - routable only within egress AS
>
>
> ​This is referring to routability of SID ... not right. SID does not 
> need to be routable. What prefix they are part of may be routable. ​​

Just replace my use of the term "SID" with the longer term "the IPv6 
address of which the SID is a part".

>
>        and the BGP ingress device receiving this route
>        MAY choose to encapsulate or insert an SRv6 SRH, second it
>     indicates
>        the value of the SID to include in the SRH encapsulation.  For
>     L3VPN,
>        only a single SRv6-VPN SID MAY be necessary.
>
>     **** I don't understand the phrase "only a single SRv6-VPN SID MAY be
>     **** necessary".
>
>
> ​Analogy to basic L3VPN when you have VPN label and underlay LDP label. ​

Still don't understand what is being said.

>
>
>        If the BGP speaker supports MPLS based
>        L3VPN simultaneously, it MAY also populate the Label values in
>     L3VPN
>        route types and allow the BGP ingress device to decide which
>        encapsulation to use.  If the BGP speaker does not support MPLS
>     based
>        L3VPN services the MPLS Labels in L3VPN route types MUST be set to
>        IMPLICIT-NULL.
>
>     **** Please provide a reference that specifies how you set the
>     Label field
>     **** of a SAFI-4 or SAFI-128 route to "implicit null".  I don't
>     recall any
>     **** such thing existing in RFC 3107, 4364, or 8277.
>
>
>
> ​4364 does not restrict what value of VPN label is used - does it ? I 
> think this draft now right here defines ​how to read implicit-null 
> being placed there :) It's not my idea though - so I will let real 
> inventors to comment on it more.
>
>     **** If you mean "set to three" (the value defined in RFC 3032 to
>     represent
>     **** "implicit null"), I don't think the SAFI-4/SAFI-128
>     implementations
>     **** generally interpret the value three in that manner.
>
>
> ​As mentioned I think it just is being defined here and now. ​

I didn't see any mention of the numeric value to put in the label field 
of the NLRI.

> or to define a new special or reserved label ​for that embedded 
> signalling.

Some discussion of why this won't cause any backwards compatibility 
problems would be appropriate.


>
>
>     **** I'm not really sure what you're trying to do here. There are
>     at least
>     **** four cases to consider:
>
>     **** 1. For the case where the backbone doesn't have MPLS, there
>     is no harm
>     **** in saying "set the label to zero".
>
>
> ​Really ? ​What does the backbone having or not having MPLS has to do 
> with this ? Underlay forwarding does not matter and this is what I 
> read as "backbone".

What I meant is that if it is known a priori that SRv6 is being used 
instead of MPLS, the label value obviously doesn't matter, because it 
will never be used.

>
>     **** 2. For the case where the backbone supports both MPLS and
>     SRv6, and
>     **** some PEs support L3VPN both ways, while others support only
>     MPLS-based
>     **** L3VPN, then a real label needs to be put in.
>
>
> ​OK.​
>
>     **** 3. For the case where the backbone supports both MPLS and
>     SRv6, but a
>     **** particular egress PE only supports SRv6, there needs to be
>     some way to
>     **** instruct the ingress PEs to use SRv6 and not MPLS. Perhaps the
>     **** presence of the prefix-SID attribute with VPN-SID TLV is
>     sufficient.
>
>
> ​Perhaps not ... and this is exactly ​the case trying to be addressed.

Why isn't the presence of the attribute sufficient in this case?

>
>     **** 4. For the case where the backbone supports both MPLS and
>     SRv6, the
>     **** egress PE supports both for transit, but the egress PE only
>     supports
>     **** SRv6 for L3VPN, the label in the SAFI-1/SAFI-128 routes
>     should be a
>
>
> ​Label in SAFI 1 ? ​

Sorry, I meant SAFI-4.  Actually, only SAFI-128 really matters in this 
context, I think.



--------------54A25299DC12F9DDE693C821
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 12/28/2017 1:55 PM, Robert Raszuk wrote:<br>
    <blockquote type="cite"
cite="mid:CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div dir="ltr">
        <div class="gmail_default"
          style="font-family:arial,helvetica,sans-serif;font-size:small">Ok
          let's start all over :) <br>
        </div>
      </div>
    </blockquote>
    <br>
    From the draft:<br>
    <br>
        <tt>The SRv6 VPN SID MAY be routable within the AS of the
      egress-PE and</tt><tt><br>
    </tt><tt>  serves the dual purpose of providing reachability between
      ingress-PE</tt><tt><br>
    </tt><tt>  and egress-PE while also encoding the VPN identifier.<br>
    </tt><br>
    I took this to mean that  a single IPv6 address could cause the
    backbone to forward the packet to the egress-PE and cause the
    egress-PE to look up the payload's IP address in a VRF which is
    identified by that same IPv6 address.  Did I misunderstand that?<br>
    <br>
    <blockquote type="cite"
cite="mid:CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">****
              This suggests that an IPv6 address has to be assigned to
              each VRF (for<br>
              **** per-VRF "labeling"), or even to each CE (for per-CE
              labeling).<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​No
                one suggests that. VPN SID is not IPv6 address .. it is
                part of v6 SID which when appended to IPv6 prefix forms
                a complete SRv6 SID. Semantics does matter here. ​</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Given the above quote from the draft, I'm not sure what is wrong
    with what I said.<br>
    <br>
    <blockquote type="cite"
cite="mid:CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">**** If
              those addresses are routable, doesn't this create a
              security issue<br>
              **** as discussed in RFC 4023 Section 8.2?<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​PE's
                loopback address say /64 being routable causes any
                security risk ? ​</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Please see the reference.  <br>
    <br>
    <blockquote type="cite"
cite="mid:CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">**** The
              phrase "only has local significance" suggests that these
              SIDs are<br>
              **** not routable. But later on there is a suggestion that
              they are<br>
              **** routable, or at least that they might be.<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​Again
                SIDs are not routable and they have only local
                significance - true. ​They are prepended to say loopback
                address to form IPv6 SID. </div>
              <br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">**** So
              there are a number of options:<br>
              **** - not routable<br>
              **** - globally routable<br>
              **** - routable only within egress AS<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​This
                is referring to routability of SID ... not right. SID
                does not need to be routable. What prefix they are part
                of may be routable. ​​</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Just replace my use of the term "SID" with the longer term "the IPv6
    address of which the SID is a part".<br>
    <br>
    <blockquote type="cite"
cite="mid:CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> <br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">   and
              the BGP ingress device receiving this route<br>
                 MAY choose to encapsulate or insert an SRv6 SRH, second
              it indicates<br>
                 the value of the SID to include in the SRH
              encapsulation.  For L3VPN,<br>
                 only a single SRv6-VPN SID MAY be necessary.<br>
              <br>
              **** I don't understand the phrase "only a single SRv6-VPN
              SID MAY be<br>
              **** necessary".<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​Analogy
                to basic L3VPN when you have VPN label and underlay LDP
                label. ​</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Still don't understand what is being said.<br>
    <br>
    <blockquote type="cite"
cite="mid:CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">   If
              the BGP speaker supports MPLS based<br>
                 L3VPN simultaneously, it MAY also populate the Label
              values in L3VPN<br>
                 route types and allow the BGP ingress device to decide
              which<br>
                 encapsulation to use.  If the BGP speaker does not
              support MPLS based<br>
                 L3VPN services the MPLS Labels in L3VPN route types
              MUST be set to<br>
                 IMPLICIT-NULL.<br>
              <br>
              **** Please provide a reference that specifies how you set
              the Label field<br>
              **** of a SAFI-4 or SAFI-128 route to "implicit null".  I
              don't recall any<br>
              **** such thing existing in RFC 3107, 4364, or 8277.<br>
            </blockquote>
            <div><br>
            </div>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​4364
                does not restrict what value of VPN label is used - does
                it ? I think this draft now right here defines ​how to
                read implicit-null being placed there :) It's not my
                idea though - so I will let real inventors to comment on
                it more. </div>
            </div>
            <div> <br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">**** If
              you mean "set to three" (the value defined in RFC 3032 to
              represent<br>
              **** "implicit null"), I don't think the SAFI-4/SAFI-128
              implementations<br>
              **** generally interpret the value three in that manner.<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​As
                mentioned I think it just is being defined here and now.
                ​</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I didn't see any mention of the numeric value to put in the label
    field of the NLRI.   <br>
    <br>
    <blockquote type="cite">or to define a new special or reserved label
      ​for that embedded signalling.</blockquote>
    <br>
    Some discussion of why this won't cause any backwards compatibility
    problems would be appropriate.<br>
    <br>
    <br>
    <blockquote type="cite"
cite="mid:CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
              **** I'm not really sure what you're trying to do here.
              There are at least<br>
              **** four cases to consider:<br>
              <br>
              **** 1. For the case where the backbone doesn't have MPLS,
              there is no harm<br>
              **** in saying "set the label to zero".<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​Really
                ? ​What does the backbone having or not having MPLS has
                to do with this ? Underlay forwarding does not matter
                and this is what I read as "backbone".</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    What I meant is that if it is known a priori that SRv6 is being used
    instead of MPLS, the label value obviously doesn't matter, because
    it will never be used.<br>
    <br>
    <blockquote type="cite"
cite="mid:CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small"> </div>
            </div>
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">**** 2.
              For the case where the backbone supports both MPLS and
              SRv6, and<br>
              **** some PEs support L3VPN both ways, while others
              support only MPLS-based<br>
              **** L3VPN, then a real label needs to be put in.<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​OK.​</div>
            </div>
            <div> <br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">**** 3.
              For the case where the backbone supports both MPLS and
              SRv6, but a<br>
              **** particular egress PE only supports SRv6, there needs
              to be some way to<br>
              **** instruct the ingress PEs to use SRv6 and not MPLS.
              Perhaps the<br>
              **** presence of the prefix-SID attribute with VPN-SID TLV
              is sufficient.<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​Perhaps
                not ... and this is exactly ​the case trying to be
                addressed. <br>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Why isn't the presence of the attribute sufficient in this case?<br>
    <br>
    <blockquote type="cite"
cite="mid:CA+b+ERmbqc+HDrHnhdUMYqPanyV513acTWo8La9v2hWZ7eo6ng@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">**** 4.
              For the case where the backbone supports both MPLS and
              SRv6, the<br>
              **** egress PE supports both for transit, but the egress
              PE only supports<br>
              **** SRv6 for L3VPN, the label in the SAFI-1/SAFI-128
              routes should be a<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div class="gmail_default"
                style="font-family:arial,helvetica,sans-serif;font-size:small">​Label
                in SAFI 1 ? ​</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Sorry, I meant SAFI-4.  Actually, only SAFI-128 really matters in
    this context, I think.<br>
    <br>
    <br>
  </body>
</html>

--------------54A25299DC12F9DDE693C821--