Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input

From: [email-masked]
Date: Mon, 26 Sep 2011 11:10:42 +0800

Hi Rajiv,
I think it is reasonable, but would be preferred to add "why". If we don't 
have this restriction, the peer LSR which may not enable LDPv6 would 
receive IPv6 FEC that it may not process. Even both LSRs are IPv6 enabled, 
if there is no IPv6 hello adjacency, IPv6 FEC advertising would not make 
LDP-based IPv6 LSP work.

I have additional comment for the text of section 6.1:
     - An LSR should prefer the LDP/TCP connection over IPv6 for a new
        LDP session with a remote LSR, if it has both IPv4 and IPv6
        hello adjacencies for the same LDP Identifier (over a dual-
        stack interface, or two or more single-stack IPv4 and IPv6
        interfaces). This applies to the section 2.5.2 of RFC5036.
     - An LSR should prefer the LDP/TCP connection over IPv6 for a new
        LDP session with a remote LSR, if they attempted two TCP
        connections using IPv4 and IPv6 transport addresses
        simultaneously.
Such kind of preferrance would make operators a bit hard to predict the 
TCP connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and 
IPv4 TCP is established. Then LDPv6 is enabled between LSR1 and LSR2, and 
IPv4 TCP is till kept. Some day, LSR1 and LSR2 are rebooted, but the 
session would be changed to IPv6 which is different with the previous. 
That means the network results would be different after rebooting. Would 
be better to add a note here to let everyone know that.

Regards
Lizhong

> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 24 Sep 2011 10:28:48 -0400
> From: "Mallette, Edwin" <[email-masked]>
> To: "Rajiv Asati (rajiva)" <[email-masked]>, "[email-masked]"
>    <[email-masked]>
> Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
> Rajiv, my response is in-line.
> 
> On 9/22/11 4:52 PM, "Rajiv Asati (rajiva)" <[email-masked]> wrote:
> 
> >While this document passed the WGLC without any comments, we wanted to
> >bring up an issue to seek your feedback.
> >
> >The issue is that the current LDP spec rfc5036 allows an LDP peer to
> >advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may
> >not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See figure 3
> >in section 1.1.1 of ldp-ipv6 document.
> >
> >While mpls-ldp-ipv6 section 7** addresses this issue (by checking for 
v6
> >hello adj, in line with existing 'targeted adj check for PW binding
> >advertisement'), we want to pose the following questions:
> >
> >(1) is this a reasonable issue to be fixed?
> [EJM] Yes!
> >
> >(2) is ldp-ipv6 document the right place to fix it?
> [EJM] It's certainly the most expedient.  It strikes me that the plan
> would be to "fix" this issue within LDP-IPv6 and then when RFC5036 is
> incremented, create a new ID which includes the LDP-IPV6 additions, 
along
> with the fix, within the updated LDP Specification.
> My 2c yes.
> >(3) is the solution highlighted in section 7 a reasonable solution, if
> >you answered yes to both 1 and 2?
> [EJM] Yes.
> >
> >You may answer simple yes/no to each Q, if you like.
> >
> >Cheers,
> >Rajiv
> >
> >
> >
> >
> >
> >*      Consequently, an LDP peer advertising IPv4 bindings to
> >       an LDP IPv6 only peer, which doesn't have IPv4 any more
> >       (out in the future, of course).
> >
> >
> >**
> >7. Label Distribution
> >
> >   This document specifies that an LSR should advertise and receive
> >   both IPv4 and IPv6 label bindings from and to the peer, only if it
> >   has valid IPv4 and IPv6 Hello Adjacencies for that peer, as
> >   specified in section 6.2.
> >
> >   This means that the LSR must not advertise any IPv6 label bindings
> >   to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency
> >   existed for that peer (and vice versa).
> >_______________________________________________
> >mpls mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/mpls
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 26 Sep 2011 09:50:15 -0500

Hi Lizhong,

If I follow it right, then your response is 

1. yes
2. yes
3. yes

However, you would like to add some text for further clarity into the
rationale. Did I sum up right?

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, September 25, 2011 11:11 PM
> To: [email-masked]; Rajiv Asati (rajiva)
> Cc: [email-masked]
receive
> IPv6 FEC that it may not process. Even both LSRs are IPv6 enabled, if
there is
> no IPv6 hello adjacency, IPv6 FEC advertising would not make LDP-based
IPv6
> LSP work.
> Such kind of preferrance would make operators a bit hard to predict
the TCP
> connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and
IPv4 TCP
> is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4
TCP is
> till kept. Some day, LSR1 and LSR2 are rebooted, but the session would
be
> changed to IPv6 which is different with the previous. That means the
network
> results would be different after rebooting. Would be better to add a
note here
> to let everyone know that.
> 
> Regards
> Lizhong
> 
> 
> >
> >
> > >While mpls-ldp-ipv6 section 7** addresses this issue (by checking
for v6
along
> ZTE Information Security Notice: The information contained in this
mail is
> solely property of the sender's organization. This mail communication
is
> confidential. Recipients named above are obligated to maintain secrecy
and are
> not permitted to disclose the contents of this communication to
others.
> This email and any files transmitted with it are confidential and
intended
> solely for the use of the individual or entity to whom they are
addressed. If
> you have received this email in error please notify the originator of
the
> message. Any views expressed in this message are those of the
individual
> sender.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 26 Sep 2011 10:03:30 -0500

Hi Lizhong,

Pls see inline,

the TCP
IPv4 TCP
TCP is
be
network
note here
> to let everyone know that.

Sure. And that is already covered in section 6.3 (Maintaining LDP
Sessions) in sufficient details.

Would you suggest any other add-ons?

Cheers,
Rajiv

receive
there is
IPv6
the TCP
IPv4 TCP
TCP is
be
network
note here
for v6
along
mail is
is
and are
others.
intended
addressed. If
the
individual

---

From: Lizhong Jin<[email-masked]>
Date: Tue, 27 Sep 2011 09:06:32 +0800

Hi Rajiv,
Suggest to add additional note in section 6.3 behind the first paragraph, 
may like below:
Note, if the previous LDP session is by IPv4, and IPv6 is added by 
enabling dual-stack or adding another IPv6 interface, when this LDP 
session is re-established by e.g, rebooting, the new LDP session would be 
changed to IPv6 which is different with the previous.

Cheers
Lizhong

---

From: Lizhong Jin<[email-masked]>
Date: Tue, 27 Sep 2011 09:09:04 +0800

Rajiv,
Correct, add some text to be rational. Thanks.

Lizhong