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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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]> 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" <mpls at ietf.org>, "mpls-chairs at tools.ietf.org"
> <mpls-chairs at tools.ietf.org>, Martin Vigoureux
> <martin.vigoureux at alcatel-lucent.com>,
> "draft-ietf-mpls-ldp-ipv6 at tools.ietf.org"
> <draft-ietf-mpls-ldp-ipv6 at 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).
> > 
> >This wglc ends Dec 20, 2013.
> > 
> >/Loa
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls