

an egress LSR (LER), this LSR needs to match between the incoming packet =
and one of his opened LDP sessions. There are several options to solve =
this issue: one would be to change RFC 4379 and to add to the LDP ipv4 =
FEC described in the RFC a ping originator address (this address should =
be the originator=92s transport address).  Another option can be to =
conclude the LDP session from the source ip address of the echo request =
packet. The last option in my opinion shouldn=92t be the preferred one =
since it requires matching between the incoming packet and the =
address-list TLV used in the LDP protocol. However even this last option =
should have been discussed in the RFC.=20

=20

Please enlighten me with your thoughts.

Did I miss something in the RFC.=20

Regards

Asaf Henig=20

MRV communications. =20

=20

=20

=20

=20

=20

 =20

=20

=20

=20

------_=_NextPart_001_01C710A6.43C069FB
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML =
DIR=3Drtl><HEAD><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255"></HEAD><BODY><DIV dir=3Dltr><FONT face=3D'Arial' =
color=3D#000000 size=3D2>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Section 4.4.1 in the RFC describes an algorithm for Fec =
Validation, i.e. =0A=
a procedure to verify the compatibility between the incoming label and =
the FEC =0A=
tlv that describes it. </FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>However, it appears that the RFC writers didn=92t notice that =
there are =0A=
cases in which there is no 1 to 1 compatibility between the incoming =
labels and =0A=
FECs.</FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><?xml:namespace =
prefix =3D o ns =3D =0A=
"urn:schemas-microsoft-com:office:office" /><o:p><FONT face=3D"Times New =
Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Specifically let me point out the simple LDP ipv4 FEC tlv which =
includes =0A=
only a simple prefix to describe any FEC. An LSR advertising the =
networks to =0A=
which it is the egress router may advertise different labels to the same =
network =0A=
to different LSRs with which it has opened an LDP sessions. This is =
especially =0A=
true to LSRs working in Global label space. </FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>In general it appears that the RFC writers didn=92t take into =
consideration =0A=
the issue of different LDP sessions. Note that although the algorithm =
described =0A=
in section 4.4.1 also asks to validate the interface through which the =
echo =0A=
request packet arrived, this interface is not an indicator for the LDP =
session =0A=
(think of several LSRs found in the same network and are connected by a =
bridge). =0A=
</FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT =0A=
face=3D"Times New Roman">It is important to note that there are some FEC =
TLVs in =0A=
which this issue is not relevant. An example can be the RSVP ipv4 FEC =
which =0A=
includes extended-tunnel-id that marks the ping originator and thus have =
a full =0A=
1 to 1 compatibility between the FEC and the incoming label. <SPAN =0A=
style=3D"mso-spacerun: yes">&nbsp;</SPAN></FONT></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>When an incoming mpls echo request packet, with an LDP ipv4 =
FEC, reaches =0A=
an egress LSR (LER), this LSR needs to match between the intf-mx.ietf.org with esmtp (Exim 4.43) id 1GnzRf-0008V4-9x
	for [email-masked]; Sat, 25 Nov 2006 10:28:01 -0500
Content-class: urn:content-classes:message
Date: Sat, 25 Nov 2006 17:26:45 +0200
From: "Asaf Henig" <[email-masked]>
To: <[email-masked]>,
	<[email-masked]>,
	<[email-masked]>
Cc: Alon Michaeli <[email-masked]>, Amnon Ilan <[email-masked]>
Subject: [mpls] =?windows-1255?q?BUG_in_RFC_4379_=28_MPLS_Ping_/_Tracerou?=
	=?windows-1255?q?te=29_-_or_maybe_not_=96_please_enlighten_me?=

This is a multi-part message in MIME format.

--===============0139775663==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C710A6.43C069FB"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C710A6.43C069FB
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Section 4.4.1 in the RFC describes an algorithm for Fec Validation, i.e. =
a procedure to verify the compatibility between the incoming label and =
the FEC tlv that describes it.=20

However, it appears that the RFC writers didn=92t notice that there are =
cases in which there is no 1 to 1 compatibility between the incoming =
labels and FECs.

=20

Specifically let me point out the simple LDP ipv4 FEC tlv which includes =
only a simple prefix to describe any FEC. An LSR advertising the =
networks to which it is the egress router may advertise different labels =
to the same network to different LSRs with which it has opened an LDP =
sessions. This is especially true to LSRs working in Global label space. =

In general it appears that the RFC writers didn=92t take into =
consideration the issue of different LDP sessions. Note that although =
the algorithm described in section 4.4.1 also asks to validate the =
interface through which the echo request packet arrived, this interface =
is not an indicator for the LDP session (think of several LSRs found in =
the same network and are connected by a bridge).=20

=20

It is important to note that there are some FEC TLVs in which this issue =
is not relevant. An example can be the RSVP ipv4 FEC which includes =
extended-tunnel-id that marks the ping originator and thus have a full 1 =
to 1 compatibility between the FEC and the incoming label. =20

=20

When an incoming mpls echo request packet, with acoming packet =
and one =0A=
of his opened LDP sessions. There are several options to solve this =
issue: one =0A=
would be to change RFC 4379 and to add to the LDP ipv4 FEC described in =
the RFC =0A=
a ping originator address (this address should be the originator=92s =
transport =0A=
address).<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Another option =
can be to =0A=
conclude the LDP session from the source ip address of the echo request =
packet. =0A=
The last option in my opinion shouldn=92t be the preferred one since it =
requires =0A=
matching between the incoming packet and the address-list TLV used in =
the LDP =0A=
protocol. However even this last option should have been discussed in =
the RFC. =0A=
</FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Please enlighten me with your thoughts.</FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Did I miss something in the RFC. </FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Regards</FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Asaf Henig </FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT =0A=
face=3D"Times New Roman">MRV communications.<SPAN style=3D"mso-spacerun: =
yes">&nbsp; =0A=
</SPAN></FONT></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN =0A=
style=3D"mso-spacerun: yes"><FONT face=3D"Times New Roman" =
size=3D3>&nbsp; =0A=
</FONT></SPAN></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P></FONT></DIV></BODY></HTML>
------_=_NextPart_001_01C710A6.43C069FB--

--===============0139775663==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

--===============0139775663==--

n LDP ipv4 FEC, reaches =
an egress LSR (LER), this LSR needs to match between the incoming packet =
and one of his opened LDP sessions. There are several options to solve =
this issue: one would be to change RFC 4379 and to add to the LDP ipv4 =
FEC described in the RFC a ping originator address (this address should =
be the originator=92s transport address).  Another option can be to =
conclude the LDP session from the source ip address of the echo request =
packet. The last option in my opinion shouldn=92t be the preferred one =
since it requires matching between the incoming packet and the =
address-list TLV used in the LDP protocol. However even this last option =
should have been discussed in the RFC.=20

=20

Please enlighten me with your thoughts.

Did I miss something in the RFC.=20

Regards

Asaf Henig=20

MRV communications. =20

=20

=20

=20

=20

=20

 =20

=20

=20

=20

------_=_NextPart_001_01C710A6.43C069FB
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML =
DIR=3Drtl><HEAD><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255"></HEAD><BODY><DIV dir=3Dltr><FONT face=3D'Arial' =
color=3D#000000 size=3D2>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Section 4.4.1 in the RFC describes an algorithm for Fec =
Validation, i.e. =0A=
a procedure to verify the compatibility between the incoming label and =
the FEC =0A=
tlv that describes it. </FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>However, it appears that the RFC writers didn=92t notice that =
there are =0A=
cases in which there is no 1 to 1 compatibility between the incoming =
labels and =0A=
FECs.</FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><?xml:namespace =
prefix =3D o ns =3D =0A=
"urn:schemas-microsoft-com:office:office" /><o:p><FONT face=3D"Times New =
Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Specifically let me point out the simple LDP ipv4 FEC tlv which =
includes =0A=
only a simple prefix to describe any FEC. An LSR advertising the =
networks to =0A=
which it is the egress router may advertise different labels to the same =
network =0A=
to different LSRs with which it has opened an LDP sessions. This is =
especially =0A=
true to LSRs working in Global label space. </FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>In general it appears that the RFC writers didn=92t take into =
consideration =0A=
the issue of different LDP sessions. Note that although the algorithm =
described =0A=
in section 4.4.1 also asks to validate the interface through which the =
echo =0A=
request packet arrived, this interface is not an indicator for the LDP =
session =0A=
(think of several LSRs found in the same network and are connected by a =
bridge). =0A=
</FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT =0A=
face=3D"Times New Roman">It is important to note that there are some FEC =
TLVs in =0A=
which this issue is not relevant. An example can be the RSVP ipv4 FEC =
which =0A=
includes extended-tunnel-id that marks the ping originator and thus have =
a full =0A=
1 to 1 compatibility between the FEC and the incoming label. <SPAN =0A=
style=3D"mso-spacerun: yes">&nbsp;</SPAN></FONT></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>When an incoming mpls echo request packet, with an LDP ipv4 =
FEC, reaches =0A=
an egress LSR (LER), this LSR needs to match between the incoming packet =
and one =0A=
of his opened LDP sessions. There are several options to solve this =
issue: one =0A=
would be to change RFC 4379 and to add to the LDP ipv4 FEC described in =
the RFC =0A=
a ping originator address (this address should be the originator=92s =
transport =0A=
address).<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Another option =
can be to =0A=
conclude the LDP session from the source ip address of the echo request =
packet. =0A=
The last option in my opinion shouldn=92t be the preferred one since it =
requires =0A=
matching between the incoming packet and the address-list TLV used in =
the LDP =0A=
protocol. However even this last option should have been discussed in =
the RFC. =0A=
</FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Please enlighten me with your thoughts.</FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Did I miss something in the RFC. </FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Regards</FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman" =0A=
size=3D3>Asaf Henig </FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT =0A=
face=3D"Times New Roman">MRV communications.<SPAN style=3D"mso-spacerun: =
yes">&nbsp; =0A=
</SPAN></FONT></FONT></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN =0A=
style=3D"mso-spacerun: yes"><FONT face=3D"Times New Roman" =
size=3D3>&nbsp; =0A=
</FONT></SPAN></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P>=0A=
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman" =0A=
size=3D3>&nbsp;</FONT></o:p></P></FONT></DIV></BODY></HTML>
------_=_NextPart_001_01C710A6.43C069FB--

--===============0139775663==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

--===============0139775663==--