Lizhong Jin | 1 Mar 01:57 2012
Picon

Re: Comments on draft-ietf-mpls-ldp-ipv6-06


Hi Mustapha,
I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong
 

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui <at> alcatel-lucent.com> wrote 2012/03/01 04:35:41:

> Hi Lizhong,
> I actually think that we would need to define a new one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6 network will not be possible. I cannot see that operators
> will start maintaining a mapping of some global non routable LSR-id
> value to an IPv6 loopback interface on each router in the network.
>  
> Mustapha.
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If
> necessary we could define a new format to allow the use of /128 IPv6addresses.
>  
> Mustapha.
>
> From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6
> FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the
> correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions
> for IPv4 and IPv6 as an option. Regarding the format definition in
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta <at> alcatel-lucent.com>
> > To: Vishwas Manral <vishwas.ietf <at> gmail.com>
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui <at> alcatel-lucent.com>,   "mpls <at> ietf.org"
> >    <mpls <at> ietf.org>
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C584046466ED224CA92C1BC3313B963E09EFE8D667 <at> INBANSXCHMBSA3.in.
> > alcatel-lucent.com>
> >    
> > Content-Type: text/plain; charset="us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id because
> > having separate link adjacencies does not really solved any problem.
> > Since hello adjacencies are associated with a link, still fate
> > sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would
> > only decide whether such a link is to be programmed for IPV4 or IPV6
> > egress traffic but I see it as overkill and unnecessary scalability impacts.
> >
> > Thanks,
> > Pranjal
> >
> --------------------------------------------------------
> 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.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Dutta, Pranjal K (Pranjal | 1 Mar 02:03 2012

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

Yes, I support that too. There would be network management issues with mapping of 4 byte LSR-ID to an IPV6 remote address.

Most of the implementations I know off usually maps 4 byte of the LSR-ID with a local ipv4 interface address in the system.

 

Thanks,

Pranjal

 

From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
Sent: Wednesday, February 29, 2012 4:57 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls <at> ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

 


Hi Mustapha,
I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong
 

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui <at> alcatel-lucent.com> wrote 2012/03/01 04:35:41:

> Hi Lizhong,

> I actually think that we would need to define a new one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6 network will not be possible. I cannot see that operators
> will start maintaining a mapping of some global non routable LSR-id
> value to an IPv6 loopback interface on each router in the network.

>  
> Mustapha.
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If
> necessary we could define a new format to allow the use of /128 IPv6addresses.

>  
> Mustapha.
>
> From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6
> FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the
> correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions
> for IPv4 and IPv6 as an option. Regarding the format definition in
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta <at> alcatel-lucent.com>
> > To: Vishwas Manral <vishwas.ietf <at> gmail.com>
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui <at> alcatel-lucent.com>,   "mpls <at> ietf.org"
> >    <mpls <at> ietf.org>
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C584046466ED224CA92C1BC3313B963E09EFE8D667 <at> INBANSXCHMBSA3.in.
> > alcatel-lucent.com>
> >    
> > Content-Type: text/plain; charset="us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id because
> > having separate link adjacencies does not really solved any problem.
> > Since hello adjacencies are associated with a link, still fate
> > sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would
> > only decide whether such a link is to be programmed for IPV4 or IPV6
> > egress traffic but I see it as overkill and unnecessary scalability impacts.
> >
> > Thanks,
> > Pranjal
> >

> --------------------------------------------------------
> 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.

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Vishwas Manral | 1 Mar 02:11 2012
Picon

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have come after last call are:

1. Allow for separation of sessions along with the adjacency.
2. Allow for an IPv6 based LSR-ID.

The second could lead to changes required in both OSPF and IS-IS, as well because the new LSR ID would then need to be exchanged. We could treat it as an enhancement instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta <at> alcatel-lucent.com> wrote:

Yes, I support that too. There would be network management issues with mapping of 4 byte LSR-ID to an IPV6 remote address.

Most of the implementations I know off usually maps 4 byte of the LSR-ID with a local ipv4 interface address in the system.

 

Thanks,

Pranjal

 

From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
Sent: Wednesday, February 29, 2012 4:57 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls <at> ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com


Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

 


Hi Mustapha,
I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong
 

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui <at> alcatel-lucent.com> wrote 2012/03/01 04:35:41:

> Hi Lizhong,

> I actually think that we would need to define a new one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6 network will not be possible. I cannot see that operators
> will start maintaining a mapping of some global non routable LSR-id
> value to an IPv6 loopback interface on each router in the network.

>  
> Mustapha.
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If
> necessary we could define a new format to allow the use of /128 IPv6addresses.

>  
> Mustapha.
>
> From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6
> FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the
> correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions
> for IPv4 and IPv6 as an option. Regarding the format definition in
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta <at> alcatel-lucent.com>
> > To: Vishwas Manral <vishwas.ietf <at> gmail.com>
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui <at> alcatel-lucent.com>,   "mpls <at> ietf.org"
> >    <mpls <at> ietf.org>
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C584046466ED224CA92C1BC3313B963E09EFE8D667 <at> INBANSXCHMBSA3.in.
> > alcatel-lucent.com>
> >    
> > Content-Type: text/plain; charset="us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id because
> > having separate link adjacencies does not really solved any problem.
> > Since hello adjacencies are associated with a link, still fate
> > sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would
> > only decide whether such a link is to be programmed for IPV4 or IPV6
> > egress traffic but I see it as overkill and unnecessary scalability impacts.
> >
> > Thanks,
> > Pranjal
> >

> --------------------------------------------------------
> 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.


_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Rajiv Asati (rajiva | 1 Mar 04:27 2012
Picon

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Mustapha, 

Thanks for the review of the document and the feedback. It is never too
late. :)
Sorry about the delay in getting back to you.

Please see inline,

> > below are comments on this draft. I realize this draft passed WG
last call but I
> think the issues are significant enough in my view. I apologize if
some of these
> comments were already raised on this mailing list.

Yes, they were discussed in the past and closed.

> > 1. Section 3 - LSP Mapping; second paragraph.
> > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring
to a
> loopback interface of the egress router, not any other interface. That
is why
> RFC 5036 explicitly states /32 for IPv4. In my view, we should
explicitly refer to
> /128 for IPv6.

No.

While it is a common practice to assign a host route to the loopback
interface, and it is a common practice to use loopback interface as the
next-hop, we must not assume the common practice to be the norm for the
protocol. In fact, there is NO technical argument against using the
non-host route on a loopback interface.

In fact, almost every implementation allows the next-hop to be a
non-host route, and I am aware of at least one implementation that
allows LDP to correctly resolve the next-hop when it uses a non-host
route.

> > 2. Section 3 - LSP Mapping; last Paragraph:
> > "
> > Additionally, it is desirable that a packet is forwarded to an LSP
of an egress
> router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches
with that of
> the LDP hello adjacency on the next-hop interface.
> > "
> > MA> RFC 5036 makes no tie, and there should not be, between the type
of
> resolved FEC and the adjacency to the next-hop. I think this statement
should be
> removed.

RFC5036 actually does make a tie in section 2.5.5 in the sense that if
hello adj ceases to exist on an interface, then LDP concludes the lack
of MPLS forwarding on that interface. So, if IPv6 hello adj failed, then
stop the IPv6 MPLS forwarding (i.e. LSPv6) on that int, and vice versa,
instead of blindly stopping MPLS forwarding altogether. That wouldn't
make sense. 

//
   when it receives a Hello that matches the adjacency.  If the timer
   expires without receipt of a matching Hello from the peer, LDP
   concludes that the peer no longer wishes to label switch using that
   label space for that link (or target, in the case of Targeted Hellos)
   or that the peer has failed.  The LSR then deletes the Hello
 //

> > 3. Section 4 - LDP identifiers; third paragraph:
> > "
> > This document qualifies the first sentence of last paragraph of
> >   Section 2.5.2 of [RFC5036] to be per address family and therefore
> >   updates that sentence to the following: "For a given address
family
> >   over which a Hello is sent, and a given label space, an LSR MUST
> >   advertise the same transport address." This rightly enables the
per-
> >   platform label space to be shared between IPv4 and IPv6.
> > "
> > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has
anything
> to do with the address family. It only requires that an LSR advertises
the same
> transport address in all Hello adjacencies that advertise the same
label space.

I agree. It doesn't have anything to do with the address family, but it
becomes restrictive when having to accommodate transport of two
different address families (IPv4 and IPv6). Pls see more details on this
later on.

> In fact the intent as explained in the second sentence of that same
paragraph
> was to make sure that if two LSRs are establishing multiple Hello
adjacencies
> that they play the same active/passive role for establishing the TCP
connection.
> >
> > In practice though, most implementations allow Hello adjacencies
over
> parallel links with different IPv4 transport addresses and it works
just fine. I
> think we should remove this restriction from RFC 5036 and not refer to
it in this
> draft.

That's not correct (and the implementation is in violation of RFC5036).

We had good discussion on this early on. In fact, we had an editor's
note on this in initial versions of this document to solicit discussion
on that.

The last para of section 2.5.2, as stated, would result in a particular
IP address (1.1.1.1, say) being encoded in the transport address in both
IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared
(which is what the WG agreed to during IETF 80), then it prohibits IPv6
hello from carrying IPv6 transport address (or IPv4 hello from carrying
IPv4 transport address). It would not make sense.

In other words, we wouldn't want IPv4 Hello to carry IPv6 transport
address and vice versa. It wouldn't make sense and would be incorrect.

That's why the change was needed.

> > 4. Section 5.1 - Basic Discovery mechanism
> > MA> I understand the need to send both IPv4 and IPv6 Hello messages
over a
> dual-stack interface since there could be both IPv4 and IPv6 LSRs on
the same
> subnet. However, this does not justify the need to maintain two
separate Hello
> ajacencies per peer. In practice, each router can send both IPv4 and
IPv6 hellos
> but only a single Hello adjacency must be allowed with each peer
(LSR-id, label-
> space} over a given interface, whichever came up first. Over a P2P
interface, it
> is up to the user to configure which adjacency they want to form which
means
> there is only a need to send one type of hello.

We thought so too, but we uncovered various corner cases in which this
becomes problematic, not to mention that the indeterminism it would
bring into the picture. The easiest was to maintain hello adj per
address-family per peer.

For ex, consider three LDP enabled interfaces between R1 and R2, where
two are dual-stack, whereas the 3rd is single-stack (v4). If they
maintain only single adj, then they would have hello adj of one
transport (v6, say) on dual-stack interfaces, and another transport (v4,
say) on 3rd interface. 
	
Hello adj is tightly coupled with the functional LDP peering. If (the
last) hello adj is lost, then LDP peering must be brought down.
Additionally, if hello adj is gone from an interface, then LDP should
prohibit MPLS forwarding from using that interface.

Another way to think about it is - if IPv4 stops functioning on an
interface, but IPv6 keeps functioning, then IPv6 MPLS forwarding should
not be penalized. And vice versa.

Having separate hello adj maintenance is much cleaner/simpler and
provides deterministic behavior.

Nonetheless, an implementation could choose to optimize, if needed, to
keep both address-family related info in a single adjacency structure,
but this is all implementation specific. :)

> > 5. Section 6.1 - Transport connection establishment "
> > 2. 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.
> > "
> > MA> This is not a new issue. If I am not mistaken, this can also
occur in RFC
> 5036 implementations if an LSR receives two optional IPv4 transport
address
> TLVs. RFC 506 does not say what to do with this and was left for
> implementations to handle. If we absolutely need to specify something,
maybe
> we should say only the first TLV in the Hello message is processed.

Good point, but this is a different problem. It is not about the
sequence (which was ok if IPv4 hellow as carrying two IPv4 transport
addresses).

The problem is that allowing IPv4 based "discovery" to suggest an IPv6
transport address is fundamentally a wrong approach, IMO. How would IPv4
know that IPv6 transport is even functional (and vice versa).  IPv4
based discovery should suggest IPv4 transport, and IPv6 based discovery
should suggest IPv6 transport.

> > 6. Section 6.1 - Transport connection establishment "
> > 7. 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.
> >
> > 8. 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.
> > "
> > MA> No need for all this if you enforce that only a single adjacency
is
> maintained to each peer over a dual-stack interface.

We need the address-family awareness in peer hello adjacency/s, whether
it is a kept in a single adj structure or not.

Loosing the AFI awareness leads up the other problems that I mentioned
earlier. 

> > 7. Section 7 - Label Distribution; First paragraph:
> > "
> > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as
> >   well as interface addresses via ADDRESS message) from/to the peer
> >   over an LDP session (using whatever transport), unless it has
valid
> >   IPv4 and IPv6 Hello Adjacencies for that peer, as specified in
> >   section 6.2.
> > "
> > MA> I do not agree that the advertisement of IPv6 label-FEC bindings
should
> depend on the existence of an IPv6 Hello adjacency. This is a very
narrow
> interpretation of RFC 5036.
> > The proper solution to this is to add an IPV6 LDP capability to
negotiate which
> FEC address family can be exchanged regardless if the Hello adjacency
is IPv4
> or IPv6. This is already done for multicast LDP (mLDP) FECs.

It is MAY. :)
It was changed to MAY based on the exhaustive discussion on mailing list
in 2011 for us to move forward. 

> > 8. Section 7 - Label Distribution; Fourth paragraph:
> > "
> > Additionally, to ensure backward compatibility (and interoperability
> > with IPv4-only LDP implementations), this document specifies that
> > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV
> containing FEC Elements of different address-family. In other words, a
FEC TLV
> in the label mapping message MUST contain the FEC Elements belonging
to the
> same address-family.
> > 2. An LSR MUST NOT send an Address message (or Address Withdraw
> message) with an Address List TLV containing IP addresses of different
address-
> family. In other words, an Address List TLV in the Address (or Address
> Withdraw) message MUST contain the addresses belonging to the same
> address-family..
> > "
> > MA> This is yet another narrow interpretation of RFC 5036. There is
no
> justification for such a restriction and certainly RFC 5036 does not
make it. A
> FEC TLV contains list of FEC Elements which are opaque. Each FEC
Element has
> its own Type, Length, Value and is self sufficient. Although
implementations
> don't mix and match FEC elements but they are designed to handle it.
Same
> applies to Address list  TLV.

We initially thought so too, until we discovered the following very
explicitly in RFC5036. This is a recipe for a disaster, if left
untreated. 

//
Section 3.5.5.1 -
If an LSR does not support the Address Family specified in the Address
List TLV, it SHOULD send an Unsupported Address Family Notification to
its LDP signaling an error and abort processing the message.

Section 3.4.1.1 -
If in decoding a FEC TLV an LSR encounters a FEC Element with an Address
Family it does not support, it SHOULD stop decoding the FEC TLV, abort
processing the message containing the TLV, and send an "Unsupported
Address Family" Notification message to its LDP peer signaling an error.
//

> > 9. Section 8 - LDP Identifiers and Next Hop Addresses
> > MA> I believe the need to handle duplicate interface addresses
received from
> two different peers is not a new issue. It needed to be handled in
existing IPv4
> based LDP implementations. Maybe the authors can specify why duplicate
link
> local addresses is any different.

Because it is native in IPv6 to allow for link-local addresses that IPv4
never allowed. 
So, what was an anomaly with IPv4 is now a standard behavior with IPv6,
hence, that verbiage.

> > 10. Section 9 - LDP TTL Security
> > "
> > This document also specifies that the LDP/TCP transport connection
> >   over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security
> >   Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP
> >   session peering established between the adjacent LSRs using Basic
> >   Discovery, by default.
> > "
> > MA> GTSM must be optional as explained in RFC 5082. This draft is
not
> defining a new protocol and as such it should remain optional as in
RFC 5036.

We posed the Q about GTSM being the default or not during IETF 80, and
there were 10-yes and 0-no (mostly from operators)
Pls see the minutes, 
http://www.ietf.org/proceedings/80/minutes/mpls.txt

Cheers,
Rajiv

> -----Original Message-----
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf
Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Monday, February 06, 2012 3:21 PM
> To: Shane Amante
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> 
> Hi Shane,
> LDP as defined in RFC 5036 can carry multiple FEC types within an LDP
session
> from a peer which is identified by the LDP identifier tuple {LSR-id,
label-space-
> id}. If two LSR nodes using the same LSR-id want to advertise two
different label
> spaces, then they must use two different Hello adjacencies and LDP
sessions for
> that. Also, if an implementation supports virtualization of LDP, then
a different
> LDP identifier altogether can be used to establish a separate LDP
session. Other
> than that, there is no relation between the type of adjacency and the
FEC which
> are carried. For example, the same LDP Hello Adjacency and LDP session
are
> used to carry unicast FECs, multicast FECs (mLDP), and PW FECs between
two
> directly connected peers.
> 
> As far as I know BGP is not very different. It offers the ability to
carry IPv4 NLRI
> over a IPv6 session and vice versa.
> 
> If what is required is to carry IPv6 FECs on an IPv6 session and IPv4
on an IPv4
> session between two LSRs,  then we should consider extending RFC 5036
to
> allow for two different LSR-id values sharing the same global label
space. This
> way, we can have separate Hello adjacency and LDP session and it is up
to the
> user to assign which FEC type is allowed on which LDP session. This is
a new
> work item but in my view much cleaner and backward compatible with RFC
> 5036 than to try to tie the address family to the type of Hello
adjacency.
> 
> By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate
Hello
> adjacency but a single shared LDP session. It is not exactly what you
are asking
> for.
> 
> Regards,
> Mustapha.
> 
> -----Original Message-----
> From: Shane Amante [mailto:shane <at> castlepoint.net]
> Sent: Friday, February 03, 2012 11:32 PM
> To: Aissaoui, Mustapha (Mustapha)
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> 
> Mustapha,
> 
> I am not an author, but I do want to provide some operational input on
some of
> your comments.  Specifically, I get the sense from several of your
comments --
> actually, moreso from #3 -- that you are opposed to maintaining
separate LDP
> Hello and/or Session Adjacencies: 1 for each address family.  (If my
impression
> is incorrect I apologize).
> 
> I actually *do* want to have separate LDP Hello and Session
adjacencies: one
> per address family, at least at this point in time. I'm concerned
about
> [operational] issues that may develop in, for example, v6 affecting
the
> exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one
more
> concrete example, 6man/v6ops are only right now working on improving
the
> robustness of IPv6 ND to DoS attacks. There are potentially other
areas where
> IPv6 will be hardened, as well. The bottom-line is I do not want
problems in v6
> to affect exchange of FEC's + labels for v4, or vice-versa. Also,
FWIW, there has
> already been a precedent here wrt BGP where there it maintains
separate
> neighbors/sessions for each address family, so why aren't we doing the
same
> thing for LDP?
> 
> Ultimately, having separate sessions over-the-wire is much more
intuitive to
> operators in lots of cases where they may expect that a configuration
change
> or bugs they /think/ are only going to affect one address family,
really do only
> affect one address family. Besides, LDP Hello & Sessions timers, when
set to
> default, are extremely relaxed (order of several seconds), so the
burden on
> implementations to maintain separate sessions should be miniscule.
> 
> IMO, I would prefer that the default be separate Hellos & Sessions
over the
> wire to avoid "fate sharing". Only when an operator chooses to
explicitly
> configure their device to have hellos and sessions share fate should
the device
> do so.
> 
> Just my $0.02,
> 
> -shane
> 
> 
> 
> On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote:
> > Dear authors,
> > below are comments on this draft. I realize this draft passed WG
last call but I
> think the issues are significant enough in my view. I apologize if
some of these
> comments were already raised on this mailing list.
> >
> > Regards,
> > Mustapha.
> >
> ================================================================
> ======
> > =================
> >
> > 1. Section 3 - LSP Mapping; second paragraph.
> > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring
to a
> loopback interface of the egress router, not any other interface. That
is why
> RFC 5036 explicitly states /32 for IPv4. In my view, we should
explicitly refer to
> /128 for IPv6.
> >
> >
> > 2. Section 3 - LSP Mapping; last Paragraph:
> > "
> > Additionally, it is desirable that a packet is forwarded to an LSP
of an egress
> router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches
with that of
> the LDP hello adjacency on the next-hop interface.
> > "
> > MA> RFC 5036 makes no tie, and there should not be, between the type
of
> resolved FEC and the adjacency to the next-hop. I think this statement
should be
> removed.
> >
> >
> > 3. Section 4 - LDP identifiers; third paragraph:
> > "
> > This document qualifies the first sentence of last paragraph of
> >   Section 2.5.2 of [RFC5036] to be per address family and therefore
> >   updates that sentence to the following: "For a given address
family
> >   over which a Hello is sent, and a given label space, an LSR MUST
> >   advertise the same transport address." This rightly enables the
per-
> >   platform label space to be shared between IPv4 and IPv6.
> > "
> > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has
anything
> to do with the address family. It only requires that an LSR advertises
the same
> transport address in all Hello adjacencies that advertise the same
label space.
> In fact the intent as explained in the second sentence of that same
paragraph
> was to make sure that if two LSRs are establishing multiple Hello
adjacencies
> that they play the same active/passive role for establishing the TCP
connection.
> >
> > In practice though, most implementations allow Hello adjacencies
over
> parallel links with different IPv4 transport addresses and it works
just fine. I
> think we should remove this restriction from RFC 5036 and not refer to
it in this
> draft.
> >
> >
> > 4. Section 5.1 - Basic Discovery mechanism
> > MA> I understand the need to send both IPv4 and IPv6 Hello messages
over a
> dual-stack interface since there could be both IPv4 and IPv6 LSRs on
the same
> subnet. However, this does not justify the need to maintain two
separate Hello
> ajacencies per peer. In practice, each router can send both IPv4 and
IPv6 hellos
> but only a single Hello adjacency must be allowed with each peer
(LSR-id, label-
> space} over a given interface, whichever came up first. Over a P2P
interface, it
> is up to the user to configure which adjacency they want to form which
means
> there is only a need to send one type of hello.
> >
> >
> > 5. Section 6.1 - Transport connection establishment "
> > 2. 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.
> > "
> > MA> This is not a new issue. If I am not mistaken, this can also
occur in RFC
> 5036 implementations if an LSR receives two optional IPv4 transport
address
> TLVs. RFC 506 does not say what to do with this and was left for
> implementations to handle. If we absolutely need to specify something,
maybe
> we should say only the first TLV in the Hello message is processed.
> >
> >
> > 6. Section 6.1 - Transport connection establishment "
> > 7. 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.
> >
> > 8. 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.
> > "
> > MA> No need for all this if you enforce that only a single adjacency
is
> maintained to each peer over a dual-stack interface.
> >
> >
> > 7. Section 7 - Label Distribution; First paragraph:
> > "
> > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as
> >   well as interface addresses via ADDRESS message) from/to the peer
> >   over an LDP session (using whatever transport), unless it has
valid
> >   IPv4 and IPv6 Hello Adjacencies for that peer, as specified in
> >   section 6.2.
> > "
> > MA> I do not agree that the advertisement of IPv6 label-FEC bindings
should
> depend on the existence of an IPv6 Hello adjacency. This is a very
narrow
> interpretation of RFC 5036.
> > The proper solution to this is to add an IPV6 LDP capability to
negotiate which
> FEC address family can be exchanged regardless if the Hello adjacency
is IPv4
> or IPv6. This is already done for multicast LDP (mLDP) FECs.
> >
> >
> > 8. Section 7 - Label Distribution; Fourth paragraph:
> > "
> > Additionally, to ensure backward compatibility (and interoperability
> > with IPv4-only LDP implementations), this document specifies that
> > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV
> containing FEC Elements of different address-family. In other words, a
FEC TLV
> in the label mapping message MUST contain the FEC Elements belonging
to the
> same address-family.
> > 2. An LSR MUST NOT send an Address message (or Address Withdraw
> message) with an Address List TLV containing IP addresses of different
address-
> family. In other words, an Address List TLV in the Address (or Address
> Withdraw) message MUST contain the addresses belonging to the same
> address-family..
> > "
> > MA> This is yet another narrow interpretation of RFC 5036. There is
no
> justification for such a restriction and certainly RFC 5036 does not
make it. A
> FEC TLV contains list of FEC Elements which are opaque. Each FEC
Element has
> its own Type, Length, Value and is self sufficient. Although
implementations
> don't mix and match FEC elements but they are designed to handle it.
Same
> applies to Address list  TLV.
> >
> >
> > 9. Section 8 - LDP Identifiers and Next Hop Addresses
> > MA> I believe the need to handle duplicate interface addresses
received from
> two different peers is not a new issue. It needed to be handled in
existing IPv4
> based LDP implementations. Maybe the authors can specify why duplicate
link
> local addresses is any different.
> >
> >
> > 10. Section 9 - LDP TTL Security
> > "
> > This document also specifies that the LDP/TCP transport connection
> >   over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security
> >   Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP
> >   session peering established between the adjacent LSRs using Basic
> >   Discovery, by default.
> > "
> > MA> GTSM must be optional as explained in RFC 5082. This draft is
not
> defining a new protocol and as such it should remain optional as in
RFC 5036.
> >
> >
> ================================================================
> ======
> > =================
> _______________________________________________
> > mpls mailing list
> > mpls <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Mark Tinka | 1 Mar 05:03 2012
Picon

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

On Thursday, March 01, 2012 11:27:56 AM Rajiv Asati (rajiva) 
wrote:

> Nonetheless, an implementation could choose to optimize,
> if needed, to keep both address-family related info in a
> single adjacency structure, but this is all
> implementation specific. :)

I agree, and as mentioned earlier, as an operator, I'd 
rather this isn't the default. If a default needs to be 
implemented by a vendor, then AF separation would be my 
preference.

However, I'd support including knobs to allow operators to 
consolidate, if they so wished.

Mark.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Kamran Raza | 1 Mar 05:39 2012
Picon

Re: Comments on draft-ietf-mpls-ldp-ipv6-06


Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/or route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and need not be routable, though most implementations currently populate it with /32 loopback address. Let’s not carry forward a wrong notion/usage.

Secondly, If there is a need to define new “LDP Identifier” in order to establish/maintain a separate session for IPv6 AF, this should be a protocol change — i.e. we should bump up LDP protocol version in LDP PDU header for this, and possibly define new format for “LDP Identifier” in the context of new LDP protocol version.

My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf <at> gmail.com> wrote:

Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have come after last call are:

1. Allow for separation of sessions along with the adjacency.
2. Allow for an IPv6 based LSR-ID.

The second could lead to changes required in both OSPF and IS-IS, as well because the new LSR ID would then need to be exchanged. We could treat it as an enhancement instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta <at> alcatel-lucent.com> wrote:
Yes, I support that too. There would be network management issues with mapping of 4 byte LSR-ID to an IPV6 remote address.
Most of the implementations I know off usually maps 4 byte of the LSR-ID with a local ipv4 interface address in the system.
 
Thanks,
Pranjal
 

From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
Sent: Wednesday, February 29, 2012 4:57 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls <at> ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com

Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
 

Hi Mustapha,
I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong
 

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui <at> alcatel-lucent.com> wrote 2012/03/01 04:35:41:

> Hi Lizhong,

> I actually think that we would need to define a new one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6 network will not be possible. I cannot see that operators
> will start maintaining a mapping of some global non routable LSR-id
> value to an IPv6 loopback interface on each router in the network.

>  
> Mustapha.
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If
> necessary we could define a new format to allow the use of /128 IPv6addresses.

>  
> Mustapha.
>
> From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6
> FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the
> correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions
> for IPv4 and IPv6 as an option. Regarding the format definition in
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta <at> alcatel-lucent.com>
> > To: Vishwas Manral <vishwas.ietf <at> gmail.com>
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui <at> alcatel-lucent.com>,   "mpls <at> ietf.org"
> >    <mpls <at> ietf.org>
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C584046466ED224CA92C1BC3313B963E09EFE8D667 <at> INBANSXCHMBSA3.in.
> > alcatel-lucent.com <http://alcatel-lucent.com> >
> >    
> > Content-Type: text/plain; charset="us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id because
> > having separate link adjacencies does not really solved any problem.
> > Since hello adjacencies are associated with a link, still fate
> > sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would
> > only decide whether such a link is to be programmed for IPV4 or IPV6
> > egress traffic but I see it as overkill and unnecessary scalability impacts.
> >
> > Thanks,
> > Pranjal
> >
> --------------------------------------------------------
> 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.



_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.com



_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Lizhong Jin | 1 Mar 09:45 2012
Picon

Re: Comments on draft-ietf-mpls-ldp-ipv6-06



> Hi Lizhong/ Pranjal/ Mustapha,
>
> So the two main comments that have come after last call are:
>
> 1. Allow for separation of sessions along with the adjacency.
> 2. Allow for an IPv6 based LSR-ID.
>
> The second could lead to changes required in both OSPF and IS-IS, as
> well because the new LSR ID would then need to be exchanged. We
> could treat it as an enhancement instead in my view. Do you agree?
[Lizhong] agree, but as Kamran pointed out also in another email, it is not necessary to flood LSR-ID in routing protocol, the transport address in hello message is required to be flooded.

Regards
Lizhong

>
> Thanks,
> Vishwas

> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <
> pranjal.dutta <at> alcatel-lucent.com> wrote:
> Yes, I support that too. There would be network management issues
> with mapping of 4 byte LSR-ID to an IPV6 remote address.
> Most of the implementations I know off usually maps 4 byte of the
> LSR-ID with a local ipv4 interface address in the system.
>  
> Thanks,
> Pranjal
>  
>
> From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
> Sent: Wednesday, February 29, 2012 4:57 PM
> To: Aissaoui, Mustapha (Mustapha)
> Cc: mpls <at> ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com
>
> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>  
>
> Hi Mustapha,
> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I
> pointed out in my first email.
>
> Thanks
> Lizhong
>  
>
> "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui <at> alcatel-lucent.com
> > wrote 2012/03/01 04:35:41:
>
> > Hi Lizhong,
> > I actually think that we would need to define a new one which will
> > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> > a all-IPv6 network will not be possible. I cannot see that operators
> > will start maintaining a mapping of some global non routable LSR-id
> > value to an IPv6 loopback interface on each router in the network.
> >  
> > Mustapha.
> > From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> > Aissaoui, Mustapha (Mustapha)
> > Sent: Tuesday, February 07, 2012 10:12 AM
> > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com
> > Cc: mpls <at> ietf.org
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>
> > Lizhong,
> > the existing LSR-id will do the job and should be supported since
> > the LSR-id need not be an IP address. Most implementations will
> > actually populate the field with a /32 address in IPv4 and thus If
> > necessary we could define a new format to allow the use of /128
> IPv6addresses.
> >  
> > Mustapha.
> >
> > From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
> > Sent: Monday, February 06, 2012 10:23 PM
> > To: Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com; Aissaoui,
> > Mustapha (Mustapha)
> > Cc: mpls <at> ietf.org
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>
> >
> > Hi,
> > I wonder if it is feasible to use LDP capability to advertise IPv6
> > FEC without IPv6 adjacency, and only use one adjacency for LDP
> > session in dual-stack network. LDP capability is per node
> > capability, not per interface capability. But for LDP to choose the
> > correct downstream session and output interface for each FEC, it
> > should also check if the output interface is LDP enabled or not. The
> > link adjacency could be used to assist such kind of checking.
> >
> > However, IMO, it is valuable to allow two independent LDP sessions
> > for IPv4 and IPv6 as an option. Regarding the format definition in
> > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> > new format of LSR-ID.
> >
> > Regards
> > Lizhong
> >
> >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta <at> alcatel-lucent.com>
> > > To: Vishwas Manral <vishwas.ietf <at> gmail.com>
> > > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> > >    <mustapha.aissaoui <at> alcatel-lucent.com>,   "mpls <at> ietf.org"
> > >    <mpls <at> ietf.org>
> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > > Message-ID:
> > >    <C584046466ED224CA92C1BC3313B963E09EFE8D667 <at> INBANSXCHMBSA3.in.
> > > alcatel-lucent.com>
> > >    
> > > Content-Type: text/plain; charset="us-ascii"
> > >
> > > I would rather for complete separation with multiple lsr-id because
> > > having separate link adjacencies does not really solved any problem.
> > > Since hello adjacencies are associated with a link, still fate
> > > sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
> > > Having IPV4 and IPV6 specific hello adjacencies over a link would
> > > only decide whether such a link is to be programmed for IPV4 or IPV6
> > > egress traffic but I see it as overkill and unnecessary
> scalability impacts.
> > >
> > > Thanks,
> > > Pranjal
> > >
> > --------------------------------------------------------
> > 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.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

that is correct. We do not want to change the meaning of LSR-ID. We just want it to be able to accomodate a global unique ID of the size of an IPv6 address.
 
There will certainly be other additions to make the protocol support separate sessions and as such bumping the protocol version might be required.
 
Mustapha.

From: Kamran Raza [mailto:skraza <at> cisco.com]
Sent: Wednesday, February 29, 2012 11:40 PM
To: Vishwas Manral; Dutta, Pranjal K (Pranjal)
Cc: Aissaoui, Mustapha (Mustapha); mpls <at> ietf.org; Lizhong Jin
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06


Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/or route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and need not be routable, though most implementations currently populate it with /32 loopback address. Let’s not carry forward a wrong notion/usage.

Secondly, If there is a need to define new “LDP Identifier” in order to establish/maintain a separate session for IPv6 AF, this should be a protocol change — i.e. we should bump up LDP protocol version in LDP PDU header for this, and possibly define new format for “LDP Identifier” in the context of new LDP protocol version.

My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf <at> gmail.com> wrote:

Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have come after last call are:

1. Allow for separation of sessions along with the adjacency.
2. Allow for an IPv6 based LSR-ID.

The second could lead to changes required in both OSPF and IS-IS, as well because the new LSR ID would then need to be exchanged. We could treat it as an enhancement instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta <at> alcatel-lucent.com> wrote:
Yes, I support that too. There would be network management issues with mapping of 4 byte LSR-ID to an IPV6 remote address.
Most of the implementations I know off usually maps 4 byte of the LSR-ID with a local ipv4 interface address in the system.
 
Thanks,
Pranjal
 

From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
Sent: Wednesday, February 29, 2012 4:57 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls <at> ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com

Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
 

Hi Mustapha,
I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong
 

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui <at> alcatel-lucent.com> wrote 2012/03/01 04:35:41:

> Hi Lizhong,

> I actually think that we would need to define a new one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6 network will not be possible. I cannot see that operators
> will start maintaining a mapping of some global non routable LSR-id
> value to an IPv6 loopback interface on each router in the network.

>  
> Mustapha.
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If
> necessary we could define a new format to allow the use of /128 IPv6addresses.

>  
> Mustapha.
>
> From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6
> FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the
> correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions
> for IPv4 and IPv6 as an option. Regarding the format definition in
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta <at> alcatel-lucent.com>
> > To: Vishwas Manral <vishwas.ietf <at> gmail.com>
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui <at> alcatel-lucent.com>,   "mpls <at> ietf.org"
> >    <mpls <at> ietf.org>
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C584046466ED224CA92C1BC3313B963E09EFE8D667 <at> INBANSXCHMBSA3.in.
> > alcatel-lucent.com <http://alcatel-lucent.com> >
> >    
> > Content-Type: text/plain; charset="us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id because
> > having separate link adjacencies does not really solved any problem.
> > Since hello adjacencies are associated with a link, still fate
> > sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would
> > only decide whether such a link is to be programmed for IPV4 or IPV6
> > egress traffic but I see it as overkill and unnecessary scalability impacts.
> >
> > Thanks,
> > Pranjal
> >
> --------------------------------------------------------
> 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.



_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.com



_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Shane Amante | 1 Mar 16:45 2012
Picon

Re: Comments on draft-ietf-mpls-ldp-ipv6-06

Kamran,

On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote:
Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/or route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and need not be routable, though most implementations currently populate it with /32 loopback address. Let’s not carry forward a wrong notion/usage.

Although, in theory, the LSR-ID "need not be routable", I can say that in the networks I operate it is *always* routable. From a simple troubleshooting PoV, it's extremely easy to:
a) ping the /32 (4-octet) LSR-ID; or,
b) look at a routing table for the existence of a /32 (4-octet) LSR-ID
b) use traceroute and/or a routing table to learn the _topological_ location of the /32 (4-octet) LSR-ID in the network ...

In summary, there is a tremendous amount of operational value in the 4-Byte LSR-ID actually be announced/routed in a network's IGP -- let us not underestimate that. All I'm saying is, let's not go out of our way to try to make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical reasons.

-shane


Secondly, If there is a need to define new “LDP Identifier” in order to establish/maintain a separate session for IPv6 AF, this should be a protocol change — i.e. we should bump up LDP protocol version in LDP PDU header for this, and possibly define new format for “LDP Identifier” in the context of new LDP protocol version.

My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf <at> gmail.com> wrote:

Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have come after last call are:

1. Allow for separation of sessions along with the adjacency.
2. Allow for an IPv6 based LSR-ID.

The second could lead to changes required in both OSPF and IS-IS, as well because the new LSR ID would then need to be exchanged. We could treat it as an enhancement instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta <at> alcatel-lucent.com> wrote:
Yes, I support that too. There would be network management issues with mapping of 4 byte LSR-ID to an IPV6 remote address.
Most of the implementations I know off usually maps 4 byte of the LSR-ID with a local ipv4 interface address in the system.
 
Thanks,
Pranjal
 

From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
Sent: Wednesday, February 29, 2012 4:57 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls <at> ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com

Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
 

Hi Mustapha,
I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong
 

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui <at> alcatel-lucent.com> wrote 2012/03/01 04:35:41:

> Hi Lizhong,

> I actually think that we would need to define a new one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6 network will not be possible. I cannot see that operators
> will start maintaining a mapping of some global non routable LSR-id
> value to an IPv6 loopback interface on each router in the network.

>  
> Mustapha.
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If
> necessary we could define a new format to allow the use of /128 IPv6addresses.

>  
> Mustapha.
>
> From: Lizhong Jin [mailto:lizhong.jin <at> zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vishwas.ietf <at> gmail.com; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls <at> ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6
> FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the
> correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions
> for IPv4 and IPv6 as an option. Regarding the format definition in
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta <at> alcatel-lucent.com>
> > To: Vishwas Manral <vishwas.ietf <at> gmail.com>
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui <at> alcatel-lucent.com>,   "mpls <at> ietf.org"
> >    <mpls <at> ietf.org>
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C584046466ED224CA92C1BC3313B963E09EFE8D667 <at> INBANSXCHMBSA3.in.
> > alcatel-lucent.com <http://alcatel-lucent.com> >
> >    
> > Content-Type: text/plain; charset="us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id because
> > having separate link adjacencies does not really solved any problem.
> > Since hello adjacencies are associated with a link, still fate
> > sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would
> > only decide whether such a link is to be programmed for IPV4 or IPV6
> > egress traffic but I see it as overkill and unnecessary scalability impacts.
> >
> > Thanks,
> > Pranjal
> >
> --------------------------------------------------------
> 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.


_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.com



_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Shane Amante | 1 Mar 16:51 2012
Picon

Re: Comments on draft-ietf-mpls-ldp-ipv6-06


On Feb 29, 2012, at 9:03 PM, Mark Tinka wrote:
> On Thursday, March 01, 2012 11:27:56 AM Rajiv Asati (rajiva) 
> wrote:
> 
>> Nonetheless, an implementation could choose to optimize,
>> if needed, to keep both address-family related info in a
>> single adjacency structure, but this is all
>> implementation specific. :)
> 
> I agree, and as mentioned earlier, as an operator, I'd 
> rather this isn't the default. If a default needs to be 
> implemented by a vendor, then AF separation would be my 
> preference.
> 
> However, I'd support including knobs to allow operators to 
> consolidate, if they so wished.

Well said, Mark. As an operator, as well, I concur with both points.

-shane
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls


Gmane