Re: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6

[Qin Wu <[e-mail]>]

Hi, Carlos:
Thank for your clarification and proposed changes.
Your proposed changes look good to me.

Regards!
-Qin
From: Carlos Pignataro (cpignata) [mailto:[e-mail]]
Sent: Sunday, December 29, 2013 4:31 AM
To: Qin Wu
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6

Hi, Qin,

Thanks for the review! Please find some follow-up comments inline.

On Dec 16, 2013, at 2:38 AM, Qin Wu <[e-mail]<mailto:[e-mail]>> wrote:


Hi, all:
Here are my review to draft-ietf-mpls-ldp-ipv6.
1. Section 5.1 said:
"
Additionally, the link-local
IPv6 address MUST be used as the source IP address in IPv6 LDP Link
Hellos.

"
[Qin]: Why the link local multicast IPv6 address MUST be used as the source address?
Usually multicast IPv6 address is used as destination address for datagram, what am I missing?


The use of link-local IPv6 address as a source address for packets destined on-link is perfectly valid, and consistent with other protocols-for-IPv6. See for example RFC 5340, "OSPF for IPv6", Sections 2.5 and 4.1.3 (e.g., https://tools.ietf.org/html/rfc5340#section-2.5), or "VRRP for IPv4 and IPv6" Section 5.1.2.1 (i.e., http://tools.ietf.org/search/rfc5798#section-5.1.2.1).

Further, the document clearly says:

   Additionally, the link-local
   IPv6 address MUST be used as the source IP address in IPv6 LDP Link
   Hellos.

But also:

   The link-local IP addresses MUST NOT be used as the source or
   destination IPv6 addresses in extended discovery.



2. Section 5.1, last paragraph said:
"
Lastly, the IPv6 and IPv4 LDP Link Hellos must carry the same LDP
identifier (assuming per-platform label space usage).

"
s/must/MUST

OK


3. Section 5.2, 1st paragraph said:
"
Suffice to say, the extended discovery mechanism (defined in section
2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific
consideration, since the targeted LDP Hellos are sent to a pre-
configured (unicast) destination IPv6 address.
"

[Qin]; It is better to clarify the purpose of extended discovery mechanism? E.g., for
discovery of the LSR that is not directly connected in the LDP session?


It is not for "discovery of the LSR that is not directly connected in the LDP session". It is for "LDP discovery between non-directly connected LSRs."

But in any case, there is a pointer to the exact section of RFC 5036 where this is specified at the source. I would not want to try to re-define with a one-liner, since RFC 5036 is normative.


4. Section 6.1, said:
"
however, it does not specify the
   behavior of LDP if both IPv4 and IPv6 transport address objects
   (TLV) are sent in a Hello message or separate Hello messages.

"
[Qin]: It is better to distinct one Hello from two Hello, so suggest the following change
s/separate Hello/two separate Hello


"messages" in "or separate Hello messages" is plural, I do not see the need for this change.


5. Section 6.1,2nd bullet:
"
O An LSR SHOULD accept the Hello message that contains both IPv4
and IPv6 transport address optional objects, but MUST use only
the transport address whose address family is the same as that
of the IP packet carrying Hello.

"
[Qin]: Since LSR is not allowed to send a Hello containing both IPv4 and IPv6 transport address, why receiving LSR need to process such Hello message?


Because of the robustness principle.


6.Section 6.1, 5th bullet:
"
An LSR MUST prefer using global unicast IPv6 address for an LDP
session with a remote LSR, if it had to choose between global
unicast IPv6 address and unique-local or link-local IPv6
address (pertaining to the same LDP Identifier) for the
transport connection.
"
[Qin]: Can unique-local or link local IPv6 address be used in IPv6 transport address optional object? Is bullet 5 contradict with bullet 4?


No contradiction, bullet #4 is about "targeted hellos" only.


7. Section 6.2 said:
"
This document allows an LSR to maintain Rx-side Link Hello adjacency
for only one address family that has been used for the establishment
of the LDP session.
"
[Qin]: What does Rx-side mean?
Is there sender side Link Hello?

Rx-side means receive-side. This nomenclature is consistent with RFC 5036.

However, reading that sentence, I believe there is a small mistake, that this sentence did not incorporate an additional change suggested by Mustapha (missing "however"), and I will clarify that there can be one or two hello adjacencies maintained.

Thanks again for the review.

Net-net, these are the upcoming changes:
1. s/must/MUST/ in last para of Section 5.1., from Qin in this email.
2. Section 6.2 last sentence, from Mustapha+Carlos.
3. Additional fixes identified by Loa: add a pre-5378 clause to the Copyright notice, and fix idnits.

Thanks,

-- Carlos.



-----Original Message-----
From: Loa Andersson <loa at pi.nu>
Date: Wednesday, December 11, 2013 11:52 PM
To: "mpls at ietf.org<http://ietf.org/>" <mpls at ietf.org<http://ietf.org/>>, "mpls-chairs at tools.ietf.org<http://tools.ietf.org/>"
<mpls-chairs at tools.ietf.org<http://tools.ietf.org/>>, Martin Vigoureux
<martin.vigoureux at alcatel-lucent.com<http://alcatel-lucent.com/>>,
"draft-ietf-mpls-ldp-ipv6 at tools.ietf.org<http://tools.ietf.org/>"
<draft-ietf-mpls-ldp-ipv6 at tools.ietf.org<http://tools.ietf.org/>>
Subject: [mpls] Short wg last call on draft-ietf-mpls-ldp-ipv6

>Working Group,
>
>This is to start a one week working group last call on
>draft-ietf-mpls-ldp-ipv6-10
>
>We did a wglc on draft draft-ietf-mpls-ldp-ipv6 mid-2011. We had good
>comments and the document almost ready to go. At that point a discussion
>on the number of LDP session needed between a pair LSRs with both IPv4
>and IPv6 emerged, it has taken us quite a long time to resolve this.
>
>However, the author, wg chairs and people making the comments now agree
>that version -10 is resolve those comments.
>
>This working group last call is limited to the changes since the
>previous last call. A diff can be found at:
>
>http://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-ldp-ipv6-07&difftype=--ht
>ml&submit=Go%21&url2=draft-ietf-mpls-ldp-ipv6-10
>
>Please send you comments to the MPLS wg mailing list (mpls at ietf.org<http://ietf.org/>).
>
>This wglc ends Dec 20, 2013.
>
>/Loa
________________________________
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls