Bob Thomas (rhthomas | 5 Mar 19:36 2008
Picon

draft-manral-mls-ldp-ipv6

I read the recently submitted subject draft with interest and have a few
comments/questions below.

Bob

* Page 2, Section 2.  LSP mapping procedures

Suggest the following wording for the bulleted item:

      -  If it is known that a packet must traverse a particular egress
         router, and there is an LSP that has an Address Prefix FEC
         element that is an IPv4 or IPv6 address of that router, then
         the packet is mapped to that LSP.  The procedure for
         obtaining this knowledge is beyond the scope of this
         document.

* Page 4, Section 4.  LDP Discovery

Suggest replacing "LSR's label swithing peers" with "LDP peers".

* Page 4, Section 4.1.  Basic Discovery Mechanism

For LDP peers connected by a single point-to-point link aren't Hello
messages for a single address family (either IPv4 or IPv6) sufficient?

Also, the term "socket" is not defined in the context of this draft.
The draft should restrict itself to talking about formats of packets on
the wire, rather than about implementation read/write concepts.

* Page 5, Section 4.2 Extended Discovery Mechanism
(Continue reading)

Vishwas Manral | 5 Mar 19:59 2008
Picon

Re: draft-manral-mls-ldp-ipv6

Hi Bob,

Thanks a lot for the comments. The comments are very helpful.

The biggest change you suggest of allowing multiple Transport Address
TLV's is something that will require more updates to the draft, as
RFC5036 assumes only a single Transport address TLV in the Hello. Have
a look and do let me know what you think.

Please see my comments inline in the draft.

On Wed, Mar 5, 2008 at 10:36 AM, Bob Thomas (rhthomas)
<rhthomas <at> cisco.com> wrote:

>  * Page 2, Section 2.  LSP mapping procedures
>
>  Suggest the following wording for the bulleted item:
>
>       -  If it is known that a packet must traverse a particular egress
>          router, and there is an LSP that has an Address Prefix FEC
>          element that is an IPv4 or IPv6 address of that router, then
>          the packet is mapped to that LSP.  The procedure for
>          obtaining this knowledge is beyond the scope of this
>          document.
VM>> Will change to the wording you define.

>
>  * Page 4, Section 4.  LDP Discovery
>
>  Suggest replacing "LSR's label swithing peers" with "LDP peers".
(Continue reading)

jeanlouis.leroux | 5 Mar 20:01 2008

Re: I-D ACTION:draft-ietf-mpls-mp-ldp-reqs-04.txt

Hi all

There is no change in this new version, this is a pure refresh.

We consider that the draft is ready for WG last call.

Regards,

JL

 

 New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

Title : Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol
Author(s) : J. Le Roux
Filename : draft-ietf-mpls-mp-ldp-reqs-04.txt
Pages : 18
Date : 2008-2-25

This document lists a set of functional requirements for Label
   Distribution Protocol (LDP) extensions for setting up point-to-
   multipoint (P2MP) Label Switched Paths (LSP), in order to deliver
   point-to-multipoint applications over a Multi Protocol Label
   Switching (MPLS) infrastructure. It is intended that solutions that
   specify LDP procedures for setting up P2MP LSP satisfy these
   requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-04.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-mpls-mp-ldp-reqs-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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


 
 

Jean-Louis Le Roux
FT/NSM/SIRP/DIOS/DSF

Responsable Unité de R&D DSF
tél. 02 96 05 30 20
mob. 06 83 47 05 28
jeanlouis.leroux <at> orange-ftgroup.com

 
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Bob Thomas (rhthomas | 5 Mar 20:48 2008
Picon

Re: draft-manral-mpls-ldp-ipv6

[Note that I corrected the spelling of the draft name in the Subject
field]

Hi Vishwas,

Just a few follow up comments in line.  Search for #bt.

Bob

> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com] 
> Sent: Wednesday, March 05, 2008 2:00 PM
> To: Bob Thomas (rhthomas)
> Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; mpls <at> ietf.org
> Subject: Re: [mpls] draft-manral-mls-ldp-ipv6
> 
> Hi Bob,
> 
> Thanks a lot for the comments. The comments are very helpful.
> 
> The biggest change you suggest of allowing multiple Transport Address
> TLV's is something that will require more updates to the draft, as
> RFC5036 assumes only a single Transport address TLV in the Hello. Have
> a look and do let me know what you think.

#bt: Actually my intention was to suggest that we allow an optional IPv4
Transport Address TLV (but NOT an IPv6 Transport Address TLV) in a Hello
carried in an IPv4 packet and an optional IPv6 Transport Address TLV
(but NOT an IPv4 Transport Address TLV) in a Hello carried by an IPv6
packet.

That is, there would be at most 1 Transport Address TLV in a Hello
message.

> Please see my comments inline in the draft.
> 
> On Wed, Mar 5, 2008 at 10:36 AM, Bob Thomas (rhthomas)
> <rhthomas <at> cisco.com> wrote:
> 
> >  * Page 2, Section 2.  LSP mapping procedures
> >
> >  Suggest the following wording for the bulleted item:
> >
> >       -  If it is known that a packet must traverse a 
> particular egress
> >          router, and there is an LSP that has an Address Prefix FEC
> >          element that is an IPv4 or IPv6 address of that 
> router, then
> >          the packet is mapped to that LSP.  The procedure for
> >          obtaining this knowledge is beyond the scope of this
> >          document.
> VM>> Will change to the wording you define.
> 
> >
> >  * Page 4, Section 4.  LDP Discovery
> >
> >  Suggest replacing "LSR's label swithing peers" with "LDP peers".
> VM>> The sentence is actually taked from Section 2.4 of RFC5036. Will
> change it however.
> 
> >
> >  * Page 4, Section 4.1.  Basic Discovery Mechanism
> >
> >  For LDP peers connected by a single point-to-point link 
> aren't Hello
> >  messages for a single address family (either IPv4 or IPv6) 
> sufficient?
> >
> >  Also, the term "socket" is not defined in the context of 
> this draft.
> >  The draft should restrict itself to talking about formats 
> of packets on
> >  the wire, rather than about implementation read/write concepts.
> VM>> I agree. Does the wording below help:
> 
>    In a dual stack case where the interface has both IPv4 as 
> well as IPv6
>    configured hellos will be sent for both IPv4 and IPv6 for 
> every label
>    space.

#bt: I think that it is unnecessary to send both IPv4 and IPv6 packets
carrying Hello's over a point-to-point link between two LSRs.  A single
packet type (IPv4 packet carrying an IPv4 Hello or IPv6 packet carrying
an IPv6 Hello) should be sufficient.

> >  * Page 5, Section 4.2 Extended Discovery Mechanism
> >
> >    "As Targeted Hellos will be sent to a particular preconfigured
> >  address,
> >     we send the Hello only the socket of the same address 
> family as the
> >     configured address. If the address is configured for 
> both IPv4 and
> >  IPv6
> >     in that case we can send Hellos on the both IPv4 and 
> IPv6 sockets."
> >
> >  I'm not sure what it means for an "address" to be 
> "configured for both
> >  IPv4 and IPv6".  Assuming that it means that targeted Hello's are
> >  targeted for 2 addresses, one of which is an IPv4 address 
> and the other
> >  of which is an IPv6 address, without inspecting topology 
> information
> >  gleaned from an IGP how could a router determine if 2 such 
> addresses are
> >  for the same target?
> VM>> You are right. It was a bad attempt to make a distinction between
> the Extended Discovery and the Basic discovery mechanism. I will
> reword this further.
> 
> >  * Page 5, Section 5. Maintaining Hello Adjacencies
> >
> >    "An LDP session has multiple Hello adjacencies when a 
> pair of LSRs is
> >     connected by multiple links that share the same label space; for
> >     example, multiple PPP links between a pair of routers. 
> We can also
> >  have
> >     multiple Hello adjacencies in the dual stack case where 
> we have IPv4
> >     and IPv6 Hellos exchanged for the same label space 
> between a pair of
> >     LSR's."
> >
> >  For peers directly connected by a single point-2-point 
> link Hello's for
> >  a single address family should be sufficient to allow 
> estalishment of an
> >  LDP session supporting label advertisement for both IPv4 and IPv6
> >  addresses families.
> >
> >  For a set of peers connected by a single multi-access link 
> it may not be
> >  practical in general to limit Hello's to a single address family.
> >
> >  For targeted peers it may be difficult to prevent multiple 
> hello targets
> >  for the same peer.
> VM> That is correct, hellos for a single address family should be
> sufficient in the case that the other end also supports the same.
> However this is meant to work for the case where we have say an IPv6
> only or IPv4 router as a peer.

#bt: Agreed, discovery needs to work when peering is with an IPv4-only
or an IPv6-only peer.  However, I think the discovery procedures can be
defined in such a way that it is unnecessary to send both IPv6 and IPv4
Hello's between 2 peers on a point-to-point link.  For example, if R1
supports both IPv4 and IPv6 and R2 supports only IPv4, R1 can quickly
discover that it is receiving IPv4 Hellos from R2 and send only IPv4
Hellos to R2 (if it is not already doing so).

> >  * Page 5, Section 6.  Hello Message Procedures
> >
> >    "However [RFC5036] states does not define the behavior 
> of LDP in case
> >
> >     both IPv4 and IPv6 transport addresses are sent in the packet.
> >
> >     [RFC5036] seems to assume that only one such TLV is received
> >     and specifies the behavior based on such a case."
> >
> >  One Transport Address TLV per Hello message is sufficient 
> and should be
> >  the goal.
> >
> >  A reasonable approach would be to permit an optional IPv4 Transport
> >  Address TLV (but not an IPv6 Transport Address TLV) when the Hello
> >  message is carried in an IPv4 packet and to permit an optional IPv6
> >  Transport Address TLV (but not an IPv4 Transport Address 
> TLV) when the
> >  Hellos message is carried in an IPv6 packet.
> VM> Our attempt is to allow only one Transport Address TLV in the
> hello's. We currently allow receiving multiple TLV's, but we send only
> a single TLV. We have not yet got the optional part that you mention.
> the reason being that RFC5036 states the below:
> 
>       IPv4 Transport Address
>          Specifies the IPv4 address to be used for the 
> sending LSR when
>          opening the LDP session TCP connection.  If this optional TLV
>          is not present, the IPv4 source address for the UDP packet
>          carrying the Hello SHOULD be used.
> 
>       Configuration Sequence Number
>          Specifies a 4 octet unsigned configuration sequence 
> number that
>          identifies the configuration state of the sending 
> LSR.  Used by
>          the receiving LSR to detect configuration changes on the
>          sending LSR.
> 
>       IPv6 Transport Address
>          Specifies the IPv6 address to be used for the 
> sending LSR when
>          opening the LDP session TCP connection.  If this optional TLV
>          is not present the IPv6 source address for the UDP packet
>          carrying the Hello SHOULD be used.
> 
> We will then need to change the above section too.

#bt: As noted above my suggestion is to allow an optional IPv4 Transport
Address TLV in Hello's carried by IPv4 packets and an optional IPv6
Transport Address TLV in Hello's carried by IPv6 packets.  I think this
is in the spirit of the rfc5036 text quoted above.

 
> >  * Page 6, Section 7.2  Session Initialization
> >
> >  My opinion is that IPv6 label distribution should be 
> assumed to be "off"
> >  for an LDP session until explicitly enabled by the LDP capability
> >  mechanism.
> >
> >  This is the approach for all "new" FEC types (e.g., the 
> mLDP FEC types),
> >  and had the capability mechanism been part of the baseline 
> LDP spec it
> >  would have been the case for IPv4 and the AToM/L2vpn set 
> of FEC types.
> VM>> OK, will do this part. We had left it because we thought it was a
> configuration option local to the router in question.

#bt: I agree that it is a configuration option.  If IPv6 LDP label
distribution is configured on a router then it would advertise the
corresponding capability in its Initialization message as part of
session establishment.

> >  * Page 8, Section 8.1 Normative References
> >
> >  rfc5036 is missing from the list of normative references.
> VM>> That is a big gaffee and will be corrected.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Vishwas Manral | 5 Mar 21:09 2008
Picon

Re: draft-manral-mpls-ldp-ipv6

Hi Bob,

I think we have narrowed down the differences further then.:) Your
comments have been helpful.

>  #bt: Actually my intention was to suggest that we allow an optional IPv4
>  Transport Address TLV (but NOT an IPv6 Transport Address TLV) in a Hello
>  carried in an IPv4 packet and an optional IPv6 Transport Address TLV
>  (but NOT an IPv4 Transport Address TLV) in a Hello carried by an IPv6
>  packet.
>
>  That is, there would be at most 1 Transport Address TLV in a Hello
>  message.
VM>> I guess the draft intends to state exactly that. We will clarify
it further.

>  #bt: I think that it is unnecessary to send both IPv4 and IPv6 packets
>  carrying Hello's over a point-to-point link between two LSRs.  A single
>  packet type (IPv4 packet carrying an IPv4 Hello or IPv6 packet carrying
>  an IPv6 Hello) should be sufficient.
VM>> It would be nice, if we knew the capability of the neighbor.
However as we do not know whether the neighbor supports both stacks or
not (unlike protocols like BGP the peer address is not configured but
actually discovered), we may have to start sending both the Hello's.

After that we can decide to drop a Hello's adjacency (if we have two),
but then again we will need to have priority of which one to drop (so
that we do it consistently - and we do not have two sides of the
adjacency dropping different Hello adjacencies). I thought it would be
good to allow both. Do you see any other issue besides the load of the
extra Hello (added resiliency is gained too though).

I guess the above is the main point of difference between us right now.

Thanks,
Vishwas

On Wed, Mar 5, 2008 at 11:48 AM, Bob Thomas (rhthomas)
<rhthomas <at> cisco.com> wrote:
> [Note that I corrected the spelling of the draft name in the Subject
>  field]
>
>  Hi Vishwas,
>
>  Just a few follow up comments in line.  Search for #bt.
>
>  Bob
>
>
>  > -----Original Message-----
>  > From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com]
>  > Sent: Wednesday, March 05, 2008 2:00 PM
>  > To: Bob Thomas (rhthomas)
>  > Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; mpls <at> ietf.org
>  > Subject: Re: [mpls] draft-manral-mls-ldp-ipv6
>  >
>  > Hi Bob,
>  >
>  > Thanks a lot for the comments. The comments are very helpful.
>  >
>  > The biggest change you suggest of allowing multiple Transport Address
>  > TLV's is something that will require more updates to the draft, as
>  > RFC5036 assumes only a single Transport address TLV in the Hello. Have
>  > a look and do let me know what you think.
>
>  #bt: Actually my intention was to suggest that we allow an optional IPv4
>  Transport Address TLV (but NOT an IPv6 Transport Address TLV) in a Hello
>  carried in an IPv4 packet and an optional IPv6 Transport Address TLV
>  (but NOT an IPv4 Transport Address TLV) in a Hello carried by an IPv6
>  packet.
>
>  That is, there would be at most 1 Transport Address TLV in a Hello
>  message.
>
>
>  > Please see my comments inline in the draft.
>  >
>  > On Wed, Mar 5, 2008 at 10:36 AM, Bob Thomas (rhthomas)
>  > <rhthomas <at> cisco.com> wrote:
>  >
>  > >  * Page 2, Section 2.  LSP mapping procedures
>  > >
>  > >  Suggest the following wording for the bulleted item:
>  > >
>  > >       -  If it is known that a packet must traverse a
>  > particular egress
>  > >          router, and there is an LSP that has an Address Prefix FEC
>  > >          element that is an IPv4 or IPv6 address of that
>  > router, then
>  > >          the packet is mapped to that LSP.  The procedure for
>  > >          obtaining this knowledge is beyond the scope of this
>  > >          document.
>  > VM>> Will change to the wording you define.
>  >
>  > >
>  > >  * Page 4, Section 4.  LDP Discovery
>  > >
>  > >  Suggest replacing "LSR's label swithing peers" with "LDP peers".
>  > VM>> The sentence is actually taked from Section 2.4 of RFC5036. Will
>  > change it however.
>  >
>  > >
>  > >  * Page 4, Section 4.1.  Basic Discovery Mechanism
>  > >
>  > >  For LDP peers connected by a single point-to-point link
>  > aren't Hello
>  > >  messages for a single address family (either IPv4 or IPv6)
>  > sufficient?
>  > >
>  > >  Also, the term "socket" is not defined in the context of
>  > this draft.
>  > >  The draft should restrict itself to talking about formats
>  > of packets on
>  > >  the wire, rather than about implementation read/write concepts.
>  > VM>> I agree. Does the wording below help:
>  >
>  >    In a dual stack case where the interface has both IPv4 as
>  > well as IPv6
>  >    configured hellos will be sent for both IPv4 and IPv6 for
>  > every label
>  >    space.
>
>  #bt: I think that it is unnecessary to send both IPv4 and IPv6 packets
>  carrying Hello's over a point-to-point link between two LSRs.  A single
>  packet type (IPv4 packet carrying an IPv4 Hello or IPv6 packet carrying
>  an IPv6 Hello) should be sufficient.
>
>
>  > >  * Page 5, Section 4.2 Extended Discovery Mechanism
>  > >
>  > >    "As Targeted Hellos will be sent to a particular preconfigured
>  > >  address,
>  > >     we send the Hello only the socket of the same address
>  > family as the
>  > >     configured address. If the address is configured for
>  > both IPv4 and
>  > >  IPv6
>  > >     in that case we can send Hellos on the both IPv4 and
>  > IPv6 sockets."
>  > >
>  > >  I'm not sure what it means for an "address" to be
>  > "configured for both
>  > >  IPv4 and IPv6".  Assuming that it means that targeted Hello's are
>  > >  targeted for 2 addresses, one of which is an IPv4 address
>  > and the other
>  > >  of which is an IPv6 address, without inspecting topology
>  > information
>  > >  gleaned from an IGP how could a router determine if 2 such
>  > addresses are
>  > >  for the same target?
>  > VM>> You are right. It was a bad attempt to make a distinction between
>  > the Extended Discovery and the Basic discovery mechanism. I will
>  > reword this further.
>  >
>  > >  * Page 5, Section 5. Maintaining Hello Adjacencies
>  > >
>  > >    "An LDP session has multiple Hello adjacencies when a
>  > pair of LSRs is
>  > >     connected by multiple links that share the same label space; for
>  > >     example, multiple PPP links between a pair of routers.
>  > We can also
>  > >  have
>  > >     multiple Hello adjacencies in the dual stack case where
>  > we have IPv4
>  > >     and IPv6 Hellos exchanged for the same label space
>  > between a pair of
>  > >     LSR's."
>  > >
>  > >  For peers directly connected by a single point-2-point
>  > link Hello's for
>  > >  a single address family should be sufficient to allow
>  > estalishment of an
>  > >  LDP session supporting label advertisement for both IPv4 and IPv6
>  > >  addresses families.
>  > >
>  > >  For a set of peers connected by a single multi-access link
>  > it may not be
>  > >  practical in general to limit Hello's to a single address family.
>  > >
>  > >  For targeted peers it may be difficult to prevent multiple
>  > hello targets
>  > >  for the same peer.
>  > VM> That is correct, hellos for a single address family should be
>  > sufficient in the case that the other end also supports the same.
>  > However this is meant to work for the case where we have say an IPv6
>  > only or IPv4 router as a peer.
>
>  #bt: Agreed, discovery needs to work when peering is with an IPv4-only
>  or an IPv6-only peer.  However, I think the discovery procedures can be
>  defined in such a way that it is unnecessary to send both IPv6 and IPv4
>  Hello's between 2 peers on a point-to-point link.  For example, if R1
>  supports both IPv4 and IPv6 and R2 supports only IPv4, R1 can quickly
>  discover that it is receiving IPv4 Hellos from R2 and send only IPv4
>  Hellos to R2 (if it is not already doing so).
>
>  > >  * Page 5, Section 6.  Hello Message Procedures
>  > >
>  > >    "However [RFC5036] states does not define the behavior
>  > of LDP in case
>  > >
>  > >     both IPv4 and IPv6 transport addresses are sent in the packet.
>  > >
>  > >     [RFC5036] seems to assume that only one such TLV is received
>  > >     and specifies the behavior based on such a case."
>  > >
>  > >  One Transport Address TLV per Hello message is sufficient
>  > and should be
>  > >  the goal.
>  > >
>  > >  A reasonable approach would be to permit an optional IPv4 Transport
>  > >  Address TLV (but not an IPv6 Transport Address TLV) when the Hello
>  > >  message is carried in an IPv4 packet and to permit an optional IPv6
>  > >  Transport Address TLV (but not an IPv4 Transport Address
>  > TLV) when the
>  > >  Hellos message is carried in an IPv6 packet.
>  > VM> Our attempt is to allow only one Transport Address TLV in the
>  > hello's. We currently allow receiving multiple TLV's, but we send only
>  > a single TLV. We have not yet got the optional part that you mention.
>  > the reason being that RFC5036 states the below:
>  >
>  >       IPv4 Transport Address
>  >          Specifies the IPv4 address to be used for the
>  > sending LSR when
>  >          opening the LDP session TCP connection.  If this optional TLV
>  >          is not present, the IPv4 source address for the UDP packet
>  >          carrying the Hello SHOULD be used.
>  >
>  >       Configuration Sequence Number
>  >          Specifies a 4 octet unsigned configuration sequence
>  > number that
>  >          identifies the configuration state of the sending
>  > LSR.  Used by
>  >          the receiving LSR to detect configuration changes on the
>  >          sending LSR.
>  >
>  >       IPv6 Transport Address
>  >          Specifies the IPv6 address to be used for the
>  > sending LSR when
>  >          opening the LDP session TCP connection.  If this optional TLV
>  >          is not present the IPv6 source address for the UDP packet
>  >          carrying the Hello SHOULD be used.
>  >
>  > We will then need to change the above section too.
>
>  #bt: As noted above my suggestion is to allow an optional IPv4 Transport
>  Address TLV in Hello's carried by IPv4 packets and an optional IPv6
>  Transport Address TLV in Hello's carried by IPv6 packets.  I think this
>  is in the spirit of the rfc5036 text quoted above.
>
>
>  > >  * Page 6, Section 7.2  Session Initialization
>  > >
>  > >  My opinion is that IPv6 label distribution should be
>  > assumed to be "off"
>  > >  for an LDP session until explicitly enabled by the LDP capability
>  > >  mechanism.
>  > >
>  > >  This is the approach for all "new" FEC types (e.g., the
>  > mLDP FEC types),
>  > >  and had the capability mechanism been part of the baseline
>  > LDP spec it
>  > >  would have been the case for IPv4 and the AToM/L2vpn set
>  > of FEC types.
>  > VM>> OK, will do this part. We had left it because we thought it was a
>  > configuration option local to the router in question.
>
>  #bt: I agree that it is a configuration option.  If IPv6 LDP label
>  distribution is configured on a router then it would advertise the
>  corresponding capability in its Initialization message as part of
>  session establishment.
>
>
>  > >  * Page 8, Section 8.1 Normative References
>  > >
>  > >  rfc5036 is missing from the list of normative references.
>  > VM>> That is a big gaffee and will be corrected.
>
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Bob Thomas (rhthomas | 5 Mar 22:03 2008
Picon

Re: draft-manral-mpls-ldp-ipv6

Hi Vishal,

Yes, I think we are converging ...

Follow up inline - search for #bt.

Bob

> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com] 
> Sent: Wednesday, March 05, 2008 3:09 PM
> To: Bob Thomas (rhthomas)
> Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; mpls <at> ietf.org
> Subject: Re: [mpls] draft-manral-mpls-ldp-ipv6
> 
> Hi Bob,
> 
> I think we have narrowed down the differences further then.:) Your
> comments have been helpful.
> 
> >  #bt: Actually my intention was to suggest that we allow an 
> optional IPv4
> >  Transport Address TLV (but NOT an IPv6 Transport Address 
> TLV) in a Hello
> >  carried in an IPv4 packet and an optional IPv6 Transport 
> Address TLV
> >  (but NOT an IPv4 Transport Address TLV) in a Hello carried 
> by an IPv6
> >  packet.
> >
> >  That is, there would be at most 1 Transport Address TLV in a Hello
> >  message.
> VM>> I guess the draft intends to state exactly that. We will clarify
> it further.
> 
> >  #bt: I think that it is unnecessary to send both IPv4 and 
> IPv6 packets
> >  carrying Hello's over a point-to-point link between two 
> LSRs.  A single
> >  packet type (IPv4 packet carrying an IPv4 Hello or IPv6 
> packet carrying
> >  an IPv6 Hello) should be sufficient.
> VM>> It would be nice, if we knew the capability of the neighbor.
> However as we do not know whether the neighbor supports both stacks or
> not (unlike protocols like BGP the peer address is not configured but
> actually discovered), we may have to start sending both the Hello's.

#bt: One approach would be to make that explicit in the Hello's (not
sure that we want to go there).  The other is to wait and see what kinds
of Hello's are received from the peer.

> After that we can decide to drop a Hello's adjacency (if we have two),
> but then again we will need to have priority of which one to drop (so
> that we do it consistently - and we do not have two sides of the
> adjacency dropping different Hello adjacencies). I thought it would be
> good to allow both. Do you see any other issue besides the load of the
> extra Hello (added resiliency is gained too though).

#bt: The decision process as to which Hello's to stop sending can be
described by a simple table with an entry for each of the cases.

I'm not convinced that sending 2 types of Hello's on a link is more
resilient than sending a single type of hello's twice as frequently
(unless the concern is about the reliability of the code generating,
sending, receiving and processing hello's of a given type).

My goal is to eliminate Hello's that are unnecessary.

> I guess the above is the main point of difference between us 
> right now.
> 
> Thanks,
> Vishwas
> 
> 
> On Wed, Mar 5, 2008 at 11:48 AM, Bob Thomas (rhthomas)
> <rhthomas <at> cisco.com> wrote:
> > [Note that I corrected the spelling of the draft name in the Subject
> >  field]
> >
> >  Hi Vishwas,
> >
> >  Just a few follow up comments in line.  Search for #bt.
> >
> >  Bob
> >
> >
> >  > -----Original Message-----
> >  > From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com]
> >  > Sent: Wednesday, March 05, 2008 2:00 PM
> >  > To: Bob Thomas (rhthomas)
> >  > Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; mpls <at> ietf.org
> >  > Subject: Re: [mpls] draft-manral-mls-ldp-ipv6
> >  >
> >  > Hi Bob,
> >  >
> >  > Thanks a lot for the comments. The comments are very helpful.
> >  >
> >  > The biggest change you suggest of allowing multiple 
> Transport Address
> >  > TLV's is something that will require more updates to the 
> draft, as
> >  > RFC5036 assumes only a single Transport address TLV in 
> the Hello. Have
> >  > a look and do let me know what you think.
> >
> >  #bt: Actually my intention was to suggest that we allow an 
> optional IPv4
> >  Transport Address TLV (but NOT an IPv6 Transport Address 
> TLV) in a Hello
> >  carried in an IPv4 packet and an optional IPv6 Transport 
> Address TLV
> >  (but NOT an IPv4 Transport Address TLV) in a Hello carried 
> by an IPv6
> >  packet.
> >
> >  That is, there would be at most 1 Transport Address TLV in a Hello
> >  message.
> >
> >
> >  > Please see my comments inline in the draft.
> >  >
> >  > On Wed, Mar 5, 2008 at 10:36 AM, Bob Thomas (rhthomas)
> >  > <rhthomas <at> cisco.com> wrote:
> >  >
> >  > >  * Page 2, Section 2.  LSP mapping procedures
> >  > >
> >  > >  Suggest the following wording for the bulleted item:
> >  > >
> >  > >       -  If it is known that a packet must traverse a
> >  > particular egress
> >  > >          router, and there is an LSP that has an 
> Address Prefix FEC
> >  > >          element that is an IPv4 or IPv6 address of that
> >  > router, then
> >  > >          the packet is mapped to that LSP.  The procedure for
> >  > >          obtaining this knowledge is beyond the scope of this
> >  > >          document.
> >  > VM>> Will change to the wording you define.
> >  >
> >  > >
> >  > >  * Page 4, Section 4.  LDP Discovery
> >  > >
> >  > >  Suggest replacing "LSR's label swithing peers" with 
> "LDP peers".
> >  > VM>> The sentence is actually taked from Section 2.4 of 
> RFC5036. Will
> >  > change it however.
> >  >
> >  > >
> >  > >  * Page 4, Section 4.1.  Basic Discovery Mechanism
> >  > >
> >  > >  For LDP peers connected by a single point-to-point link
> >  > aren't Hello
> >  > >  messages for a single address family (either IPv4 or IPv6)
> >  > sufficient?
> >  > >
> >  > >  Also, the term "socket" is not defined in the context of
> >  > this draft.
> >  > >  The draft should restrict itself to talking about formats
> >  > of packets on
> >  > >  the wire, rather than about implementation read/write 
> concepts.
> >  > VM>> I agree. Does the wording below help:
> >  >
> >  >    In a dual stack case where the interface has both IPv4 as
> >  > well as IPv6
> >  >    configured hellos will be sent for both IPv4 and IPv6 for
> >  > every label
> >  >    space.
> >
> >  #bt: I think that it is unnecessary to send both IPv4 and 
> IPv6 packets
> >  carrying Hello's over a point-to-point link between two 
> LSRs.  A single
> >  packet type (IPv4 packet carrying an IPv4 Hello or IPv6 
> packet carrying
> >  an IPv6 Hello) should be sufficient.
> >
> >
> >  > >  * Page 5, Section 4.2 Extended Discovery Mechanism
> >  > >
> >  > >    "As Targeted Hellos will be sent to a particular 
> preconfigured
> >  > >  address,
> >  > >     we send the Hello only the socket of the same address
> >  > family as the
> >  > >     configured address. If the address is configured for
> >  > both IPv4 and
> >  > >  IPv6
> >  > >     in that case we can send Hellos on the both IPv4 and
> >  > IPv6 sockets."
> >  > >
> >  > >  I'm not sure what it means for an "address" to be
> >  > "configured for both
> >  > >  IPv4 and IPv6".  Assuming that it means that targeted 
> Hello's are
> >  > >  targeted for 2 addresses, one of which is an IPv4 address
> >  > and the other
> >  > >  of which is an IPv6 address, without inspecting topology
> >  > information
> >  > >  gleaned from an IGP how could a router determine if 2 such
> >  > addresses are
> >  > >  for the same target?
> >  > VM>> You are right. It was a bad attempt to make a 
> distinction between
> >  > the Extended Discovery and the Basic discovery mechanism. I will
> >  > reword this further.
> >  >
> >  > >  * Page 5, Section 5. Maintaining Hello Adjacencies
> >  > >
> >  > >    "An LDP session has multiple Hello adjacencies when a
> >  > pair of LSRs is
> >  > >     connected by multiple links that share the same 
> label space; for
> >  > >     example, multiple PPP links between a pair of routers.
> >  > We can also
> >  > >  have
> >  > >     multiple Hello adjacencies in the dual stack case where
> >  > we have IPv4
> >  > >     and IPv6 Hellos exchanged for the same label space
> >  > between a pair of
> >  > >     LSR's."
> >  > >
> >  > >  For peers directly connected by a single point-2-point
> >  > link Hello's for
> >  > >  a single address family should be sufficient to allow
> >  > estalishment of an
> >  > >  LDP session supporting label advertisement for both 
> IPv4 and IPv6
> >  > >  addresses families.
> >  > >
> >  > >  For a set of peers connected by a single multi-access link
> >  > it may not be
> >  > >  practical in general to limit Hello's to a single 
> address family.
> >  > >
> >  > >  For targeted peers it may be difficult to prevent multiple
> >  > hello targets
> >  > >  for the same peer.
> >  > VM> That is correct, hellos for a single address family should be
> >  > sufficient in the case that the other end also supports the same.
> >  > However this is meant to work for the case where we have 
> say an IPv6
> >  > only or IPv4 router as a peer.
> >
> >  #bt: Agreed, discovery needs to work when peering is with 
> an IPv4-only
> >  or an IPv6-only peer.  However, I think the discovery 
> procedures can be
> >  defined in such a way that it is unnecessary to send both 
> IPv6 and IPv4
> >  Hello's between 2 peers on a point-to-point link.  For 
> example, if R1
> >  supports both IPv4 and IPv6 and R2 supports only IPv4, R1 
> can quickly
> >  discover that it is receiving IPv4 Hellos from R2 and send 
> only IPv4
> >  Hellos to R2 (if it is not already doing so).
> >
> >  > >  * Page 5, Section 6.  Hello Message Procedures
> >  > >
> >  > >    "However [RFC5036] states does not define the behavior
> >  > of LDP in case
> >  > >
> >  > >     both IPv4 and IPv6 transport addresses are sent in 
> the packet.
> >  > >
> >  > >     [RFC5036] seems to assume that only one such TLV 
> is received
> >  > >     and specifies the behavior based on such a case."
> >  > >
> >  > >  One Transport Address TLV per Hello message is sufficient
> >  > and should be
> >  > >  the goal.
> >  > >
> >  > >  A reasonable approach would be to permit an optional 
> IPv4 Transport
> >  > >  Address TLV (but not an IPv6 Transport Address TLV) 
> when the Hello
> >  > >  message is carried in an IPv4 packet and to permit an 
> optional IPv6
> >  > >  Transport Address TLV (but not an IPv4 Transport Address
> >  > TLV) when the
> >  > >  Hellos message is carried in an IPv6 packet.
> >  > VM> Our attempt is to allow only one Transport Address TLV in the
> >  > hello's. We currently allow receiving multiple TLV's, 
> but we send only
> >  > a single TLV. We have not yet got the optional part that 
> you mention.
> >  > the reason being that RFC5036 states the below:
> >  >
> >  >       IPv4 Transport Address
> >  >          Specifies the IPv4 address to be used for the
> >  > sending LSR when
> >  >          opening the LDP session TCP connection.  If 
> this optional TLV
> >  >          is not present, the IPv4 source address for the 
> UDP packet
> >  >          carrying the Hello SHOULD be used.
> >  >
> >  >       Configuration Sequence Number
> >  >          Specifies a 4 octet unsigned configuration sequence
> >  > number that
> >  >          identifies the configuration state of the sending
> >  > LSR.  Used by
> >  >          the receiving LSR to detect configuration changes on the
> >  >          sending LSR.
> >  >
> >  >       IPv6 Transport Address
> >  >          Specifies the IPv6 address to be used for the
> >  > sending LSR when
> >  >          opening the LDP session TCP connection.  If 
> this optional TLV
> >  >          is not present the IPv6 source address for the 
> UDP packet
> >  >          carrying the Hello SHOULD be used.
> >  >
> >  > We will then need to change the above section too.
> >
> >  #bt: As noted above my suggestion is to allow an optional 
> IPv4 Transport
> >  Address TLV in Hello's carried by IPv4 packets and an optional IPv6
> >  Transport Address TLV in Hello's carried by IPv6 packets.  
> I think this
> >  is in the spirit of the rfc5036 text quoted above.
> >
> >
> >  > >  * Page 6, Section 7.2  Session Initialization
> >  > >
> >  > >  My opinion is that IPv6 label distribution should be
> >  > assumed to be "off"
> >  > >  for an LDP session until explicitly enabled by the 
> LDP capability
> >  > >  mechanism.
> >  > >
> >  > >  This is the approach for all "new" FEC types (e.g., the
> >  > mLDP FEC types),
> >  > >  and had the capability mechanism been part of the baseline
> >  > LDP spec it
> >  > >  would have been the case for IPv4 and the AToM/L2vpn set
> >  > of FEC types.
> >  > VM>> OK, will do this part. We had left it because we 
> thought it was a
> >  > configuration option local to the router in question.
> >
> >  #bt: I agree that it is a configuration option.  If IPv6 LDP label
> >  distribution is configured on a router then it would advertise the
> >  corresponding capability in its Initialization message as part of
> >  session establishment.
> >
> >
> >  > >  * Page 8, Section 8.1 Normative References
> >  > >
> >  > >  rfc5036 is missing from the list of normative references.
> >  > VM>> That is a big gaffee and will be corrected.
> >
> 
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Vishwas Manral | 5 Mar 23:15 2008
Picon

Re: draft-manral-mpls-ldp-ipv6

Hi Bob,

>  > VM>> It would be nice, if we knew the capability of the neighbor.
>  > However as we do not know whether the neighbor supports both stacks or
>  > not (unlike protocols like BGP the peer address is not configured but
>  > actually discovered), we may have to start sending both the Hello's.
>  #bt: One approach would be to make that explicit in the Hello's (not
>  sure that we want to go there).  The other is to wait and see what kinds
>  of Hello's are received from the peer.
VM>> That is not possible because if 2 routers come up both may be
waiting for the other to send Hello's first.

>  #bt: The decision process as to which Hello's to stop sending can be
>  described by a simple table with an entry for each of the cases.
VM>> That idea is correct. However this may only be applicable to P2P
links as an option.

Not sure about how it would work for Multi-Access links, as on
Multi-Access links the peers may come up or down at any point of time.

Thanks,
Vishwas

On Wed, Mar 5, 2008 at 1:03 PM, Bob Thomas (rhthomas)
<rhthomas <at> cisco.com> wrote:
> Hi Vishal,
>
>  Yes, I think we are converging ...
>
>  Follow up inline - search for #bt.
>
>
>  Bob
>
>
>  > -----Original Message-----
>  > From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com]
>
> > Sent: Wednesday, March 05, 2008 3:09 PM
>  > To: Bob Thomas (rhthomas)
>  > Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; mpls <at> ietf.org
>
>
> > Subject: Re: [mpls] draft-manral-mpls-ldp-ipv6
>  >
>  > Hi Bob,
>  >
>  > I think we have narrowed down the differences further then.:) Your
>  > comments have been helpful.
>  >
>  > >  #bt: Actually my intention was to suggest that we allow an
>  > optional IPv4
>  > >  Transport Address TLV (but NOT an IPv6 Transport Address
>  > TLV) in a Hello
>  > >  carried in an IPv4 packet and an optional IPv6 Transport
>  > Address TLV
>  > >  (but NOT an IPv4 Transport Address TLV) in a Hello carried
>  > by an IPv6
>  > >  packet.
>  > >
>  > >  That is, there would be at most 1 Transport Address TLV in a Hello
>  > >  message.
>  > VM>> I guess the draft intends to state exactly that. We will clarify
>  > it further.
>  >
>  > >  #bt: I think that it is unnecessary to send both IPv4 and
>  > IPv6 packets
>  > >  carrying Hello's over a point-to-point link between two
>  > LSRs.  A single
>  > >  packet type (IPv4 packet carrying an IPv4 Hello or IPv6
>  > packet carrying
>  > >  an IPv6 Hello) should be sufficient.
>  > VM>> It would be nice, if we knew the capability of the neighbor.
>  > However as we do not know whether the neighbor supports both stacks or
>  > not (unlike protocols like BGP the peer address is not configured but
>  > actually discovered), we may have to start sending both the Hello's.
>
>  #bt: One approach would be to make that explicit in the Hello's (not
>  sure that we want to go there).  The other is to wait and see what kinds
>  of Hello's are received from the peer.
>
>
>
>  > After that we can decide to drop a Hello's adjacency (if we have two),
>  > but then again we will need to have priority of which one to drop (so
>  > that we do it consistently - and we do not have two sides of the
>  > adjacency dropping different Hello adjacencies). I thought it would be
>  > good to allow both. Do you see any other issue besides the load of the
>  > extra Hello (added resiliency is gained too though).
>
>  #bt: The decision process as to which Hello's to stop sending can be
>  described by a simple table with an entry for each of the cases.
>
>  I'm not convinced that sending 2 types of Hello's on a link is more
>  resilient than sending a single type of hello's twice as frequently
>  (unless the concern is about the reliability of the code generating,
>  sending, receiving and processing hello's of a given type).
>
>  My goal is to eliminate Hello's that are unnecessary.
>
>
>
>
>  > I guess the above is the main point of difference between us
>  > right now.
>  >
>  > Thanks,
>  > Vishwas
>  >
>  >
>  > On Wed, Mar 5, 2008 at 11:48 AM, Bob Thomas (rhthomas)
>  > <rhthomas <at> cisco.com> wrote:
>  > > [Note that I corrected the spelling of the draft name in the Subject
>  > >  field]
>  > >
>  > >  Hi Vishwas,
>  > >
>  > >  Just a few follow up comments in line.  Search for #bt.
>  > >
>  > >  Bob
>  > >
>  > >
>  > >  > -----Original Message-----
>  > >  > From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com]
>  > >  > Sent: Wednesday, March 05, 2008 2:00 PM
>  > >  > To: Bob Thomas (rhthomas)
>  > >  > Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; mpls <at> ietf.org
>  > >  > Subject: Re: [mpls] draft-manral-mls-ldp-ipv6
>  > >  >
>  > >  > Hi Bob,
>  > >  >
>  > >  > Thanks a lot for the comments. The comments are very helpful.
>  > >  >
>  > >  > The biggest change you suggest of allowing multiple
>  > Transport Address
>  > >  > TLV's is something that will require more updates to the
>  > draft, as
>  > >  > RFC5036 assumes only a single Transport address TLV in
>  > the Hello. Have
>  > >  > a look and do let me know what you think.
>  > >
>  > >  #bt: Actually my intention was to suggest that we allow an
>  > optional IPv4
>  > >  Transport Address TLV (but NOT an IPv6 Transport Address
>  > TLV) in a Hello
>  > >  carried in an IPv4 packet and an optional IPv6 Transport
>  > Address TLV
>  > >  (but NOT an IPv4 Transport Address TLV) in a Hello carried
>  > by an IPv6
>  > >  packet.
>  > >
>  > >  That is, there would be at most 1 Transport Address TLV in a Hello
>  > >  message.
>  > >
>  > >
>  > >  > Please see my comments inline in the draft.
>  > >  >
>  > >  > On Wed, Mar 5, 2008 at 10:36 AM, Bob Thomas (rhthomas)
>  > >  > <rhthomas <at> cisco.com> wrote:
>  > >  >
>  > >  > >  * Page 2, Section 2.  LSP mapping procedures
>  > >  > >
>  > >  > >  Suggest the following wording for the bulleted item:
>  > >  > >
>  > >  > >       -  If it is known that a packet must traverse a
>  > >  > particular egress
>  > >  > >          router, and there is an LSP that has an
>  > Address Prefix FEC
>  > >  > >          element that is an IPv4 or IPv6 address of that
>  > >  > router, then
>  > >  > >          the packet is mapped to that LSP.  The procedure for
>  > >  > >          obtaining this knowledge is beyond the scope of this
>  > >  > >          document.
>  > >  > VM>> Will change to the wording you define.
>  > >  >
>  > >  > >
>  > >  > >  * Page 4, Section 4.  LDP Discovery
>  > >  > >
>  > >  > >  Suggest replacing "LSR's label swithing peers" with
>  > "LDP peers".
>  > >  > VM>> The sentence is actually taked from Section 2.4 of
>  > RFC5036. Will
>  > >  > change it however.
>  > >  >
>  > >  > >
>  > >  > >  * Page 4, Section 4.1.  Basic Discovery Mechanism
>  > >  > >
>  > >  > >  For LDP peers connected by a single point-to-point link
>  > >  > aren't Hello
>  > >  > >  messages for a single address family (either IPv4 or IPv6)
>  > >  > sufficient?
>  > >  > >
>  > >  > >  Also, the term "socket" is not defined in the context of
>  > >  > this draft.
>  > >  > >  The draft should restrict itself to talking about formats
>  > >  > of packets on
>  > >  > >  the wire, rather than about implementation read/write
>  > concepts.
>  > >  > VM>> I agree. Does the wording below help:
>  > >  >
>  > >  >    In a dual stack case where the interface has both IPv4 as
>  > >  > well as IPv6
>  > >  >    configured hellos will be sent for both IPv4 and IPv6 for
>  > >  > every label
>  > >  >    space.
>  > >
>  > >  #bt: I think that it is unnecessary to send both IPv4 and
>  > IPv6 packets
>  > >  carrying Hello's over a point-to-point link between two
>  > LSRs.  A single
>  > >  packet type (IPv4 packet carrying an IPv4 Hello or IPv6
>  > packet carrying
>  > >  an IPv6 Hello) should be sufficient.
>  > >
>  > >
>  > >  > >  * Page 5, Section 4.2 Extended Discovery Mechanism
>  > >  > >
>  > >  > >    "As Targeted Hellos will be sent to a particular
>  > preconfigured
>  > >  > >  address,
>  > >  > >     we send the Hello only the socket of the same address
>  > >  > family as the
>  > >  > >     configured address. If the address is configured for
>  > >  > both IPv4 and
>  > >  > >  IPv6
>  > >  > >     in that case we can send Hellos on the both IPv4 and
>  > >  > IPv6 sockets."
>  > >  > >
>  > >  > >  I'm not sure what it means for an "address" to be
>  > >  > "configured for both
>  > >  > >  IPv4 and IPv6".  Assuming that it means that targeted
>  > Hello's are
>  > >  > >  targeted for 2 addresses, one of which is an IPv4 address
>  > >  > and the other
>  > >  > >  of which is an IPv6 address, without inspecting topology
>  > >  > information
>  > >  > >  gleaned from an IGP how could a router determine if 2 such
>  > >  > addresses are
>  > >  > >  for the same target?
>  > >  > VM>> You are right. It was a bad attempt to make a
>  > distinction between
>  > >  > the Extended Discovery and the Basic discovery mechanism. I will
>  > >  > reword this further.
>  > >  >
>  > >  > >  * Page 5, Section 5. Maintaining Hello Adjacencies
>  > >  > >
>  > >  > >    "An LDP session has multiple Hello adjacencies when a
>  > >  > pair of LSRs is
>  > >  > >     connected by multiple links that share the same
>  > label space; for
>  > >  > >     example, multiple PPP links between a pair of routers.
>  > >  > We can also
>  > >  > >  have
>  > >  > >     multiple Hello adjacencies in the dual stack case where
>  > >  > we have IPv4
>  > >  > >     and IPv6 Hellos exchanged for the same label space
>  > >  > between a pair of
>  > >  > >     LSR's."
>  > >  > >
>  > >  > >  For peers directly connected by a single point-2-point
>  > >  > link Hello's for
>  > >  > >  a single address family should be sufficient to allow
>  > >  > estalishment of an
>  > >  > >  LDP session supporting label advertisement for both
>  > IPv4 and IPv6
>  > >  > >  addresses families.
>  > >  > >
>  > >  > >  For a set of peers connected by a single multi-access link
>  > >  > it may not be
>  > >  > >  practical in general to limit Hello's to a single
>  > address family.
>  > >  > >
>  > >  > >  For targeted peers it may be difficult to prevent multiple
>  > >  > hello targets
>  > >  > >  for the same peer.
>  > >  > VM> That is correct, hellos for a single address family should be
>  > >  > sufficient in the case that the other end also supports the same.
>  > >  > However this is meant to work for the case where we have
>  > say an IPv6
>  > >  > only or IPv4 router as a peer.
>  > >
>  > >  #bt: Agreed, discovery needs to work when peering is with
>  > an IPv4-only
>  > >  or an IPv6-only peer.  However, I think the discovery
>  > procedures can be
>  > >  defined in such a way that it is unnecessary to send both
>  > IPv6 and IPv4
>  > >  Hello's between 2 peers on a point-to-point link.  For
>  > example, if R1
>  > >  supports both IPv4 and IPv6 and R2 supports only IPv4, R1
>  > can quickly
>  > >  discover that it is receiving IPv4 Hellos from R2 and send
>  > only IPv4
>  > >  Hellos to R2 (if it is not already doing so).
>  > >
>  > >  > >  * Page 5, Section 6.  Hello Message Procedures
>  > >  > >
>  > >  > >    "However [RFC5036] states does not define the behavior
>  > >  > of LDP in case
>  > >  > >
>  > >  > >     both IPv4 and IPv6 transport addresses are sent in
>  > the packet.
>  > >  > >
>  > >  > >     [RFC5036] seems to assume that only one such TLV
>  > is received
>  > >  > >     and specifies the behavior based on such a case."
>  > >  > >
>  > >  > >  One Transport Address TLV per Hello message is sufficient
>  > >  > and should be
>  > >  > >  the goal.
>  > >  > >
>  > >  > >  A reasonable approach would be to permit an optional
>  > IPv4 Transport
>  > >  > >  Address TLV (but not an IPv6 Transport Address TLV)
>  > when the Hello
>  > >  > >  message is carried in an IPv4 packet and to permit an
>  > optional IPv6
>  > >  > >  Transport Address TLV (but not an IPv4 Transport Address
>  > >  > TLV) when the
>  > >  > >  Hellos message is carried in an IPv6 packet.
>  > >  > VM> Our attempt is to allow only one Transport Address TLV in the
>  > >  > hello's. We currently allow receiving multiple TLV's,
>  > but we send only
>  > >  > a single TLV. We have not yet got the optional part that
>  > you mention.
>  > >  > the reason being that RFC5036 states the below:
>  > >  >
>  > >  >       IPv4 Transport Address
>  > >  >          Specifies the IPv4 address to be used for the
>  > >  > sending LSR when
>  > >  >          opening the LDP session TCP connection.  If
>  > this optional TLV
>  > >  >          is not present, the IPv4 source address for the
>  > UDP packet
>  > >  >          carrying the Hello SHOULD be used.
>  > >  >
>  > >  >       Configuration Sequence Number
>  > >  >          Specifies a 4 octet unsigned configuration sequence
>  > >  > number that
>  > >  >          identifies the configuration state of the sending
>  > >  > LSR.  Used by
>  > >  >          the receiving LSR to detect configuration changes on the
>  > >  >          sending LSR.
>  > >  >
>  > >  >       IPv6 Transport Address
>  > >  >          Specifies the IPv6 address to be used for the
>  > >  > sending LSR when
>  > >  >          opening the LDP session TCP connection.  If
>  > this optional TLV
>  > >  >          is not present the IPv6 source address for the
>  > UDP packet
>  > >  >          carrying the Hello SHOULD be used.
>  > >  >
>  > >  > We will then need to change the above section too.
>  > >
>  > >  #bt: As noted above my suggestion is to allow an optional
>  > IPv4 Transport
>  > >  Address TLV in Hello's carried by IPv4 packets and an optional IPv6
>  > >  Transport Address TLV in Hello's carried by IPv6 packets.
>  > I think this
>  > >  is in the spirit of the rfc5036 text quoted above.
>  > >
>  > >
>  > >  > >  * Page 6, Section 7.2  Session Initialization
>  > >  > >
>  > >  > >  My opinion is that IPv6 label distribution should be
>  > >  > assumed to be "off"
>  > >  > >  for an LDP session until explicitly enabled by the
>  > LDP capability
>  > >  > >  mechanism.
>  > >  > >
>  > >  > >  This is the approach for all "new" FEC types (e.g., the
>  > >  > mLDP FEC types),
>  > >  > >  and had the capability mechanism been part of the baseline
>  > >  > LDP spec it
>  > >  > >  would have been the case for IPv4 and the AToM/L2vpn set
>  > >  > of FEC types.
>  > >  > VM>> OK, will do this part. We had left it because we
>  > thought it was a
>  > >  > configuration option local to the router in question.
>  > >
>  > >  #bt: I agree that it is a configuration option.  If IPv6 LDP label
>  > >  distribution is configured on a router then it would advertise the
>  > >  corresponding capability in its Initialization message as part of
>  > >  session establishment.
>  > >
>  > >
>  > >  > >  * Page 8, Section 8.1 Normative References
>  > >  > >
>  > >  > >  rfc5036 is missing from the list of normative references.
>  > >  > VM>> That is a big gaffee and will be corrected.
>  > >
>  >
>
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Bob Thomas (rhthomas | 5 Mar 23:45 2008
Picon

Re: draft-manral-mpls-ldp-ipv6

Hi Vishal,

Some comments in line - search for #bt:

Bob

> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com] 
> Sent: Wednesday, March 05, 2008 5:16 PM
> To: Bob Thomas (rhthomas)
> Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; mpls <at> ietf.org
> Subject: Re: [mpls] draft-manral-mpls-ldp-ipv6
> 
> Hi Bob,
> 
> >  > VM>> It would be nice, if we knew the capability of the neighbor.
> >  > However as we do not know whether the neighbor supports 
> both stacks or
> >  > not (unlike protocols like BGP the peer address is not 
> configured but
> >  > actually discovered), we may have to start sending both 
> the Hello's.
> >  #bt: One approach would be to make that explicit in the 
> Hello's (not
> >  sure that we want to go there).  The other is to wait and 
> see what kinds
> >  of Hello's are received from the peer.
> VM>> That is not possible because if 2 routers come up both may be
> waiting for the other to send Hello's first.

#bt: I can see that I didn't precisely say what I meant.  What I meant
was to start sending Hello's based on local configuration (e.g., both
IPv4 and IPv6 if both are configured) and to modify what you send based
on the Hello's you receive over several Hello "cycles".  For example, if
after several cycles you receive only IPv6 Hello packets continue
sending the IPv6 Hellos and cease sending the IPv4 Hellos.

> >  #bt: The decision process as to which Hello's to stop 
> sending can be
> >  described by a simple table with an entry for each of the cases.
> VM>> That idea is correct. However this may only be applicable to P2P
> links as an option.

#bt: Yes, that is why my original message said:

"For peers directly connected by a single point-2-point link Hello's for
a single address family should be sufficient to allow estalishment of an
LDP session supporting label advertisement for both IPv4 and IPv6
addresses families.

For a set of peers connected by a single multi-access link it may not be
practical in general to limit Hello's to a single address family.

For targeted peers it may be difficult to prevent multiple hello targets
for the same peer."

> Not sure about how it would work for Multi-Access links, as on
> Multi-Access links the peers may come up or down at any point of time.

#bt: Furthermore, in general (but perhaps not often in practice) some
peers may be IPv4 only, some IPv6 only, and some IPv4 and IPv6.

> Thanks,
> Vishwas
> 
> On Wed, Mar 5, 2008 at 1:03 PM, Bob Thomas (rhthomas)
> <rhthomas <at> cisco.com> wrote:
> > Hi Vishal,
> >
> >  Yes, I think we are converging ...
> >
> >  Follow up inline - search for #bt.
> >
> >
> >  Bob
> >
> >
> >  > -----Original Message-----
> >  > From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com]
> >
> > > Sent: Wednesday, March 05, 2008 3:09 PM
> >  > To: Bob Thomas (rhthomas)
> >  > Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; mpls <at> ietf.org
> >
> >
> > > Subject: Re: [mpls] draft-manral-mpls-ldp-ipv6
> >  >
> >  > Hi Bob,
> >  >
> >  > I think we have narrowed down the differences further 
> then.:) Your
> >  > comments have been helpful.
> >  >
> >  > >  #bt: Actually my intention was to suggest that we allow an
> >  > optional IPv4
> >  > >  Transport Address TLV (but NOT an IPv6 Transport Address
> >  > TLV) in a Hello
> >  > >  carried in an IPv4 packet and an optional IPv6 Transport
> >  > Address TLV
> >  > >  (but NOT an IPv4 Transport Address TLV) in a Hello carried
> >  > by an IPv6
> >  > >  packet.
> >  > >
> >  > >  That is, there would be at most 1 Transport Address 
> TLV in a Hello
> >  > >  message.
> >  > VM>> I guess the draft intends to state exactly that. We 
> will clarify
> >  > it further.
> >  >
> >  > >  #bt: I think that it is unnecessary to send both IPv4 and
> >  > IPv6 packets
> >  > >  carrying Hello's over a point-to-point link between two
> >  > LSRs.  A single
> >  > >  packet type (IPv4 packet carrying an IPv4 Hello or IPv6
> >  > packet carrying
> >  > >  an IPv6 Hello) should be sufficient.
> >  > VM>> It would be nice, if we knew the capability of the neighbor.
> >  > However as we do not know whether the neighbor supports 
> both stacks or
> >  > not (unlike protocols like BGP the peer address is not 
> configured but
> >  > actually discovered), we may have to start sending both 
> the Hello's.
> >
> >  #bt: One approach would be to make that explicit in the 
> Hello's (not
> >  sure that we want to go there).  The other is to wait and 
> see what kinds
> >  of Hello's are received from the peer.
> >
> >
> >
> >  > After that we can decide to drop a Hello's adjacency (if 
> we have two),
> >  > but then again we will need to have priority of which 
> one to drop (so
> >  > that we do it consistently - and we do not have two sides of the
> >  > adjacency dropping different Hello adjacencies). I 
> thought it would be
> >  > good to allow both. Do you see any other issue besides 
> the load of the
> >  > extra Hello (added resiliency is gained too though).
> >
> >  #bt: The decision process as to which Hello's to stop 
> sending can be
> >  described by a simple table with an entry for each of the cases.
> >
> >  I'm not convinced that sending 2 types of Hello's on a link is more
> >  resilient than sending a single type of hello's twice as frequently
> >  (unless the concern is about the reliability of the code 
> generating,
> >  sending, receiving and processing hello's of a given type).
> >
> >  My goal is to eliminate Hello's that are unnecessary.
> >
> >
> >
> >
> >  > I guess the above is the main point of difference between us
> >  > right now.
> >  >
> >  > Thanks,
> >  > Vishwas
> >  >
> >  >
> >  > On Wed, Mar 5, 2008 at 11:48 AM, Bob Thomas (rhthomas)
> >  > <rhthomas <at> cisco.com> wrote:
> >  > > [Note that I corrected the spelling of the draft name 
> in the Subject
> >  > >  field]
> >  > >
> >  > >  Hi Vishwas,
> >  > >
> >  > >  Just a few follow up comments in line.  Search for #bt.
> >  > >
> >  > >  Bob
> >  > >
> >  > >
> >  > >  > -----Original Message-----
> >  > >  > From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com]
> >  > >  > Sent: Wednesday, March 05, 2008 2:00 PM
> >  > >  > To: Bob Thomas (rhthomas)
> >  > >  > Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; 
> mpls <at> ietf.org
> >  > >  > Subject: Re: [mpls] draft-manral-mls-ldp-ipv6
> >  > >  >
> >  > >  > Hi Bob,
> >  > >  >
> >  > >  > Thanks a lot for the comments. The comments are 
> very helpful.
> >  > >  >
> >  > >  > The biggest change you suggest of allowing multiple
> >  > Transport Address
> >  > >  > TLV's is something that will require more updates to the
> >  > draft, as
> >  > >  > RFC5036 assumes only a single Transport address TLV in
> >  > the Hello. Have
> >  > >  > a look and do let me know what you think.
> >  > >
> >  > >  #bt: Actually my intention was to suggest that we allow an
> >  > optional IPv4
> >  > >  Transport Address TLV (but NOT an IPv6 Transport Address
> >  > TLV) in a Hello
> >  > >  carried in an IPv4 packet and an optional IPv6 Transport
> >  > Address TLV
> >  > >  (but NOT an IPv4 Transport Address TLV) in a Hello carried
> >  > by an IPv6
> >  > >  packet.
> >  > >
> >  > >  That is, there would be at most 1 Transport Address 
> TLV in a Hello
> >  > >  message.
> >  > >
> >  > >
> >  > >  > Please see my comments inline in the draft.
> >  > >  >
> >  > >  > On Wed, Mar 5, 2008 at 10:36 AM, Bob Thomas (rhthomas)
> >  > >  > <rhthomas <at> cisco.com> wrote:
> >  > >  >
> >  > >  > >  * Page 2, Section 2.  LSP mapping procedures
> >  > >  > >
> >  > >  > >  Suggest the following wording for the bulleted item:
> >  > >  > >
> >  > >  > >       -  If it is known that a packet must traverse a
> >  > >  > particular egress
> >  > >  > >          router, and there is an LSP that has an
> >  > Address Prefix FEC
> >  > >  > >          element that is an IPv4 or IPv6 address of that
> >  > >  > router, then
> >  > >  > >          the packet is mapped to that LSP.  The 
> procedure for
> >  > >  > >          obtaining this knowledge is beyond the 
> scope of this
> >  > >  > >          document.
> >  > >  > VM>> Will change to the wording you define.
> >  > >  >
> >  > >  > >
> >  > >  > >  * Page 4, Section 4.  LDP Discovery
> >  > >  > >
> >  > >  > >  Suggest replacing "LSR's label swithing peers" with
> >  > "LDP peers".
> >  > >  > VM>> The sentence is actually taked from Section 2.4 of
> >  > RFC5036. Will
> >  > >  > change it however.
> >  > >  >
> >  > >  > >
> >  > >  > >  * Page 4, Section 4.1.  Basic Discovery Mechanism
> >  > >  > >
> >  > >  > >  For LDP peers connected by a single point-to-point link
> >  > >  > aren't Hello
> >  > >  > >  messages for a single address family (either 
> IPv4 or IPv6)
> >  > >  > sufficient?
> >  > >  > >
> >  > >  > >  Also, the term "socket" is not defined in the context of
> >  > >  > this draft.
> >  > >  > >  The draft should restrict itself to talking about formats
> >  > >  > of packets on
> >  > >  > >  the wire, rather than about implementation read/write
> >  > concepts.
> >  > >  > VM>> I agree. Does the wording below help:
> >  > >  >
> >  > >  >    In a dual stack case where the interface has both IPv4 as
> >  > >  > well as IPv6
> >  > >  >    configured hellos will be sent for both IPv4 and IPv6 for
> >  > >  > every label
> >  > >  >    space.
> >  > >
> >  > >  #bt: I think that it is unnecessary to send both IPv4 and
> >  > IPv6 packets
> >  > >  carrying Hello's over a point-to-point link between two
> >  > LSRs.  A single
> >  > >  packet type (IPv4 packet carrying an IPv4 Hello or IPv6
> >  > packet carrying
> >  > >  an IPv6 Hello) should be sufficient.
> >  > >
> >  > >
> >  > >  > >  * Page 5, Section 4.2 Extended Discovery Mechanism
> >  > >  > >
> >  > >  > >    "As Targeted Hellos will be sent to a particular
> >  > preconfigured
> >  > >  > >  address,
> >  > >  > >     we send the Hello only the socket of the same address
> >  > >  > family as the
> >  > >  > >     configured address. If the address is configured for
> >  > >  > both IPv4 and
> >  > >  > >  IPv6
> >  > >  > >     in that case we can send Hellos on the both IPv4 and
> >  > >  > IPv6 sockets."
> >  > >  > >
> >  > >  > >  I'm not sure what it means for an "address" to be
> >  > >  > "configured for both
> >  > >  > >  IPv4 and IPv6".  Assuming that it means that targeted
> >  > Hello's are
> >  > >  > >  targeted for 2 addresses, one of which is an IPv4 address
> >  > >  > and the other
> >  > >  > >  of which is an IPv6 address, without inspecting topology
> >  > >  > information
> >  > >  > >  gleaned from an IGP how could a router determine 
> if 2 such
> >  > >  > addresses are
> >  > >  > >  for the same target?
> >  > >  > VM>> You are right. It was a bad attempt to make a
> >  > distinction between
> >  > >  > the Extended Discovery and the Basic discovery 
> mechanism. I will
> >  > >  > reword this further.
> >  > >  >
> >  > >  > >  * Page 5, Section 5. Maintaining Hello Adjacencies
> >  > >  > >
> >  > >  > >    "An LDP session has multiple Hello adjacencies when a
> >  > >  > pair of LSRs is
> >  > >  > >     connected by multiple links that share the same
> >  > label space; for
> >  > >  > >     example, multiple PPP links between a pair of routers.
> >  > >  > We can also
> >  > >  > >  have
> >  > >  > >     multiple Hello adjacencies in the dual stack 
> case where
> >  > >  > we have IPv4
> >  > >  > >     and IPv6 Hellos exchanged for the same label space
> >  > >  > between a pair of
> >  > >  > >     LSR's."
> >  > >  > >
> >  > >  > >  For peers directly connected by a single point-2-point
> >  > >  > link Hello's for
> >  > >  > >  a single address family should be sufficient to allow
> >  > >  > estalishment of an
> >  > >  > >  LDP session supporting label advertisement for both
> >  > IPv4 and IPv6
> >  > >  > >  addresses families.
> >  > >  > >
> >  > >  > >  For a set of peers connected by a single 
> multi-access link
> >  > >  > it may not be
> >  > >  > >  practical in general to limit Hello's to a single
> >  > address family.
> >  > >  > >
> >  > >  > >  For targeted peers it may be difficult to 
> prevent multiple
> >  > >  > hello targets
> >  > >  > >  for the same peer.
> >  > >  > VM> That is correct, hellos for a single address 
> family should be
> >  > >  > sufficient in the case that the other end also 
> supports the same.
> >  > >  > However this is meant to work for the case where we have
> >  > say an IPv6
> >  > >  > only or IPv4 router as a peer.
> >  > >
> >  > >  #bt: Agreed, discovery needs to work when peering is with
> >  > an IPv4-only
> >  > >  or an IPv6-only peer.  However, I think the discovery
> >  > procedures can be
> >  > >  defined in such a way that it is unnecessary to send both
> >  > IPv6 and IPv4
> >  > >  Hello's between 2 peers on a point-to-point link.  For
> >  > example, if R1
> >  > >  supports both IPv4 and IPv6 and R2 supports only IPv4, R1
> >  > can quickly
> >  > >  discover that it is receiving IPv4 Hellos from R2 and send
> >  > only IPv4
> >  > >  Hellos to R2 (if it is not already doing so).
> >  > >
> >  > >  > >  * Page 5, Section 6.  Hello Message Procedures
> >  > >  > >
> >  > >  > >    "However [RFC5036] states does not define the behavior
> >  > >  > of LDP in case
> >  > >  > >
> >  > >  > >     both IPv4 and IPv6 transport addresses are sent in
> >  > the packet.
> >  > >  > >
> >  > >  > >     [RFC5036] seems to assume that only one such TLV
> >  > is received
> >  > >  > >     and specifies the behavior based on such a case."
> >  > >  > >
> >  > >  > >  One Transport Address TLV per Hello message is sufficient
> >  > >  > and should be
> >  > >  > >  the goal.
> >  > >  > >
> >  > >  > >  A reasonable approach would be to permit an optional
> >  > IPv4 Transport
> >  > >  > >  Address TLV (but not an IPv6 Transport Address TLV)
> >  > when the Hello
> >  > >  > >  message is carried in an IPv4 packet and to permit an
> >  > optional IPv6
> >  > >  > >  Transport Address TLV (but not an IPv4 Transport Address
> >  > >  > TLV) when the
> >  > >  > >  Hellos message is carried in an IPv6 packet.
> >  > >  > VM> Our attempt is to allow only one Transport 
> Address TLV in the
> >  > >  > hello's. We currently allow receiving multiple TLV's,
> >  > but we send only
> >  > >  > a single TLV. We have not yet got the optional part that
> >  > you mention.
> >  > >  > the reason being that RFC5036 states the below:
> >  > >  >
> >  > >  >       IPv4 Transport Address
> >  > >  >          Specifies the IPv4 address to be used for the
> >  > >  > sending LSR when
> >  > >  >          opening the LDP session TCP connection.  If
> >  > this optional TLV
> >  > >  >          is not present, the IPv4 source address for the
> >  > UDP packet
> >  > >  >          carrying the Hello SHOULD be used.
> >  > >  >
> >  > >  >       Configuration Sequence Number
> >  > >  >          Specifies a 4 octet unsigned configuration sequence
> >  > >  > number that
> >  > >  >          identifies the configuration state of the sending
> >  > >  > LSR.  Used by
> >  > >  >          the receiving LSR to detect configuration 
> changes on the
> >  > >  >          sending LSR.
> >  > >  >
> >  > >  >       IPv6 Transport Address
> >  > >  >          Specifies the IPv6 address to be used for the
> >  > >  > sending LSR when
> >  > >  >          opening the LDP session TCP connection.  If
> >  > this optional TLV
> >  > >  >          is not present the IPv6 source address for the
> >  > UDP packet
> >  > >  >          carrying the Hello SHOULD be used.
> >  > >  >
> >  > >  > We will then need to change the above section too.
> >  > >
> >  > >  #bt: As noted above my suggestion is to allow an optional
> >  > IPv4 Transport
> >  > >  Address TLV in Hello's carried by IPv4 packets and an 
> optional IPv6
> >  > >  Transport Address TLV in Hello's carried by IPv6 packets.
> >  > I think this
> >  > >  is in the spirit of the rfc5036 text quoted above.
> >  > >
> >  > >
> >  > >  > >  * Page 6, Section 7.2  Session Initialization
> >  > >  > >
> >  > >  > >  My opinion is that IPv6 label distribution should be
> >  > >  > assumed to be "off"
> >  > >  > >  for an LDP session until explicitly enabled by the
> >  > LDP capability
> >  > >  > >  mechanism.
> >  > >  > >
> >  > >  > >  This is the approach for all "new" FEC types (e.g., the
> >  > >  > mLDP FEC types),
> >  > >  > >  and had the capability mechanism been part of 
> the baseline
> >  > >  > LDP spec it
> >  > >  > >  would have been the case for IPv4 and the AToM/L2vpn set
> >  > >  > of FEC types.
> >  > >  > VM>> OK, will do this part. We had left it because we
> >  > thought it was a
> >  > >  > configuration option local to the router in question.
> >  > >
> >  > >  #bt: I agree that it is a configuration option.  If 
> IPv6 LDP label
> >  > >  distribution is configured on a router then it would 
> advertise the
> >  > >  corresponding capability in its Initialization 
> message as part of
> >  > >  session establishment.
> >  > >
> >  > >
> >  > >  > >  * Page 8, Section 8.1 Normative References
> >  > >  > >
> >  > >  > >  rfc5036 is missing from the list of normative references.
> >  > >  > VM>> That is a big gaffee and will be corrected.
> >  > >
> >  >
> >
> 
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Vishwas Manral | 5 Mar 23:48 2008
Picon

Re: draft-manral-mpls-ldp-ipv6

Thanks Bob.

I will incorporate the comments and send you the draft for review.
will try to do that before the IETF.

-Vishwas

On Wed, Mar 5, 2008 at 2:45 PM, Bob Thomas (rhthomas)
<rhthomas <at> cisco.com> wrote:
> Hi Vishal,
>
>  Some comments in line - search for #bt:
>
>
>  Bob
>
>  > -----Original Message-----
>  > From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com]
>
> > Sent: Wednesday, March 05, 2008 5:16 PM
>  > To: Bob Thomas (rhthomas)
>  > Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; mpls <at> ietf.org
>  > Subject: Re: [mpls] draft-manral-mpls-ldp-ipv6
>  >
>  > Hi Bob,
>  >
>
> > >  > VM>> It would be nice, if we knew the capability of the neighbor.
>  > >  > However as we do not know whether the neighbor supports
>  > both stacks or
>  > >  > not (unlike protocols like BGP the peer address is not
>  > configured but
>  > >  > actually discovered), we may have to start sending both
>  > the Hello's.
>  > >  #bt: One approach would be to make that explicit in the
>  > Hello's (not
>  > >  sure that we want to go there).  The other is to wait and
>  > see what kinds
>  > >  of Hello's are received from the peer.
>  > VM>> That is not possible because if 2 routers come up both may be
>  > waiting for the other to send Hello's first.
>
>  #bt: I can see that I didn't precisely say what I meant.  What I meant
>  was to start sending Hello's based on local configuration (e.g., both
>  IPv4 and IPv6 if both are configured) and to modify what you send based
>  on the Hello's you receive over several Hello "cycles".  For example, if
>  after several cycles you receive only IPv6 Hello packets continue
>  sending the IPv6 Hellos and cease sending the IPv4 Hellos.
>
>
>
>  > >  #bt: The decision process as to which Hello's to stop
>  > sending can be
>  > >  described by a simple table with an entry for each of the cases.
>  > VM>> That idea is correct. However this may only be applicable to P2P
>  > links as an option.
>
>
> #bt: Yes, that is why my original message said:
>
>  "For peers directly connected by a single point-2-point link Hello's for
>  a single address family should be sufficient to allow estalishment of an
>  LDP session supporting label advertisement for both IPv4 and IPv6
>  addresses families.
>
>  For a set of peers connected by a single multi-access link it may not be
>  practical in general to limit Hello's to a single address family.
>
>  For targeted peers it may be difficult to prevent multiple hello targets
>  for the same peer."
>
>
>
> > Not sure about how it would work for Multi-Access links, as on
>  > Multi-Access links the peers may come up or down at any point of time.
>
>  #bt: Furthermore, in general (but perhaps not often in practice) some
>  peers may be IPv4 only, some IPv6 only, and some IPv4 and IPv6.
>
>
>
>
>  > Thanks,
>  > Vishwas
>  >
>  > On Wed, Mar 5, 2008 at 1:03 PM, Bob Thomas (rhthomas)
>  > <rhthomas <at> cisco.com> wrote:
>  > > Hi Vishal,
>  > >
>  > >  Yes, I think we are converging ...
>  > >
>  > >  Follow up inline - search for #bt.
>  > >
>  > >
>  > >  Bob
>  > >
>  > >
>  > >  > -----Original Message-----
>  > >  > From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com]
>  > >
>  > > > Sent: Wednesday, March 05, 2008 3:09 PM
>  > >  > To: Bob Thomas (rhthomas)
>  > >  > Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com; mpls <at> ietf.org
>  > >
>  > >
>  > > > Subject: Re: [mpls] draft-manral-mpls-ldp-ipv6
>  > >  >
>  > >  > Hi Bob,
>  > >  >
>  > >  > I think we have narrowed down the differences further
>  > then.:) Your
>  > >  > comments have been helpful.
>  > >  >
>  > >  > >  #bt: Actually my intention was to suggest that we allow an
>  > >  > optional IPv4
>  > >  > >  Transport Address TLV (but NOT an IPv6 Transport Address
>  > >  > TLV) in a Hello
>  > >  > >  carried in an IPv4 packet and an optional IPv6 Transport
>  > >  > Address TLV
>  > >  > >  (but NOT an IPv4 Transport Address TLV) in a Hello carried
>  > >  > by an IPv6
>  > >  > >  packet.
>  > >  > >
>  > >  > >  That is, there would be at most 1 Transport Address
>  > TLV in a Hello
>  > >  > >  message.
>  > >  > VM>> I guess the draft intends to state exactly that. We
>  > will clarify
>  > >  > it further.
>  > >  >
>  > >  > >  #bt: I think that it is unnecessary to send both IPv4 and
>  > >  > IPv6 packets
>  > >  > >  carrying Hello's over a point-to-point link between two
>  > >  > LSRs.  A single
>  > >  > >  packet type (IPv4 packet carrying an IPv4 Hello or IPv6
>  > >  > packet carrying
>  > >  > >  an IPv6 Hello) should be sufficient.
>  > >  > VM>> It would be nice, if we knew the capability of the neighbor.
>  > >  > However as we do not know whether the neighbor supports
>  > both stacks or
>  > >  > not (unlike protocols like BGP the peer address is not
>  > configured but
>  > >  > actually discovered), we may have to start sending both
>  > the Hello's.
>  > >
>  > >  #bt: One approach would be to make that explicit in the
>  > Hello's (not
>  > >  sure that we want to go there).  The other is to wait and
>  > see what kinds
>  > >  of Hello's are received from the peer.
>  > >
>  > >
>  > >
>  > >  > After that we can decide to drop a Hello's adjacency (if
>  > we have two),
>  > >  > but then again we will need to have priority of which
>  > one to drop (so
>  > >  > that we do it consistently - and we do not have two sides of the
>  > >  > adjacency dropping different Hello adjacencies). I
>  > thought it would be
>  > >  > good to allow both. Do you see any other issue besides
>  > the load of the
>  > >  > extra Hello (added resiliency is gained too though).
>  > >
>  > >  #bt: The decision process as to which Hello's to stop
>  > sending can be
>  > >  described by a simple table with an entry for each of the cases.
>  > >
>  > >  I'm not convinced that sending 2 types of Hello's on a link is more
>  > >  resilient than sending a single type of hello's twice as frequently
>  > >  (unless the concern is about the reliability of the code
>  > generating,
>  > >  sending, receiving and processing hello's of a given type).
>  > >
>  > >  My goal is to eliminate Hello's that are unnecessary.
>  > >
>  > >
>  > >
>  > >
>  > >  > I guess the above is the main point of difference between us
>  > >  > right now.
>  > >  >
>  > >  > Thanks,
>  > >  > Vishwas
>  > >  >
>  > >  >
>  > >  > On Wed, Mar 5, 2008 at 11:48 AM, Bob Thomas (rhthomas)
>  > >  > <rhthomas <at> cisco.com> wrote:
>  > >  > > [Note that I corrected the spelling of the draft name
>  > in the Subject
>  > >  > >  field]
>  > >  > >
>  > >  > >  Hi Vishwas,
>  > >  > >
>  > >  > >  Just a few follow up comments in line.  Search for #bt.
>  > >  > >
>  > >  > >  Bob
>  > >  > >
>  > >  > >
>  > >  > >  > -----Original Message-----
>  > >  > >  > From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com]
>  > >  > >  > Sent: Wednesday, March 05, 2008 2:00 PM
>  > >  > >  > To: Bob Thomas (rhthomas)
>  > >  > >  > Cc: vishwas <at> ipinfusion.com; rpapneja <at> isocore.com;
>  > mpls <at> ietf.org
>  > >  > >  > Subject: Re: [mpls] draft-manral-mls-ldp-ipv6
>  > >  > >  >
>  > >  > >  > Hi Bob,
>  > >  > >  >
>  > >  > >  > Thanks a lot for the comments. The comments are
>  > very helpful.
>  > >  > >  >
>  > >  > >  > The biggest change you suggest of allowing multiple
>  > >  > Transport Address
>  > >  > >  > TLV's is something that will require more updates to the
>  > >  > draft, as
>  > >  > >  > RFC5036 assumes only a single Transport address TLV in
>  > >  > the Hello. Have
>  > >  > >  > a look and do let me know what you think.
>  > >  > >
>  > >  > >  #bt: Actually my intention was to suggest that we allow an
>  > >  > optional IPv4
>  > >  > >  Transport Address TLV (but NOT an IPv6 Transport Address
>  > >  > TLV) in a Hello
>  > >  > >  carried in an IPv4 packet and an optional IPv6 Transport
>  > >  > Address TLV
>  > >  > >  (but NOT an IPv4 Transport Address TLV) in a Hello carried
>  > >  > by an IPv6
>  > >  > >  packet.
>  > >  > >
>  > >  > >  That is, there would be at most 1 Transport Address
>  > TLV in a Hello
>  > >  > >  message.
>  > >  > >
>  > >  > >
>  > >  > >  > Please see my comments inline in the draft.
>  > >  > >  >
>  > >  > >  > On Wed, Mar 5, 2008 at 10:36 AM, Bob Thomas (rhthomas)
>  > >  > >  > <rhthomas <at> cisco.com> wrote:
>  > >  > >  >
>  > >  > >  > >  * Page 2, Section 2.  LSP mapping procedures
>  > >  > >  > >
>  > >  > >  > >  Suggest the following wording for the bulleted item:
>  > >  > >  > >
>  > >  > >  > >       -  If it is known that a packet must traverse a
>  > >  > >  > particular egress
>  > >  > >  > >          router, and there is an LSP that has an
>  > >  > Address Prefix FEC
>  > >  > >  > >          element that is an IPv4 or IPv6 address of that
>  > >  > >  > router, then
>  > >  > >  > >          the packet is mapped to that LSP.  The
>  > procedure for
>  > >  > >  > >          obtaining this knowledge is beyond the
>  > scope of this
>  > >  > >  > >          document.
>  > >  > >  > VM>> Will change to the wording you define.
>  > >  > >  >
>  > >  > >  > >
>  > >  > >  > >  * Page 4, Section 4.  LDP Discovery
>  > >  > >  > >
>  > >  > >  > >  Suggest replacing "LSR's label swithing peers" with
>  > >  > "LDP peers".
>  > >  > >  > VM>> The sentence is actually taked from Section 2.4 of
>  > >  > RFC5036. Will
>  > >  > >  > change it however.
>  > >  > >  >
>  > >  > >  > >
>  > >  > >  > >  * Page 4, Section 4.1.  Basic Discovery Mechanism
>  > >  > >  > >
>  > >  > >  > >  For LDP peers connected by a single point-to-point link
>  > >  > >  > aren't Hello
>  > >  > >  > >  messages for a single address family (either
>  > IPv4 or IPv6)
>  > >  > >  > sufficient?
>  > >  > >  > >
>  > >  > >  > >  Also, the term "socket" is not defined in the context of
>  > >  > >  > this draft.
>  > >  > >  > >  The draft should restrict itself to talking about formats
>  > >  > >  > of packets on
>  > >  > >  > >  the wire, rather than about implementation read/write
>  > >  > concepts.
>  > >  > >  > VM>> I agree. Does the wording below help:
>  > >  > >  >
>  > >  > >  >    In a dual stack case where the interface has both IPv4 as
>  > >  > >  > well as IPv6
>  > >  > >  >    configured hellos will be sent for both IPv4 and IPv6 for
>  > >  > >  > every label
>  > >  > >  >    space.
>  > >  > >
>  > >  > >  #bt: I think that it is unnecessary to send both IPv4 and
>  > >  > IPv6 packets
>  > >  > >  carrying Hello's over a point-to-point link between two
>  > >  > LSRs.  A single
>  > >  > >  packet type (IPv4 packet carrying an IPv4 Hello or IPv6
>  > >  > packet carrying
>  > >  > >  an IPv6 Hello) should be sufficient.
>  > >  > >
>  > >  > >
>  > >  > >  > >  * Page 5, Section 4.2 Extended Discovery Mechanism
>  > >  > >  > >
>  > >  > >  > >    "As Targeted Hellos will be sent to a particular
>  > >  > preconfigured
>  > >  > >  > >  address,
>  > >  > >  > >     we send the Hello only the socket of the same address
>  > >  > >  > family as the
>  > >  > >  > >     configured address. If the address is configured for
>  > >  > >  > both IPv4 and
>  > >  > >  > >  IPv6
>  > >  > >  > >     in that case we can send Hellos on the both IPv4 and
>  > >  > >  > IPv6 sockets."
>  > >  > >  > >
>  > >  > >  > >  I'm not sure what it means for an "address" to be
>  > >  > >  > "configured for both
>  > >  > >  > >  IPv4 and IPv6".  Assuming that it means that targeted
>  > >  > Hello's are
>  > >  > >  > >  targeted for 2 addresses, one of which is an IPv4 address
>  > >  > >  > and the other
>  > >  > >  > >  of which is an IPv6 address, without inspecting topology
>  > >  > >  > information
>  > >  > >  > >  gleaned from an IGP how could a router determine
>  > if 2 such
>  > >  > >  > addresses are
>  > >  > >  > >  for the same target?
>  > >  > >  > VM>> You are right. It was a bad attempt to make a
>  > >  > distinction between
>  > >  > >  > the Extended Discovery and the Basic discovery
>  > mechanism. I will
>  > >  > >  > reword this further.
>  > >  > >  >
>  > >  > >  > >  * Page 5, Section 5. Maintaining Hello Adjacencies
>  > >  > >  > >
>  > >  > >  > >    "An LDP session has multiple Hello adjacencies when a
>  > >  > >  > pair of LSRs is
>  > >  > >  > >     connected by multiple links that share the same
>  > >  > label space; for
>  > >  > >  > >     example, multiple PPP links between a pair of routers.
>  > >  > >  > We can also
>  > >  > >  > >  have
>  > >  > >  > >     multiple Hello adjacencies in the dual stack
>  > case where
>  > >  > >  > we have IPv4
>  > >  > >  > >     and IPv6 Hellos exchanged for the same label space
>  > >  > >  > between a pair of
>  > >  > >  > >     LSR's."
>  > >  > >  > >
>  > >  > >  > >  For peers directly connected by a single point-2-point
>  > >  > >  > link Hello's for
>  > >  > >  > >  a single address family should be sufficient to allow
>  > >  > >  > estalishment of an
>  > >  > >  > >  LDP session supporting label advertisement for both
>  > >  > IPv4 and IPv6
>  > >  > >  > >  addresses families.
>  > >  > >  > >
>  > >  > >  > >  For a set of peers connected by a single
>  > multi-access link
>  > >  > >  > it may not be
>  > >  > >  > >  practical in general to limit Hello's to a single
>  > >  > address family.
>  > >  > >  > >
>  > >  > >  > >  For targeted peers it may be difficult to
>  > prevent multiple
>  > >  > >  > hello targets
>  > >  > >  > >  for the same peer.
>  > >  > >  > VM> That is correct, hellos for a single address
>  > family should be
>  > >  > >  > sufficient in the case that the other end also
>  > supports the same.
>  > >  > >  > However this is meant to work for the case where we have
>  > >  > say an IPv6
>  > >  > >  > only or IPv4 router as a peer.
>  > >  > >
>  > >  > >  #bt: Agreed, discovery needs to work when peering is with
>  > >  > an IPv4-only
>  > >  > >  or an IPv6-only peer.  However, I think the discovery
>  > >  > procedures can be
>  > >  > >  defined in such a way that it is unnecessary to send both
>  > >  > IPv6 and IPv4
>  > >  > >  Hello's between 2 peers on a point-to-point link.  For
>  > >  > example, if R1
>  > >  > >  supports both IPv4 and IPv6 and R2 supports only IPv4, R1
>  > >  > can quickly
>  > >  > >  discover that it is receiving IPv4 Hellos from R2 and send
>  > >  > only IPv4
>  > >  > >  Hellos to R2 (if it is not already doing so).
>  > >  > >
>  > >  > >  > >  * Page 5, Section 6.  Hello Message Procedures
>  > >  > >  > >
>  > >  > >  > >    "However [RFC5036] states does not define the behavior
>  > >  > >  > of LDP in case
>  > >  > >  > >
>  > >  > >  > >     both IPv4 and IPv6 transport addresses are sent in
>  > >  > the packet.
>  > >  > >  > >
>  > >  > >  > >     [RFC5036] seems to assume that only one such TLV
>  > >  > is received
>  > >  > >  > >     and specifies the behavior based on such a case."
>  > >  > >  > >
>  > >  > >  > >  One Transport Address TLV per Hello message is sufficient
>  > >  > >  > and should be
>  > >  > >  > >  the goal.
>  > >  > >  > >
>  > >  > >  > >  A reasonable approach would be to permit an optional
>  > >  > IPv4 Transport
>  > >  > >  > >  Address TLV (but not an IPv6 Transport Address TLV)
>  > >  > when the Hello
>  > >  > >  > >  message is carried in an IPv4 packet and to permit an
>  > >  > optional IPv6
>  > >  > >  > >  Transport Address TLV (but not an IPv4 Transport Address
>  > >  > >  > TLV) when the
>  > >  > >  > >  Hellos message is carried in an IPv6 packet.
>  > >  > >  > VM> Our attempt is to allow only one Transport
>  > Address TLV in the
>  > >  > >  > hello's. We currently allow receiving multiple TLV's,
>  > >  > but we send only
>  > >  > >  > a single TLV. We have not yet got the optional part that
>  > >  > you mention.
>  > >  > >  > the reason being that RFC5036 states the below:
>  > >  > >  >
>  > >  > >  >       IPv4 Transport Address
>  > >  > >  >          Specifies the IPv4 address to be used for the
>  > >  > >  > sending LSR when
>  > >  > >  >          opening the LDP session TCP connection.  If
>  > >  > this optional TLV
>  > >  > >  >          is not present, the IPv4 source address for the
>  > >  > UDP packet
>  > >  > >  >          carrying the Hello SHOULD be used.
>  > >  > >  >
>  > >  > >  >       Configuration Sequence Number
>  > >  > >  >          Specifies a 4 octet unsigned configuration sequence
>  > >  > >  > number that
>  > >  > >  >          identifies the configuration state of the sending
>  > >  > >  > LSR.  Used by
>  > >  > >  >          the receiving LSR to detect configuration
>  > changes on the
>  > >  > >  >          sending LSR.
>  > >  > >  >
>  > >  > >  >       IPv6 Transport Address
>  > >  > >  >          Specifies the IPv6 address to be used for the
>  > >  > >  > sending LSR when
>  > >  > >  >          opening the LDP session TCP connection.  If
>  > >  > this optional TLV
>  > >  > >  >          is not present the IPv6 source address for the
>  > >  > UDP packet
>  > >  > >  >          carrying the Hello SHOULD be used.
>  > >  > >  >
>  > >  > >  > We will then need to change the above section too.
>  > >  > >
>  > >  > >  #bt: As noted above my suggestion is to allow an optional
>  > >  > IPv4 Transport
>  > >  > >  Address TLV in Hello's carried by IPv4 packets and an
>  > optional IPv6
>  > >  > >  Transport Address TLV in Hello's carried by IPv6 packets.
>  > >  > I think this
>  > >  > >  is in the spirit of the rfc5036 text quoted above.
>  > >  > >
>  > >  > >
>  > >  > >  > >  * Page 6, Section 7.2  Session Initialization
>  > >  > >  > >
>  > >  > >  > >  My opinion is that IPv6 label distribution should be
>  > >  > >  > assumed to be "off"
>  > >  > >  > >  for an LDP session until explicitly enabled by the
>  > >  > LDP capability
>  > >  > >  > >  mechanism.
>  > >  > >  > >
>  > >  > >  > >  This is the approach for all "new" FEC types (e.g., the
>  > >  > >  > mLDP FEC types),
>  > >  > >  > >  and had the capability mechanism been part of
>  > the baseline
>  > >  > >  > LDP spec it
>  > >  > >  > >  would have been the case for IPv4 and the AToM/L2vpn set
>  > >  > >  > of FEC types.
>  > >  > >  > VM>> OK, will do this part. We had left it because we
>  > >  > thought it was a
>  > >  > >  > configuration option local to the router in question.
>  > >  > >
>  > >  > >  #bt: I agree that it is a configuration option.  If
>  > IPv6 LDP label
>  > >  > >  distribution is configured on a router then it would
>  > advertise the
>  > >  > >  corresponding capability in its Initialization
>  > message as part of
>  > >  > >  session establishment.
>  > >  > >
>  > >  > >
>  > >  > >  > >  * Page 8, Section 8.1 Normative References
>  > >  > >  > >
>  > >  > >  > >  rfc5036 is missing from the list of normative references.
>  > >  > >  > VM>> That is a big gaffee and will be corrected.
>  > >  > >
>  > >  >
>  > >
>  >
>
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

George Swallow | 7 Mar 16:34 2008
Picon

Daylight Time

For those of you coming from outside, the US, this is a reminder that
the US starts Daylight time this Sunday.  The clocks move forward by an
hour.  (which means the meeting starts an hour earlier according to your
body's clock)

See you bright and early Monday 9:00 AM EDT

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

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


Gmane