Subject: [mpls] draft-manral-mls-ldp-ipv6

From: "Bob Thomas (rhthomas)" <[email-masked]>
Date: Wed, 5 Mar 2008 13:36:08 -0500

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

   "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?

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

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

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

* Page 8, Section 8.1 Normative References

rfc5036 is missing from the list of normative references.
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 5 Mar 2008 10:59:37 -0800

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.

>          obtaining this knowledge is beyond the scope of this
VM>> Will change to the wording you define.

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

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

>  gleaned from an IGP how could a router determine if 2 such addresses are
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.

>  For targeted peers it may be difficult to prevent multiple hello targets
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.

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

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

>  rfc5036 is missing from the list of normative references.
VM>> That is a big gaffee and will be corrected.
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Bob Thomas (rhthomas)" <[email-masked]>
Date: Wed, 5 Mar 2008 14:48:46 -0500

[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:[email-masked]] 
> Sent: Wednesday, March 05, 2008 2:00 PM
> To: Bob Thomas (rhthomas)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls] draft-manral-mls-ldp-ipv6
> 
> Hi Bob,
> 

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

>    configured hellos will be sent for both IPv4 and IPv6 for 

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

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

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

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

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 5 Mar 2008 12:09:20 -0800

Hi Bob,

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

>  That is, there would be at most 1 Transport Address TLV in a Hello
VM>> I guess the draft intends to state exactly that. We will clarify
it further.

>  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

---

From: "Bob Thomas (rhthomas)" <[email-masked]>
Date: Wed, 5 Mar 2008 16:03:28 -0500

Hi Vishal,

Yes, I think we are converging ...

Follow up inline - search for #bt.

Bob

> Sent: Wednesday, March 05, 2008 3:09 PM
> Subject: Re: [mpls] draft-manral-mpls-ldp-ipv6
> 
> Hi Bob,
> 

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

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

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 5 Mar 2008 14:15:37 -0800

Hi Bob,

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

>  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

---

From: "Bob Thomas (rhthomas)" <[email-masked]>
Date: Wed, 5 Mar 2008 17:45:57 -0500

Hi Vishal,
 
Some comments in line - search for #bt:

Bob

> Sent: Wednesday, March 05, 2008 5:16 PM

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

> VM>> That idea is correct. However this may only be applicable to P2P

#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 the same peer."

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

> >  > >  > >  messages for a single address family (either 
> IPv4 or IPv6)
> >  > >  > sufficient?
> >  > >  > >
> >  > >  > >  gleaned from an IGP how could a router determine 
> if 2 such
> >  > >  > addresses are
> >  > >  > >  for the same target?
> >  > >  > >     multiple Hello adjacencies in the dual stack 
> case where
> >  > >  > we have IPv4
> >  > >  > >  For a set of peers connected by a single 
> multi-access link
> >  > >  > it may not be
> >  > >  > >  For targeted peers it may be difficult to 
> prevent multiple
> >  > >  > hello targets
> >  > >  > >  for the same peer.
> >  > >  > >  and had the capability mechanism been part of 
> the baseline
> >  > >  > LDP spec it

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 5 Mar 2008 14:48:02 -0800

Thanks Bob.

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

-Vishwas