IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN
draft-ietf-l3vpn-mvpn-infra-addrs-05

[Ballot comment]
Editorial suggestion: In Section 2, items 2 through 4 please provide references to the place where these attributes were originally defined. I had some trouble tracking them down, and I'm still not sure if I found the authoritative specification for them.

[Ballot discuss]
Thank you for writing this. The document is fine, but it had one bug that I think you must fix, and another editorial issue which would be useful to fix. Here's the bug:

Section 3 says:

  To carry an IPv6
  address, an "IPv6 Address Specific Extended Community" [RFC5701], of
  type "VRF Route Import", must be used.  A codepoint for this type of
  extended community will be allocated by IANA.

This seems incorrect. IANA has already allocated codepoint 25 for the use of RFC 5701. Unless I'm missing something obvious, you should just strike the last sentence.

[Ballot comment]
From a very late review

- In a couple of places, the word "route" occurs where it would be clearer
  to say "NLRI"

- The paragraph on "VRF Route Import Extended Community" is misplaced, as it
  is an attribute of IP-VPN routes rather than of MCAST-VPN routes; this
  paragraph should probably be a top-level section of its own.

- That paragraph contains the term "IPv6 Address Specific Route Target" when
  it should say "IPv6 Extended Community". 

These issues have been resolved in the latest version, and WG and IETF LC completed.

Upon approval of this document, IANA understands that there is a single
action that needs to be completed.

In the IPv6 Address Specific Extended Community registry in the Border
Gateway Protocol (BGP) Extended Communities registry located at:

http://www.iana.org/assignments/bgp-extended-communities

a single new value will be registered as follows from the "transitive
communities" portion of the namespaceas follows:

Value: [ tbd ]
Name: VRF Route Import
Reference: [ RFC-to-be ] AND [ draft-ietf-l3vpn-2547bis-mcast-bgp-08 ]

IANA notes that the authors suggest assignment of the value 0x000b (to
correspond to the value that is already assigned for "VRF Route Import"
in the "IPv4 Address Specific Extended Community" registry).

IANA understands that this is the only action required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN) to Proposed Standard


The IESG has received a request from the Layer 3 Virtual Private Networks
WG (l3vpn) to consider the following document:
- 'IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast
  VPN'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


To provide Multicast VPN (MVPN) service, Provider Edge routers
originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN")
BGP routes; they also originate unicast VPN routes that carry MVPN-
specific attributes.  These routes encode addresses from the
customer's address space, as well as addresses from the provider's
address space.  These two address spaces are independent, and the
address family (IPv4 or IPv6) of the two spaces may or may not be the
same.  These routes always contain an "address family" field that
specifies whether the customer addresses are IPv4 addresses or
whether they are IPv6 addresses.  However, there is no field that
explicitly specifies the address family of the provider addresses.
To ensure interoperability, this document specifies that provider
IPv4 addresses are always encoded in these update messages as four-
octet addresses, and that the distinction between IPv4 and IPv6 is
signaled solely by the length of the address field.  Specific cases
are explained in detail.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-infra-addrs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-infra-addrs/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation from IESG Evaluation::External Party.
There were some late changes to this documnet that required it to go back to the WG for a new Last Call. The WGLC completed successfully and so I am about to issue a new IETF Llast Call

State changed to IESG Evaluation::External Party from IESG Evaluation::AD Followup.
This document had a number of changes other than those required to address the IESG evaluation. I have therefore requested a new WG Last Call.

[Ballot discuss]
The Gen-ART Review by Suresh Krishnan on 17-Jan-2011 asks a question
  that deserves a response: will this document update
  draft-ietf-l3vpn-2547bis-mcast-bgp-08, once it is published as an RFC?

[Ballot discuss]
For administrative reasons I am adopting Alexey Melnikov's Discuss.

The document begs for "Updates: RFC XYZW", I am just not sure what this RFC XYZW
needs to be. Maybe it would need to update multiple RFCs.

For example, when I read this text:

1.3. IPv4 and IPv6 Addresses in MCAST-VPN Routes

  [MVPN-BGP] defines a new set of BGP route types that are used by SPs
  to provide Multicast Virtual Private Network service to their
  customers.  These routes have a newly defined BGP NLRI, the "MCAST-
  VPN" NLRI.  MCAST-VPN NLRI is carried in the NLRI field of the
  MP_REACH_NLRI/MP_UNREACH_NLRI attributes defined in [BGP-MP].  The
  SAFI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute is used to
  identify the NLRI as being an MCAST-VPN NLRI.

  When the SAFI field of an MP_REACH_NLRI/MP_UNREACH_NLRI attribute has
  the "MCAST-VPN" value, the AFI field has two defined values: 1 and 2.
  AFI 1 indicates that any customer multicast addresses occurring in
  the MP_REACH_NLRI/MP_UNREACH_NLRI attribute are IPv4 addresses; AFI 2
  indicates that any such addresses are IPv6 addresses.

  However, some of the MCAST-VPN routes also contain addresses of PE
  routers in the SP network.  An SP with an IPv4 network may provide
  MVPN service for customers that use IPv6, and an SP with an IPv6
  network may provide MVPN service for customers that use IPv4.
  Therefore the address family of the PE addresses MUST NOT be inferred
  from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI
  attribute.

It looks to me that this document is fixing a deficiency in [MVPN-BGP] and/or
[BGP-MP]. Thus it looks like it should be Updating at least one of them.


As per reply from Eric Rosen: the document should use "Updates: [MVPN-BGP]"

[Ballot discuss]
The Gen-ART Review by Suresh Krishnan on 17-Jan-2011 asks a question
  that deserves a response: will this document update
  draft-ietf-l3vpn-2547bis-mcast-bgp-08, once it is published as an RFC?

[Ballot comment]
From a very late review

- In a couple of places, the word "route" occurs where it would be clearer
  to say "NLRI"

- The paragraph on "VRF Route Import Extended Community" is misplaced, as it
  is an attribute of IP-VPN routes rather than of MCAST-VPN routes; this
  paragraph should probably be a top-level section of its own.

- That paragraph contains the term "IPv6 Address Specific Route Target" when
  it should say "IPv6 Extended Community".

[Ballot comment]
I agree with Alexey's discuss that this document is probably missing a bunch of "updates" relationships.

Additionally, with regards to [MVPN-BGP], could some or maybe all of the content of this ID rolled into [MVPN-BGP]? (Since that isn't actually published yet?)

[Ballot comment]
I agree with Alexey's discuss that this document is probably missing a bunch of "updates" relationships.

Additionally, with regards to [MVPN-BGP], could some or maybe all of the content of this ID rolled into [MVPN-BGP]?

[Ballot discuss]
The document begs for "Updates: RFC XYZW", I am just not sure what this RFC XYZW needs to be. Maybe it would need to update multiple RFCs.

For example, when I read this text:

1.3. IPv4 and IPv6 Addresses in MCAST-VPN Routes

  [MVPN-BGP] defines a new set of BGP route types that are used by SPs
  to provide Multicast Virtual Private Network service to their
  customers.  These routes have a newly defined BGP NLRI, the "MCAST-
  VPN" NLRI.  MCAST-VPN NLRI is carried in the NLRI field of the
  MP_REACH_NLRI/MP_UNREACH_NLRI attributes defined in [BGP-MP].  The
  SAFI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute is used to
  identify the NLRI as being an MCAST-VPN NLRI.

  When the SAFI field of an MP_REACH_NLRI/MP_UNREACH_NLRI attribute has
  the "MCAST-VPN" value, the AFI field has two defined values: 1 and 2.
  AFI 1 indicates that any customer multicast addresses occurring in
  the MP_REACH_NLRI/MP_UNREACH_NLRI attribute are IPv4 addresses; AFI 2
  indicates that any such addresses are IPv6 addresses.

  However, some of the MCAST-VPN routes also contain addresses of PE
  routers in the SP network.  An SP with an IPv4 network may provide
  MVPN service for customers that use IPv6, and an SP with an IPv6
  network may provide MVPN service for customers that use IPv4.
  Therefore the address family of the PE addresses MUST NOT be inferred
  from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI
  attribute.

It looks to me that this document is fixing a deficiency in [MVPN-BGP] and/or [BGP-MP]. Thus it looks like it should be Updating at least one of them.


As per reply from Eric Rosen: the document should use "Updates: [MVPN-BGP]"

[Ballot discuss]
I am sorry for this lousy DISCUSS DISCUSS, but at the moment I can't be more clear than that.
The document begs for "Updates: RFC XYZW", I am just not sure what this RFC XYZW needs to be. Maybe it would need to update multiple RFCs.

For example, when I read this text:

1.3. IPv4 and IPv6 Addresses in MCAST-VPN Routes

  [MVPN-BGP] defines a new set of BGP route types that are used by SPs
  to provide Multicast Virtual Private Network service to their
  customers.  These routes have a newly defined BGP NLRI, the "MCAST-
  VPN" NLRI.  MCAST-VPN NLRI is carried in the NLRI field of the
  MP_REACH_NLRI/MP_UNREACH_NLRI attributes defined in [BGP-MP].  The
  SAFI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute is used to
  identify the NLRI as being an MCAST-VPN NLRI.

  When the SAFI field of an MP_REACH_NLRI/MP_UNREACH_NLRI attribute has
  the "MCAST-VPN" value, the AFI field has two defined values: 1 and 2.
  AFI 1 indicates that any customer multicast addresses occurring in
  the MP_REACH_NLRI/MP_UNREACH_NLRI attribute are IPv4 addresses; AFI 2
  indicates that any such addresses are IPv6 addresses.

  However, some of the MCAST-VPN routes also contain addresses of PE
  routers in the SP network.  An SP with an IPv4 network may provide
  MVPN service for customers that use IPv6, and an SP with an IPv6
  network may provide MVPN service for customers that use IPv4.
  Therefore the address family of the PE addresses MUST NOT be inferred
  from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI
  attribute.

It looks to me that this document is fixing a deficiency in [MVPN-BGP] and/or [BGP-MP]. Thus it looks like it should be Updating at least one of them.

Can you help me out to figure out which RFCs this document is updating and if it is not updating any, to clarify why not?

[Ballot discuss]
I am sorry for this lousy DISCUSS DISCUSS, but at the moment I can't be more clear than that.
The document begs for "Updates: RFC XYZW", I am just not sure what this RFC XYZW needs to be. Maybe it would need to update multiple RFCs.

Can you help me out to figure out which RFCs this document is updating and if it is not updating any, to clarify why not?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

To: IETF-Announce 
From: The IESG
Reply-to: ietf@ietf.org
CC:
Subject: Last Call: draft-ietf-l3vpn-mvpn-infra-addrs (IPv4 and IPv6 Infrastructure Addresses in Multicast-VPN Routes) to Proposed Standard

The IESG has received a request from the Layer 3 Virtual Private Networks
WG (l3vpn) to consider the following document:

- 'IPv4 and IPv6 Infrastructure Addresses in Multicast-VPN Routes '
    as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-07. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-infra-addrs-02.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=20417&rfc_flag=0

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Ben Niven-Jenkins is the Document Shepherd for draft-ietf-l3vpn-mvpn-infra-addrs. I have personally reviewed the -02 version of the document and believe that this version is ready for forwarding to the IESG for publication as a Standards Track RFC.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The -01 version of the document passed the L3VPN WG Last Call in November 2010, although we received no technical comments on the document during the Last Call a -02 version was produced which addressed some editorial nits. No outstanding comments exist.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns and no IPR disclosures have been filed.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There were no objections during the WG Last Call on the document, and the utility of this specification is straight-forward, as well as both obvious and intuitive.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No, not to my knowledge.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The idnits tool reports no issues. There are no MIB or other elements in the document that would warrant review. As such, I have no concerns here.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document splits it references into normative and informative. All normative references are either to published RFCs or to Internet-Drafts in the RFC-Editor's queue. There are no downward references.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The document contains an IANA Considerations section but contains no actions on IANA.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

No section of this document is written in a formal language.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

To provide Multicast VPN service, a provider edge router originates Multicast-VPN BGP routes. These routes encode addresses from the customer's address space as well as addresses from the provider's address space. The customer's address space may be either IPv4 or IPv6. Independently, the provider's address space may be either IPv4 or IPv6. The Multicast-VPN BGP routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies whether the provider addresses are IPv4 addresses or whether they are IPv6 addresses. To ensure interoperability, this document specifies that Multicast-VPN routes always encode provider IPv4 addresses as four-octet addresses, and that the distinction between an IPv4 address and an IPv6 address is signaled solely by the length of the address field.


Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

This document is a product of L3VPN WG. There were no technical comments on the document during the WG Last Call, which was completed in November 2010.

Document Quality
Are there existing implementations of the protocol?

I am aware of two existing implementations.

Have a significant number of vendors indicated their plan
to implement the specification?

I do not know. However there are already two implementations that I am aware of.

Are there any reviewers that merit special mention as
having done a thorough review, e.g., one that resulted in
important changes or a conclusion that the document had no
substantive issues?

Not to the best of my knowledge.

If there was a MIB Doctor, Media Type or other expert
review, what was its course (briefly)? In the case of a
Media Type review, on what date was the request posted?

No such review was conducted as it was not considered necessary.