[mpls] Comment resolution on MPLS Identifiers draft

George Swallow <swallow@cisco.com> Thu, 03 March 2011 23:27 UTC

Return-Path: <swallow@cisco.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4F83A6872 for <mpls@core3.amsl.com>; Thu, 3 Mar 2011 15:27:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.9
X-Spam-Level:
X-Spam-Status: No, score=-109.9 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNwXvZLcKCJ0 for <mpls@core3.amsl.com>; Thu, 3 Mar 2011 15:27:46 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 893643A6816 for <mpls@ietf.org>; Thu, 3 Mar 2011 15:27:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=8439; q=dns/txt; s=iport; t=1299194935; x=1300404535; h=date:subject:from:to:message-id:mime-version; bh=GJ8CGv+1uK+vCArAmm2ieCAOHEpobRlqa2OcQBRP09M=; b=NPaxG9XkiLaff1VuvIU0+GfC7OASU5dtO/5tlezFi9vGnlRbiK0iEbQp A5XiRqokeLSkbFYoOSodIttFFBGAQkMw3J3b3JcatMRMJ+JSyv9Z/gDqr tpZ0RA1t1avhc1eqTS4/sEfWUYwf7Pd8jHzfXmR/bJ+6AToHXMtZ5uhny w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAEazb02tJV2Y/2dsb2JhbACCUKM6XXSiJZwShWEEhRqHEoNI
X-IronPort-AV: E=Sophos; i="4.62,260,1297036800"; d="scan'208,217"; a="222056727"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 03 Mar 2011 23:28:54 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p23NSsN7021614 for <mpls@ietf.org>; Thu, 3 Mar 2011 23:28:54 GMT
Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 17:28:54 -0600
Received: from 10.82.229.44 ([10.82.229.44]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Mar 2011 23:28:54 +0000
User-Agent: Microsoft-Entourage/12.28.0.101117
Date: Thu, 03 Mar 2011 18:28:56 -0500
From: George Swallow <swallow@cisco.com>
To: mpls@ietf.org
Message-ID: <C9958E68.BF6C%swallow@cisco.com>
Thread-Topic: Comment resolution on MPLS Identifiers draft
Thread-Index: AcvZ+sPJNvIFlhFEq0K5Gx1jsradxw==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3382021737_199398104"
X-OriginalArrivalTime: 03 Mar 2011 23:28:54.0194 (UTC) FILETIME=[C2B5D920:01CBD9FA]
Subject: [mpls] Comment resolution on MPLS Identifiers draft
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Thu, 03 Mar 2011 23:27:48 -0000

Addressed a comment from Mach Chen on the need for two LSP-IDs for
associated bi-directional LSPs.  Added a new section which allows for two
LSP-IDs in this case, as well as a mapping to RSVP-TE signaling.

Removed the automatic mapping of tunnel numbers to IF_IDs as this is
implementation specific.

Addressed the ITU comments as follows:


1.  Not accepted.  The sentence is correct as it is.  It does not say
    that the document defines all identifier nor does it mention LSPs,
    tunnels or connections.

2.  Accepted

3.  Accepted in principle - removed sentence.  Note that the TLV
    definitions are what actually define the order.

4.  Accepted

5.  Added the Operator ID.  However the divergent naming of endpoint
    was not added.  Such a move would add a great deal of complexity.
    Need to see clear market demand before adding.

6.  Accepted in principle - wording is diffent since some of the
    changes propose are to a direct quote from another RFC.

7.  The Global_ID is not an ASN.  A non-zero Global_ID MUST be derived
    from an ASN owned by the operator.  In a node running both MPLS-TP
    and BGP the ASN and the Global_ID could have the same value.  But
    the ASN could be another ASN also owned by the operator.

8.  Accepted

9.  Accepted with wording changes.  In particular the comment is
    addressed in a new paragraph immediately after the paragraph
    where the comment was made.

10. Accepted

11. Accepted with wording changed.

12. Accepted

13. Accepted

14. Accepted in principle.  The comment was addressed by making a
    reference to hierarchical tunnels in the last paragraph of section
    4.

15. Accepted

16. Accepted

17, 18. Paragraph rewritten for clarification.

19. Accepted

20. Per comment 26, this text was not moved.

21. Accepted but used East/West instead of A/Z

22. This has been stable text for over a year and half.  We see no
    point in changing it now.

23. Type-o fixed

24. This is the naming for co-routed bi-directional tunnels.  See new
    text in section xx for associated bi-directional

25. This is an artifact cause by the type-o which was addressed per comment
23.

26. Accepted.  Added text on associated bi-directional.

27. Type-o fixed

28. Type-o fixed

29. Accepted, text added.

30. Accepted but used East/West instead of A/Z

31. Not accepted.  The PW_ID is not unique to a node, but to a node
    pair.  To automatically generate MEP_IDs in this case would
    require both node_ids and both global_ids for global uniqueness.
    Further, having another option just makes for more complication.

32. Accepted but used East/West instead of A/Z

33. The AGI is used in defining L2VPNs

34. Rather than incorporating the comment, the note was removed as it
    was not really appropriate for this document.

35. Not accepted.  Believe the existing text is clear enough.  The
    MEP-ID is required and there are two defined.  This document does
    not specify usage.

36. Accepted with wording changes - new text is "where the Node_ID is
    the node in which the MEP is located and the AC_ID is the AC_ID of
    the Pseudowire at that node."

37. Changed name to Pseudowire Segments Endpoint ID or PW_SE_ID

38. Type-o fixed

39. Accepted