Re: [mpls] Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-framework-06: (with DISCUSS and COMMENT)

Yimin Shen <yshen@juniper.net> Wed, 31 July 2019 14:03 UTC

Return-Path: <yshen@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB3D1200F3; Wed, 31 Jul 2019 07:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptis-JVdFsfi; Wed, 31 Jul 2019 07:03:00 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A966E12017D; Wed, 31 Jul 2019 07:03:00 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6VE1qLN006451; Wed, 31 Jul 2019 07:02:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=dFgv4xY5f4bfBJF5dNBQ3YcWVsysMkNCxuZDxHrigQw=; b=ZnPDptX2bpiTbYjZEgcY9M8uNklpQiyaPxNkegFQWBKFgozVKc9eh42rFQpLfjt/MIj8 PzBWdI7XZ0SRZeYFlZ4cjRo1+IvWOH0JEhTTHXtxEjidDeEtIkH9wZSoTmE54QNcBN9R Ja5zHEvYz8PfRUcvD/oQxayWhDKUwybyVaJNj6TTpIjayMGfypys9namCN2UoXsn8eGs LMdrk2rC9vqco8cjwyvAvoha2Isyv8ctFrIJuF0IpkUh8YFXmw2jHfeGiaJA+zZZ+nLN nTfTeaRxSVTt7/dOrBCw4SMWkjwZR6kJFgdAQFki1pEifn+tLG3IB8HYfl1GR525JGkp 8g==
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2056.outbound.protection.outlook.com [104.47.32.56]) by mx0a-00273201.pphosted.com with ESMTP id 2u3ccrr03p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jul 2019 07:02:56 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TP5sfuZZz4XayyYooErXCd+YxcNZKKI+wsGDI9YaXVKqvmMBMyd3STE+MfrJXuVb5FDxwemOkauxDZqju6RY/ttmpSlvBA83MRNcF0osqXVcUuaW0fwXSZFhVJnqZ3xNZ9q8bgrZupoIzB9UdQjO4C1AyM83U8q32gPqyPrScJe+7q0th8pYh0Wxv1KxaxnLn+56j8zsXrF+CMgRJHv6TuiKOG8YPFZZKAHTFMEiqfY704jsTYadAb0r7q5q4vdwQRzYoNE+Gjd7sEW5y8e6my507ttFc+FNSy79GkShKOEC2DtJPRP/4sGK5qjhgag40KZVxvGyByHUUIVpVz2shA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dFgv4xY5f4bfBJF5dNBQ3YcWVsysMkNCxuZDxHrigQw=; b=JeWNpK5P4YASEkwkWky5q2EFAbPksu4Ur1NJwocswnrN9gos7zkWxPgWTb0BGo7j0kA+tJxaL9GMLB08wWNf6DRpelM9+/VHLTVyCWKu0ntfAphKje/IZVB47qcXNbQ9nLj6cnD3EA/4jTiXFnj7cAP9IqvUpyz5jJ7jWv2GrJxAhfLOVAxHX9H5uHPqvNhobQ7KZmgvE4PypNm5ICRKkMQI51Ges66QeUQNJYae+G3kI7XWJlewxXddVdemxmCE7ufL1Rj2LusYEcXSAfIh559msAl2Cm9gqX3cav+YBUQbdE9c45vhELifcxKPd2Yx8GabEMgk1ycBGg0pb8Mveg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=juniper.net;dmarc=pass action=none header.from=juniper.net;dkim=pass header.d=juniper.net;arc=none
Received: from BYAPR05MB5256.namprd05.prod.outlook.com (20.177.231.94) by BYAPR05MB6376.namprd05.prod.outlook.com (20.178.232.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.9; Wed, 31 Jul 2019 14:02:52 +0000
Received: from BYAPR05MB5256.namprd05.prod.outlook.com ([fe80::1436:2b4c:4af6:6f07]) by BYAPR05MB5256.namprd05.prod.outlook.com ([fe80::1436:2b4c:4af6:6f07%3]) with mapi id 15.20.2136.010; Wed, 31 Jul 2019 14:02:52 +0000
From: Yimin Shen <yshen@juniper.net>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-mpls-egress-protection-framework@ietf.org" <draft-ietf-mpls-egress-protection-framework@ietf.org>, Loa Andersson <loa@pi.nu>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-framework-06: (with DISCUSS and COMMENT)
Thread-Index: AQHVNpIdMylsKTiOdUiLwxWif3+RsKbGw8aAgBIPxwCAAmMcgIAIP9qAgAEqlYA=
Date: Wed, 31 Jul 2019 14:02:52 +0000
Message-ID: <E7BF94E1-48A4-468A-8581-D56B19B670AD@juniper.net>
References: <156270292067.15831.1558464118600381453.idtracker@ietfa.amsl.com> <F0304867-E97D-48EB-AC7D-525E84AE4199@juniper.net> <359EC4B99E040048A7131E0F4E113AFC01B33E2B56@marchand> <545CD971-1B38-47DA-85D9-A59C30297108@juniper.net> <359EC4B99E040048A7131E0F4E113AFC01B33F083B@marchand>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33F083B@marchand>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.c.190715
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4a363912-2cd6-41c9-bae3-08d715bfc7b4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB6376;
x-ms-traffictypediagnostic: BYAPR05MB6376:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR05MB6376DDFBAEE21D4287A3E2DFBDDF0@BYAPR05MB6376.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5516;
x-forefront-prvs: 011579F31F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(136003)(366004)(376002)(346002)(199004)(189003)(13464003)(476003)(486006)(66446008)(66946007)(4326008)(66556008)(2616005)(66476007)(64756008)(36756003)(71200400001)(446003)(6246003)(11346002)(71190400001)(256004)(14444005)(19627235002)(86362001)(66066001)(58126008)(478600001)(54906003)(68736007)(316002)(110136005)(6512007)(6306002)(66574012)(14454004)(6116002)(76116006)(229853002)(3846002)(5660300002)(8936002)(8676002)(81156014)(81166006)(30864003)(99286004)(305945005)(2906002)(33656002)(102836004)(53936002)(26005)(966005)(7736002)(6486002)(6506007)(25786009)(6436002)(186003)(76176011)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6376; H:BYAPR05MB5256.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: oAJFNNI8jviE7s3p2VLY8FKQv/RnYSgCAJ0sZRD4lqfl4G+SgSZaxUjKKgSNKuLv8OY27ytx6SjLiw/tOANHj8NSBVRDtfh6owUua+GsiB2Vd1yHV1Z5gvfE+aZtD4nbFqY0ReAAph+9Ada0SfRQ7N34xXOo2XxRSs/6QMJqkyepydEUxMbFwO/QC3qq66qpMUCJ14EZdEAfCxA5/mdjGJUhr30EsrZQckRH6YLLxqQcDTSjVeUaQimIqDz/MuAgWd2hbux+PIMC8fa5f9+bBXGkoB5b6OMNT8m/E701GDPdY0m1G8YDFT8yKVFjVLpKEz20wka/vFSnlKJ2lxMnmHNzig2EYmtg+yZ0C4AznCMdyIFbmew8ZcsYGW4iaG16qrNrGiGSiIjsiCUnD9M6ctzSkX8bBGYj8b0Yy1gDiuA=
Content-Type: text/plain; charset="utf-8"
Content-ID: <E4AC52FC41567741B37A647549311C8C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a363912-2cd6-41c9-bae3-08d715bfc7b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 14:02:52.7922 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yshen@juniper.net
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6376
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-31_06:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907310142
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/lAc8xcS-Yiuk8J6vw9LGSNhc8D0>
Subject: Re: [mpls] Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-framework-06: (with DISCUSS and COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 14:03:04 -0000

Hi Roman,

We have uploaded a new version (07) of this draft. It has addressed the comments and incorporated the suggestions which we received from IESG review.

https://datatracker.ietf.org/doc/draft-ietf-mpls-egress-protection-framework/

Thanks again for all the kind reviews !

-- Yimin Shen



On 7/30/19, 12:14 PM, "Roman Danyliw" <rdd@cert.org> wrote:

    Hi Yimin!
    
    This revised addresses both of my discuss items.  Thank you synthesizing it.
    
    Regards,
    Roman
    
    > -----Original Message-----
    > From: Yimin Shen [mailto:yshen@juniper.net]
    > Sent: Thursday, July 25, 2019 10:16 AM
    > To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
    > Cc: draft-ietf-mpls-egress-protection-framework@ietf.org; Loa Andersson
    > <loa@pi.nu>nu>; mpls-chairs@ietf.org; mpls@ietf.org
    > Subject: Re: Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-
    > framework-06: (with DISCUSS and COMMENT)
    > 
    > Hi Roman,
    > 
    > Thanks again for your detailed review and comments! Please see below for
    > the revised text which has incorporated your suggestions.
    > 
    > In particular, for your comment on the "In one possible case ..." about a CE-
    > launched attack, this paragraph was added to address a comment from
    > another view.  The case is not associated tightly with egress protection, but
    > we thought it would be worth mentioning it, with a clarification that [1] such
    > kind of attacks are not introduced by egress protection;  [2] they can happen
    > regardless of egress protection; [3] there are existing mechanisms to deal
    > with them. We have clarified more in the new text below.
    > 
    > Please let us know if you have more comment, or can resolve the discussion.
    > Thanks again!
    > 
    > ----
    > 
    > 12.  Security Considerations
    > 
    >    The framework in this document involves rerouting traffic around an
    >    egress node or link failure, via a bypass path from a PLR to a
    >    protector, and ultimately to a backup egress router.
    >    The forwarding performed by the routers in the data plane
    >    is anticipated, as part of the planning of egress protection.
    > 
    >    Control plane protocols MAY be used to facilitate the provisioning of
    >    the egress protection on the routers.  In particular, the framework requires
    >    a service label distribution protocol between an egress router and a
    > protector
    >    over a secure session.  The security properties of this provisioning and label
    >    distribution depend entirely on the underlying protocol chosen to
    > implement
    >    these activities . Their associated security considerations apply. This
    > framework
    >    introduces no new security requirements or guarantees relative to these
    > activities.
    > 
    >    Also, the PLR, protector, and backup egress router are located close
    >    to the protected egress router, and normally in the same
    >    administrative domain.  If they are not in the same administrative
    >    domain, a certain level of trust MUST be established between them in
    >    order for the protocols to run securely across the domain
    >    boundary.  The basis of this trust is the security model of the protocols
    >    (as described above), and further security considerations for inter-domain
    >    scenarios should be addressed by the protocols as a common requirement.
    > 
    >    Security attacks may sometimes come from a customer domain.
    >    Such kind of attacks are not introduced by the framework
    >    in this document, and may occur regardless of the existence of
    >    egress protection. In one possible case, the egress link between an egress
    >    router and a CE could become a point of attack.  An attacker that gains
    > control
    >    of the CE might use it to simulate link failures and trigger constant
    >    and cascading activities in the network. If egress link protection is
    >    in place, egress link protection activities may also be triggered.
    >    As a general solution to defeat the attack, a damping mechanism
    >    SHOULD be used by the egress router to promptly
    >    suppress the services associated with the link or CE.  The egress
    >    router would stop advertising the services, essentially detaching
    >    them from the network and eliminating the effect of the simulated
    >    link failures.
    > 
    >    From the above perspectives, this framework does not introduce any
    >    new security threat to networks.
    > 
    > 
    > Thanks,
    > 
    > -- Yimin
    > 
    > 
    > 
    > 
    > 
    > 
    > On 7/23/19, 5:48 PM, "Roman Danyliw" <rdd@cert.org> wrote:
    > 
    >     Hi Yimin!
    > 
    >     > -----Original Message-----
    >     > From: Yimin Shen [mailto:yshen@juniper.net]
    >     > Sent: Friday, July 12, 2019 9:59 AM
    >     > To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
    >     > Cc: draft-ietf-mpls-egress-protection-framework@ietf.org; Loa Andersson
    >     > <loa@pi.nu>nu>; mpls-chairs@ietf.org; mpls@ietf.org
    >     > Subject: Re: Roman Danyliw's Discuss on draft-ietf-mpls-egress-
    > protection-
    >     > framework-06: (with DISCUSS and COMMENT)
    >     >
    >     > Hi Roman,
    >     >
    >     > Thanks very much for your review!
    >     >
    >     > Please see inline below for the changes we plan to make, and let us
    > know if
    >     > they are sufficient to resolve this discussion.
    >     >
    >     > Thanks,
    >     >
    >     > -- Yimin
    >     >
    >     > On 7/9/19, 4:08 PM, "Roman Danyliw via Datatracker"
    > <noreply@ietf.org>
    >     > wrote:
    >     >
    >     >     Roman Danyliw has entered the following ballot position for
    >     >     draft-ietf-mpls-egress-protection-framework-06: Discuss
    >     >
    >     >     When responding, please keep the subject line intact and reply to all
    >     >     email addresses included in the To and CC lines. (Feel free to cut this
    >     >     introductory paragraph, however.)
    >     >
    >     >
    >     >     Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
    >     > 3A__www.ietf.org_iesg_statement_discuss-
    >     > 2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
    >     > ndb3voDTXcWzoCI&r=2-
    >     >
    > nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=X9HyscF98j23N9gok
    >     >
    > dZCH9iEG0x_yrqq45haf_Mseus&s=3coZyWz9ap2Zfz4Y4g17fpbs5CyIQnK3Oe
    >     > cHx5BBXDE&e=
    >     >     for more information about IESG DISCUSS and COMMENT positions.
    >     >
    >     >
    >     >     The document, along with other ballot positions, can be found here:
    >     >     https://urldefense.proofpoint.com/v2/url?u=https-
    >     > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmpls-2Degress-
    > 2Dprotection-
    >     > 2Dframework_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
    >     > ndb3voDTXcWzoCI&r=2-
    >     >
    > nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=X9HyscF98j23N9gok
    >     >
    > dZCH9iEG0x_yrqq45haf_Mseus&s=6r9KW52kfdX1MRN_rfpiU1ILMNibzZh7u
    >     > b-VcoEKCQM&e=
    >     >
    >     >
    >     >
    >     >     ----------------------------------------------------------------------
    >     >     DISCUSS:
    >     >     ----------------------------------------------------------------------
    >     >
    >     >     A few questions about the Security Considerations:
    >     >
    >     >     (1) Section 11.  I appreciate that this a framework document that is
    > trying
    >     > to
    >     >     be generic.  Section 4 (and others) seem to lay out generic
    > requirements.
    >     >     However, this Security Considerations section is both vague on the
    >     > protocol
    >     >     choices (understandable) and the security services/properties they
    > would
    >     > have
    >     >     (the gap).   For example, “The general security measures of the
    > protocols
    >     >     SHOULD be used whenever applicable.” and “The available security
    >     > measures of
    >     >     the chosen protocol SHOULD be used to achieve a secured session
    >     > between the two
    >     >     routers.”  Some discussion of what a “secured session” would look like
    >     > would be
    >     >     helpful.
    >     >
    >     > [yshen] We could say that “The general security measures of the
    > protocols
    >     > SHOULD be used whenever needed and applicable, e.g. an
    > authentication
    >     > method or password. The framework does not require additional
    > security
    >     > measures for these protocols, other than what they already have."
    > 
    >     Thanks.  I think I better understand what is meant with the text.  Correct
    > me here, but it seems like you're saying that the security of establishing the
    > egress protection behavior rests on the underlying security properties of the
    > control plane/service label distribution protocols used to establish the it.
    > Likewise, I'm assuming that the alluded alternative to using a control plan
    > protocol (since the current text uses a MAY) is manual configuration.
    > 
    >     If my understanding is correct, might I suggest the following to make it
    > clearer on what is in and out of scope:
    > 
    >     OLD:
    >        Some control
    >        plane protocols MAY be used between these routers to facilitate the
    >        establishment of egress protection.  The general security measures of
    >        the protocols SHOULD be used whenever applicable.  In particular, the
    >        framework requires a service label distribution protocol between an
    >        egress router and a protector.  The security measures of the chosen
    >        protocol SHOULD be used to achieve a secured session between the two
    >        routers.
    > 
    >     NEW
    >     Control plane protocols MAY be used to facilitate the provisioning of this
    > egress protection on the routers.  In particular, this framework requires a
    > service label distribution protocol between an egress router and a protector
    > over secure session.  The security properties of this provisioning and label
    > distribution depend entirely on the underlying protocol chosen to
    > implement these activities .  Their associated security considerations apply.
    > This framework introduces no new security requirements or guarantees
    > relative to these activities.
    > 
    >     >     (2) Section 11.  What are the elements and enablers of “a certain level
    > of
    >     >     trust … [being] established between the routers for the protocols to
    > run
    >     >     securely”?
    >     >
    >     > [yshen] Here, the "trust" simply means that, first the routers are allowed
    > to
    >     > run the protocols between them; and second, the protocols are run
    > securely
    >     > like the above. Again, this should be the same manner as that of an
    > inter-AS
    >     > protocols.
    > 
    >     Understood.  I believe we need a more detailed statement that (1) the
    > basis of this trust is the security model of the selected protocols (like above);
    > and a (paragraphing): "there security considerations for inter-AS protocols
    > <as defined here> and they should be addressed by the implemented
    > protocol".
    > 
    >     Finally, given what you've explained about the first two paragraphs, the
    > second from last paragraph, "In one possible case ...",  seems to actually
    > discuss a security issues relative to this framework.  Hence, I don't
    > understand the basis of new last paragraph "From the above perspective,
    > this framework doesn't introduce any new security threats to the network".
    > 
    >     >     ----------------------------------------------------------------------
    >     >     COMMENT:
    >     >     ----------------------------------------------------------------------
    >     >
    >     >     (3) Section 4.  Per “The framework MUST consider minimizing
    > disruption
    >     > during
    >     >     deployment”, why is this MUST only to _consider_ minimizing rather
    > than
    >     >     actually minimizing the disruption?
    >     >
    >     > [yshen] Will change this to "This framework must minimize disruption
    > ...".
    >     > Also pointed out by some other viewers, the normative terms
    >     > MAY/SHOULD/MUST are not suitable for this "consideration" section.
    > Will
    >     > replace them with may/should/must.
    > 
    >     Thanks.
    > 
    >     >     (4) Section 5.7.  Per “a globally unique IPv4/v6 address  is assigned to a
    >     >     protected egress {E, P} as the identifier of the protected egress {E, P}”, I
    >     >     recommend being explicit and saying and s/IPv4\\v6/IPv4 or v6/
    >     >
    >     > [yshen] Will fix this.
    > 
    >     Thanks.
    > 
    >     >     (5) Section 9.  I’m missing something obvious -- what is a “label table
    >     >     pe2.mpls”?
    >     >
    >     > [yshen] I think you are talking about the example in section 10. As it
    > specifies
    >     > in the first paragraph, " On PE3, ....., and a table pe2.mpls is created to
    >     > represent PE2's label space."
    > 
    >     We're talking about the same thing, the section titled "Example: Layer-3
    > VPN egress protection" (it was section 9 in -05 and section 10 in -05).  I
    > understand now.  Thank you for the clarification.
    > 
    >     Roman
    > 
    > 
    >     >
    > 
    >