Re: [mpls] wg last call and IPR poll on draft-ietf-mpls-ldp-ipv6-07

["Aissaoui, Mustapha (Mustapha)" <[e-mail]>]

Hi Loa,
I raised a couple of major issues with this draft and proposed a solution to address them. I have discussed these at length with the authors on this mailing list but it does not seem we are making any progress to address it. 

I have summarized the issues below as well as a possible solution. Since thes issues cause backward compatibility with RFC 5036, I do not believe we can publish the draft in its current version.

Regards,
Mustapha.
=====================================================================================
Issues in draft-ietf-mpls-ldp-ipv6:

1. Current version of LDP IPv6 draft mandates maintaining a Hello adjacency for each of IPv4 and IPv6 over a dual-stack interface between two LSRs but will bootstrap a single LDP session (IPv4 or IPv6). RFC 5036 allows bootstrapping of an IPv6 session by an IPv6 Hello adjacency OR bootstrapping of an IPv4 LDP session by an IPv4 Hello Adjacency over the same IP interface. 
The proposal in this draft doubles number of Hello adjacencies and breaks backward compatibility with RFC 5036 for no gain. 

2. Current version of LDP IPv6 draft ties the FEC types resolved over a given interface to the type of adjacency. This violates RFC 5036 which allows any FEC type (unicast IPv4, unicast IPv6, mLDP p2mp FEC, PW FEC) over an interface regardless of the Hello adjacency is IPv4 or IPv6. A Hello adjacency over a link is an assertion that a link is associated with the LDP session with the peer, meaning FECs exchanged over the session can be programmed over those links, and nothing else. The control of which FEC type is resolved over which interface is controlled via LDP capability and/or LDP FEC policies.

3. There is no need to maintain two link Hello adjacencies over the same interface for resolving an IPv4 or an IPv6 FEC. We just published a draft to specify LDP adjacency capability negotiation. This is the correct way to control which FECs can be resolved to a link such that we can keep IPv6 and IPv4 FEC resolution compatible with RFC 5036 in the case of dual-stack interfaces:
http://www.ietf.org/id/draft-pdutta-mpls-ldp-adj-capability-00.txt

=====================================================================================

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Loa Andersson
Sent: Monday, June 11, 2012 2:21 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [mpls] wg last call and IPR poll on draft-ietf-mpls-ldp-ipv6-07

Working Group,

this is to start a one week working group last call on draft-ietf-mpls-ldp-ipv6-07.

Bckground - the draft was passed working group last call in August last year, and it should from that perspective be OK to request publication.

However;

- it is a bit too long ago
- after the wg last call a discussion, that did not really cause any
   changes to the draft, that generated great interest.
   The background was that for the 32-bit LSR-id an routeable IPv4
   address has often been used in IPv4 networks. Thre were interest of
   using an routeabel  IPv6 address for LSR-id in IPv6 networks.
   It was decided not to go down this path, since it would have huge
   impact on the LDP protocol itself and all the HW implementations.

This working group last call is limited to the changes between version
-06 and -07.

Also since this draft was through wg last call before we explicitly started to poll for IPRs on our draft, we need to do that now.

Listed authors need to make an explicit statement to the working group and working group chairs that all the IPRs they now of has been disclosed or that they are not aware of any IPRs

Other working group members that har aware of IPRs should state so on the working group mailing list.

This working group last call and IPR poll ends June 18th, 2012.

/Loa
for the mpls wg co-chairs


-- 


Loa Andersson                         email: [e-mail]
Sr Strategy and Standards Manager            [e-mail]
Ericsson Inc                          phone: [phone]
                                              [phone] _______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls