ietf
[Top] [All Lists]

RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard

2014-12-19 11:59:35
Hi Mark,
both proposed methods to solve this LDP backward compatibility issue rely on 
detecting a specific TLV from the peer. So, the absence of the TLV will 
indicate that the peer LSR is not compliant to the LDP IPv6 draft in a similar 
way ISIS uses the absence of the Multi-Topology TLV to consider the neighbor is 
MT=0 capable only. So there is no need for a CLI knob. 

What we were debating is if we should use the LDP capability TLV mechanism 
which LDP uses to advertise any new capability not supported by previous 
implementations versus overloading another TLV which was not meant for 
capability discovery.

Mustapha.     

-----Original Message-----
From: Mark Tinka [mailto:mark(_dot_)tinka(_at_)seacom(_dot_)mu]
Sent: Thursday, December 18, 2014 11:28 AM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; IETF-Announce
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to 
LDP for
IPv6) to Proposed Standard

On Thursday, December 18, 2014 05:38:16 PM Aissaoui, Mustapha (Mustapha)
wrote:

Hi Mark,
The issue will exist on a p2p link...

Yes, figured as much.

but in that case you
could always add a per-interface configuration knob which disables the
dual-stack behavior and will prevent sending IPv6 FECs and IPv6
addresses over a session on that link.

Yes, easier to do on a point-to-point link compared to a broadcast network.

That said, I'm still for more of an MT-type solution a la IS-IS, so that this 
applies to
the entire protocol. This way, operators do not have to fuff around with 
yet-another-
knob (until they really have to).

Any thoughts around this?

Cheers,

Mark.


<Prev in Thread] Current Thread [Next in Thread>