'Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: mpls
Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org
From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta () alcatel-lucent ! com>
Date: 2012-09-17 21:57:50
Message-ID: C584046466ED224CA92C1BC3313B963E13F0EDB6A8 () INBANSXCHMBSA3 ! in ! alcatel-lucent ! com
[Download RAW message or body]

Hi Eric,
                  Pls. refer my answers inline.

Thanks,
Pranjal

________________________________
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri=
c Gray
Sent: Friday, September 14, 2012 7:30 AM
To: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org
Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@=
tools.ietf.org

Dear Authors,

The MPLS Chair(s) have asked myself (and others) to review this draft to
determine - possibly among other things - whether this draft is ready for
adoption as a working group draft.

[Pranjal] Thanks for detailed review of the draft.

As an overview, I feel that this draft needs a few important "direction
changes" before it will be ready to adopt by the working group, assuming
the working group decides that this is work that we have both interest and
capacity to work on.

[Pranjal]  "Interest" part is understood but I think I would have some conc=
erns on
"capacity" aspects of it and deserves more qualification - that is, are we =
compromising real
demands from today's networks just because WG can't cater to growing demand=
s. If it's so, then I am not
sure if I am the right person to answer that in the context of this specifi=
c draft and IMO, perhaps a
question to be asked and addressed in a more general thread.

I first tried to determine if this work is appropriate for the working grou=
p.
It appears that the MPLS charter is very much out of date, so this item -
along with the 25+ drafts already adopted as working group drafts (in
various degrees of completion) - does not appear as a charter item.

[Pranjal]  I re-read the current WG charter as below. Did you mean the high=
lighted text to reason this work as out of
scope of the charter?
"
The working group is also responsible for specifying the necessary manageme=
nt objects (e.g. as part
of MIB modules) and OAM techniques for the functionality specified in the b=
ase MPLS technology.

The first generation of the MPLS standards are largely complete,
and the current WG work items are:

- Define requirements, mechanisms and protocol extensions for
point-to-multipoint (P2MP) MPLS

- Define requirements, mechanisms and protocol extensions for
traffic engineered point-to-multipoint (P2MP) MPLS, including
soft preemption

- Define requirements and mechanisms for MPLS OAM

- Define an overall OAM framework for MPLS applications

- MPLS-specific aspects of traffic engineering for multi-areas/multi-AS
in cooperation with the CCAMP WG

- Determine (with CCAMP) what procedures are appropriate for evaluating
proposals to extend the MPLS and GMPLS protocols, and document these

- Document current implementation practices for MPLS load sharing

- Include extensions to the MPLS WG protocols and RFCs necessary to
create an MPLS Transport Profile (MPLS TP). The work on the MPLS TP will
be coordinated between the working groups (eg, MPLS, CCAMP, PWE3, and
L2PVN) that are chartered to do MPLS TP work."

Although multiple ldp instance is a generic concept however this is also be=
en discussed  recently in context
of ldp-ipv6 - that is for the fate separation aspects.  We had discussed ip=
v4 and ipv6 fate separation at length in the
mailing list and heard operators asking for this as requirement. We see ldp=
-ipv6 work as enhancements to "first generation"
of MPLS standards (e.g LDP RFC 3026/5036) and I can't see an explicit ldp-i=
pv6 into the existing WG charter. If that is the
case then may I ask how it is possible that ldp-ipv6 draft passed WG LC in =
the MPLS WG? I am just trying to see the correct
rationale behind your verdict on this document being out of charter.

A simple reason why we came to MPLS WG is because we are defining an approa=
ch to an existing standard (RFC 5036)
which is a product of MPLS WG. We could have gone to PWE3 or MPLS WG if the=
 draft is geared towards a specific
application only (and thus not a generic infrastructure concept).

Which is a good segue to the topic - "can the working group actually do
this - along with the work they currently have already."  If every WG
participating member were to read all of the currently adopted drafts
in preparation for each IETF meeting, they could expect to spend 2 to
3 weeks out of every 4 months doing nothing else.

Possibly this is a bit much to expect.  I suspect this is a question for th=
e
active participants in the MPLS working group to consider as a general
issue.

[Pranjal] I would probably agree but again I can't answer this as a co-auth=
or of an individual draft or I am not sure
this is the appropriate thread to raise this.

As per my understanding, perhaps the questions you are asking precisely are=
 as below:

1. Is the WG equipped with sufficient b/w to cater to today's needs? I am n=
ot sure, personally I can support the fact that
we stop making technical progress or standardize drafts with fundamental fl=
aws because the WG doesn't have
sufficient b/w. In such case a resolution needs to be taken by the WG on wh=
ether it needs a black out period
of "no draft submissions" in order to clear the existing backlogs.

2. Is the WG doing the right job in standardizing the right thing that is n=
eeded in today's networks? I can't answer
that question and perhaps a WG wide introspection is needed on quality of o=
n-going works.

As a second general issue, this draft describes what I feel are fairly well
known rules that an implementation may follow to ensure that their
"cheating ways" are not discovered in some pathological way by other
implementations.

[Pranjal] I believe in this context, you are mentioning about introduction =
of Node-ID TLV that is used for Nodes to be multi-instance
aware; IMO, cheating is always bad because you may have a corner case left =
out somewhere. I would appreciate if you could describe
precisely a method where we can do multiple instances without Node-ID TLV b=
ut not getting caught in any of existing LDP based
"applications".

This seems to be the major contribution in section 2 of this draft.

In this sense, I'd be more comfortable if this draft were targeted to
become a BCP, rather than a Standard.

[Pranjal] I am perfectly OK to drop Node-ID TLV from the draft and let an i=
mplementation figure out certains things on own
(not getting cheated by peers). Thus we can certainly make the draft BCP or=
 Informational.

But, enough of the general issues; on to the specifics of this draft...

Major issues:

The third paragraph of the introduction is incorrect.  When peering
with an LSR that uses two LSR IDs, it is possible for that LSR to do this
in a way that makes it  difficult (if not impossible) for a peer to detect
that the two LSR IDs identify LSR functions of the same physical node.

In fact, to ensure the highest probability of compatibility (or the
lowest probability of compatibility issues), any LSR implementation
that uses more than one LSR ID should do this.  That means they need
to use separate IP addresses for discovery, session establishment, etc.

This is an example of a standards implementation axiom that amounts
to this: "if you're going to cheat, be careful not to get caught."

If implementers follow this rule through proper use of addressing, and
a few other things, then support for multiple LDP sessions just works,
today - without requiring further standardization work.

[Pranjal] Yep, you are right. An implementation of multiple ldp instances e=
xists that has been deployed in major networks
for around ~5 years by now. So it's a proven, robust technique. There are 3=
 major deployment reasons for multiple ldp
instances so far -

 1.  Fate separation or avoidance of head of line blocking between PW (Pseu=
dowire) overlay and
LDP P2P/MP2P tunnels. I don't want to get into gory details but key reasons=
 on such  a separation are - demultiplex
between intenstive PW status signaling, PW OAM etc and transport signaling =
+ separation of
management entities between PW overlay and Transport.

 1.  Fate separation between LDP Multicast and Unicast Traffic. You can com=
plement this further with IGP multi-topology.

      3.   Non-fate separated use case - Separation of ldp stack into indep=
endent managements domains inside a node (e.g east, west, north, south).
            Only one lsr- based session would be established to each region=
 and thus no case of || sessions. In such use cases, each LDP LSR-ID is
            mapped to a single ipv4 address which is also a transport addre=
ss of sessions and only that address is routable to the specific region (ot=
her
            regions don't see it). In this regional separation, LDP FECs ar=
e not stitched by default between domain and distribution between domains
           (inter-region LSPs) happen thru well defined local policies (it'=
s a local implementation specific matter though). This specific use case of=
 multiple
            instance case is inter-oping with vendors that don't support or=
 aware of multi-instance. So in your words, this is the case of "cheating w=
ithout
            getting caught".

For the case where the label space portion of the LSR ID is zero (the
so-called platform-wide label space), the implementation that has
multiple LSR IDs needs to be careful about allocating labels in different
LDP Sessions - but this is an implementation robustness issue, not a
standards issue.

[Pranjal] This is why this draft describes the cases of what do to when run=
ning || sessions between two nodes (fate-separation case), LDP session
capabilities, loop detection etc. The way I see it as - with existing metho=
dologies of RFC 5036, an LDP based application mustn't get into pathologica=
l
case at any cost.

It is my opinion that the draft authors have not given sufficient thought
to what can be done using the current standards and a few common
sense implementation rules

[Pranjal]  We are aware of the current standard rules. As I mentioned, we a=
re not talking theory but running code.
But when you want to use multiple instances for fate separation, I am not q=
uite sure you can convince an implementer
to ignore Node-ID TLV in order to keep the existing LDP based applications =
sane. Currently, the fate separation cases
(1 and 2 as discussed earlier) have been working well with Node-ID TLV enco=
ded as Vendor Private TLV  (single
Vendor implementation). I am perfectly OK to keep the Node ID TLV as Vendor=
 Private as long as "vendor being cheated"
can guarantee that it handle any loop cases that may arise due to mis-confi=
guration etc. We can set the draft as BCP/
Informational.

__________________________________________________________

I believe the direction taken in section 3 - toward greater visibility of t=
he
fact that an LSR node has multiple LDP instance - is a mistake.

[Pranjal] I think I didn't understand your point well. Why do you say that =
it's a mistake when physical node has multiple
LSRs and LSR represents an instance within a single VPRN or Base Routing do=
main.

The authors have provided no example use case to support the assertion
that a loop may be formed as a result for "some applications" with a
properly implemented LSR.

[Pranjal] I agree, we fell short of explaining applications (e.g H-VPLS) in=
 adequate detail. We can discuss a few applications at length
on how loop can occur and can remove Node-ID TLV/Loop detection (Each imple=
mentation finds smarter ways in their own).

In my opinion, this draft needs to provide explicit examples of where a
properly implemented/compliant LDP implementation would cause a
pathological outcome if it is implemented in such a way that a peer is
not able to detect that multiple LDP instances are implemented by a
common physical node.

[Pranjal] You have certainly raised a good point and I agree with you. We w=
ill do so.

Minor issues and Comments/Questions:

For the paragraph that starts on page 3 and continues onto page 4, the
first sentence has a number of problems and does not parse without
making some assumptions as to what the author(s) mean to say.

In addition, it would be useful if you could expand slightly on what you
mean by "routable"  IP addresses.  To be more precise, the 32-bit part
of the LSR ID that is typically used corresponds to an IP address (one of
potentially very many) that is assigned to the LSR node.

[Pranjal] Sure. We would describe in detail. "Routability" of LSR-ID is a p=
revalent case esp. on the use case
mentioned in 3 (regional separation). You use one loopback IP address for b=
inding to everything in your OSS,
for IGP, an LDP LSR, OAM, etc. If the local IP address to which LSR is boun=
d to is also used as transport (or
(requires reachability) then the loopback IP must be routable.

In fact, common implementation considerations frequently lead to a
preference to use the router ID (typically based on an internal assigned
"loop-back" IP address) - for much the same reasons that routers use
these addresses (i.e. they are less likely to be impacted by removal of
a physical interface).

[Pranjal] Perfectly agree. AFAIK, most of implementations I have seen so fa=
r has adopted to mapping a local
loopback IP address to 32-bit of LSR-ID, except a few.

If an IPv4 address assigned to the LSR is used for this purpose, it is
clear that the address is not only routable by assigned to a specific
network entity.

[Pranjal] Yes, that's correct.
________________________________________________________

In section 2, it looks as if we are conflating the meaning of "label space"
(as a number - zero, in this case), "label context" (not necessarily tied
to the label-space number, but definitely tied to an LDP session) and
data plane.

[Pranjal] The proposal mentioned in the draft applies to global label space=
 and as per RFC 5036 global
label space is always identified by '0'. We are not saying that it doesn't =
work with per interface label space.
We can clarify that explicitly into the draft. Thanks for pointing this out=
.

As long as implementations observe certain rules, there is no problem
in using the existing protocol specifications when labels are assigned in
association with an active session and apply to a common subset of
interfaces (possibly including all interfaces).

[Pranjal] Yes, that's correct. But I am not quite sure we can claim that
"being cheated" would cater to all applications running on LDP as an
Infrastructure protocol.

For example, as long as the same label is not issued by two (or more)
LSR instances with a different semantic meaning, that label does not
present any problems when used (as intended) in the common data
plane.

[Pranjal]  On theory yes, but when we are making a robust implementation of=
 a protocol stack, every -ve case
needs to be considered (Not IETF design rule but software design rule). Ide=
ally, a peer shouldn't distribute
duplicate labels but what if it does? A receiver can get any message as def=
ined in RFC 5036. I gave H-VPLS as
another example where we can stitch FEC128 spoke to FEC 129 mesh PW. In tha=
t case if both are wrongly terminated
in same node then existing LDP procedures can't determine the semantics of =
applications (e.g loop in MAC FIB).  Can
we guarantee that the receiving LSR that is well behaved would remain sane?=
 From an implementation perspective
we can't see RFC 5036 only as LDP and an implementation needs to take care =
of the larger picture - where
LDP becomes infrastructure provider on which many solutions have been built=
 upon.

The obvious method for doing this is for all LSR instances to share a
common label management function - for at least the case where
labels allocated may have meaning across multiple interfaces.  This
has been done in LDP implementations since before RFC 3036 (the
predecessor to RFC 5036) was published.

[Pranjal] "for at least the case where labels allocated may have meaning ac=
ross multiple interfaces."
Do you mean to say "same" meaning or "different" meaning across multiple in=
terfaces?

Note that this is an implementation choice.
_________________________________________________________

NITs:

In the Introduction, in (I believe) the 4th sentence of the 2nd paragraph,
"4 octets" should be "first 4 octets" (the preceding sentence talks about
the 6-octet LSR ID and the next sentence talks about the last 2 octets).

The sentence, in the penultimate paragraph of section 1 (Introduction),
that starts "Suc next-hop addresses" was probably meant to say "Such
next-hop addresses" - and there is probably supposed to be a space
after the period in that sentence and before the first word ("Thus") of
the next sentence.

[Pranjal] Thanks. Would rectify the errors.
--
Eric

[Attachment #3 (text/html)]

<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:st1="urn:schemas-microsoft-com:office:smarttags" \
xmlns="http://www.w3.org/TR/REC-html40" \
xmlns:ns0="http://schemas.microsoft.com/office/2004/12/omml">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="place"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:480389758;
	mso-list-type:hybrid;
	mso-list-template-ids:-806461318 -1466107262 67698713 67698715 67698703 67698713 \
67698715 67698703 67698713 67698715;} @list l0:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:743793470;
	mso-list-type:hybrid;
	mso-list-template-ids:-2082581804 1773821472 67698713 67698715 67698703 67698713 \
67698715 67698703 67698713 67698715;} @list l1:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Hi Eric,<o:p></o:p></span></font></p>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 Pls. refer my answers inline.<o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Pranjal<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt;font-family:"Times New Roman"'>

<hr size=3 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] <b><span style='font-weight:
bold'>On Behalf Of </span></b>Eric Gray<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, September 14, 2012
7:30 AM<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName \
w:st="on">draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org</st1:PersonName><br> \
<b><span style='font-weight:bold'>Cc:</span></b> <st1:PersonName \
w:st="on">mpls@ietf.org</st1:PersonName>; <st1:PersonName \
w:st="on">mpls-chairs@tools.ietf.org</st1:PersonName><br> <b><span \
style='font-weight:bold'>Subject:</span></b> Re: [mpls] MPLS-RT review of \
<st1:PersonName w:st="on">draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org</st1:PersonName></span></font><font
 face="Times New Roman"><span style='font-family:"Times New \
Roman"'><o:p></o:p></span></font></p>

</div>

<p class=MsoNormal><font size=3 face=SimSun><span \
style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>Dear \
Authors,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:#1F497D'>The MPLS Chair(s) have
asked myself (and others) to review this draft to <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:#1F497D'>determine &#8211;
possibly among other things &#8211; whether this draft is ready for \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:#1F497D'>adoption as a working
group draft.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] Thanks for detailed review of
the draft. <o:p></o:p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:#1F497D;font-weight:bold;
font-style:italic'>As an overview, I feel that this draft needs a few important
&quot;direction<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:#1F497D;font-weight:bold;
font-style:italic'>changes&quot; before it will be ready to adopt by the
working group, assuming<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:#1F497D;font-weight:bold;
font-style:italic'>the working group decides that this is work that we have
both interest and <o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:#1F497D;font-weight:bold;
font-style:italic'>capacity to work on.<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>[Pranjal] &nbsp;&#8220;Interest&#8221; part
is understood but I think I would have some concerns on <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>&#8220;capacity&#8221; aspects of it and
deserves more qualification - that is, are we compromising real \
<o:p></o:p></span></font></p>

demands from today&#8217;s networks just because
WG can&#8217;t cater to growing demands. If it&#8217;s so, then I am not \
<o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>sure if I am the right person to answer
that in the context of this specific draft and IMO, perhaps a \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>question to be asked and addressed in a
more general thread.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:#1F497D'>I first tried to
determine if this work is appropriate for the working \
group.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>It appears that the
MPLS charter is very much out of date, so this item \
&#8211;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>along with the 25+
drafts already adopted as working group drafts (in<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>various degrees of
completion) &#8211; does not appear as a charter item.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] &nbsp;I re-read the current WG
charter as below. Did you mean the \
highlighted \
text to reason this work as out of <o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>scope of the \
charter?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=1 color=blue face="Courier New"><span
style='font-size:8.0pt;font-family:"Courier \
New";color:blue'>&#8220;<o:p></o:p></span></font></p>

The working group
is also responsible for specifying the necessary management objects (e.g. as
part <o:p></o:p>

<p class=MsoNormal><font size=1 color=blue face="Courier New"><span
style='font-size:8.0pt;font-family:"Courier New";color:blue'>of MIB modules)
and OAM techniques for the functionality specified in the base MPLS technology.
<br>
<br>
<b><span style='font-weight:bold'>The first generation of the MPLS standards
are largely complete, <br>
and the current WG work items are: <br>
</span></b><br>
- Define requirements, mechanisms and protocol extensions for <br>
point-to-multipoint (P2MP) MPLS <br>
<br>
- Define requirements, mechanisms and protocol extensions for <br>
traffic engineered point-to-multipoint (P2MP) MPLS, including <br>
soft preemption <br>
<br>
- Define requirements and mechanisms for MPLS OAM <br>
<br>
- Define an overall OAM framework for MPLS applications <br>
<br>
- MPLS-specific aspects of traffic engineering for multi-areas/multi-AS <br>
in cooperation with the CCAMP WG <br>
<br>
- Determine (with CCAMP) what procedures are appropriate for evaluating <br>
proposals to extend the MPLS and GMPLS protocols, and document these <br>
<br>
- Document current implementation practices for MPLS load sharing <br>
<br>
- Include extensions to the MPLS WG protocols and RFCs necessary to <br>
create an MPLS Transport Profile (MPLS TP). The work on the MPLS TP will <br>
be coordinated between the working groups (eg, MPLS, CCAMP, PWE3, and <br>
L2PVN) that are chartered to do MPLS TP work.&#8221;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=1 face="Courier New"><span style='font-size:8.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Although multiple ldp instance is a
generic concept however this is also been discussed &nbsp;recently in context \
<o:p></o:p></span></font></p>

of ldp-ipv6 &#8211; that is for the fate
separation aspects. &nbsp;We had discussed ipv4 and ipv6 fate separation at
length in the <o:p></o:p>

mailing list and heard operators asking
for this as requirement. We see ldp-ipv6 work as enhancements to &#8220;first
generation&#8221; <o:p></o:p>

of MPLS standards (e.g LDP RFC 3026/5036)
and I can&#8217;t see an explicit ldp-ipv6 into the existing WG charter. If that
is the <o:p></o:p>

case then may I ask how it is possible
that ldp-ipv6 draft passed WG LC in the MPLS WG? I am just trying to see the
correct <o:p></o:p>

rationale behind your verdict on this
document being out of charter. <o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>A simple reason why we came to MPLS WG is
because we are defining an approach to an existing standard (RFC \
5036)<o:p></o:p></span></font></p>

which is a product of MPLS WG. We could
have gone to PWE3 or MPLS WG if the draft is geared towards a specific \
<o:p></o:p>

application only (and thus not a generic
infrastructure concept). &nbsp;<o:p></o:p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>Which is a good
segue to the topic &#8211; &quot;can the working group actually \
do<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>this &#8211; along
with the work they currently have already.&quot;&nbsp; If every \
WG<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>participating member
were to read all of the currently adopted drafts<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>in preparation for
each IETF meeting, they could expect to spend 2 to<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>3 weeks out of every
4 months doing nothing else.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>Possibly this is a
bit much to expect.&nbsp; I suspect this is a question for \
the<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>active participants
in the MPLS working group to consider as a general<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>issue.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>[Pranjal] I would probably agree but again
I can&#8217;t answer this as a co-author of an individual draft or I am not
sure <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>this is the appropriate thread to raise
this.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>As per my understanding, perhaps the
questions you are asking precisely are as below:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

1. Is the WG equipped with sufficient b/w
to cater to today&#8217;s needs? I am not sure, personally I can support the
fact that <o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>we stop making technical progress or standardize
drafts with fundamental flaws because the WG doesn&#8217;t have \
<o:p></o:p></span></font></p>

sufficient b/w. In such case a resolution
needs to be taken by the WG on whether it needs a black out period \
<o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>of &#8220;no draft submissions&#8221; in
order to clear the existing backlogs.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

2. Is the WG doing the right job in
standardizing the right thing that is needed in today&#8217;s networks? I can&#8217;t
answer<o:p></o:p>

that question and perhaps a WG wide
introspection is needed on quality of on-going works. <o:p></o:p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>As a second general
issue, this draft describes what I feel are fairly well<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>known rules that an
implementation may follow to ensure that their<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>&quot;cheating
ways&quot; are not discovered in some pathological way by other \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>implementations.&nbsp;
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>[Pranjal] I believe in this context, you
are mentioning about introduction of Node-ID TLV that is used for Nodes to be
multi-instance <o:p></o:p></span></font></p>

aware; IMO, cheating is always bad because
you may have a corner case left out somewhere. I would appreciate if you could
describe <o:p></o:p>

precisely a method where we can do
multiple instances without Node-ID TLV but not getting caught in any of
existing LDP based 
&#8220;applications&#8221;. <o:p></o:p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>This seems to be the
major contribution in section 2 of this draft.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>In this sense, I'd
be more comfortable if this draft were targeted to <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>become a BCP, rather
than a Standard.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>[Pranjal] I am perfectly OK to drop Node-ID
TLV from the draft and let an implementation figure out certains things on \
own<o:p></o:p></span></font></p>

(not getting cheated by peers). Thus we
can certainly make the draft BCP or Informational.<o:p></o:p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>But, enough of the
general issues; on to the specifics of this draft&#8230;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><b><i><u><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>Major issues</span></font></u></i></b><font size=2
color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:Calibri;
color:#1F497D'>:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>The third paragraph
of the introduction is incorrect.&nbsp; When peering<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>with an LSR that
uses two LSR IDs, it is possible for that LSR to do this \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>in a way that makes
it &nbsp;difficult (if not impossible) for a peer to detect \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>that the two LSR IDs
identify LSR functions of the same physical node.&nbsp; <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>In fact, to ensure
the highest probability of compatibility (or the<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>lowest probability
of compatibility issues), any LSR implementation &nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>that uses more than
one LSR ID should do this.&nbsp; That means they need<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>to use separate IP
addresses for discovery, session establishment, etc.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>This is an example
of a standards implementation axiom that amounts <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>to this: &quot;if
you're going to cheat, be careful not to get \
caught.&quot;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>If implementers
follow this rule through proper use of addressing, and <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>a few other things,
then support for multiple LDP sessions just works, <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>today &#8211;
without requiring further standardization work.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] Yep, you are right. An
implementation of multiple ldp instances exists that has been deployed in major
networks <o:p></o:p>

for around ~5 years by now. So it&#8217;s
a proven, robust technique. There are 3 major deployment reasons for multiple
ldp <o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>instances so far \
&#8211;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<ol style='margin-top:0in' start=1 type=1>
 <li class=MsoNormal style='color:blue;mso-list:l1 level1 lfo2'><font size=2
     color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial'>Fate
     separation or avoidance of head of line blocking between PW (Pseudowire) overlay
     and <o:p></o:p></span></font></li>
</ol>

LDP P2P/MP2P tunnels. I
don&#8217;t want to get into gory details but key reasons on such&nbsp; a
separation are - demultiplex <o:p></o:p>

<p class=MsoNormal style='margin-left:.5in'><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'>between intenstive PW
status signaling, PW OAM etc and transport signaling + separation of \
<o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'>management entities
between PW overlay and Transport.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<ol style='margin-top:0in' start=2 type=1>
 <li class=MsoNormal style='color:blue;mso-list:l1 level1 lfo2'><font size=2
     color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial'>Fate
     separation between LDP Multicast and Unicast Traffic. You can complement
     this further with IGP multi-topology.<o:p></o:p></span></font></li>
</ol>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3.&nbsp;&nbsp; Non-fate separated use case - Separation of ldp stack into
independent managements domains inside a node (e.g east, west, north, south). \
<o:p></o:p>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 Only one lsr- based session would be established to each region and thus no case
of || sessions. In such use cases, each LDP LSR-ID is 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mapped to a
single ipv4 address which is also a transport address of sessions and only that
address is routable to the specific region (other<o:p></o:p>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 regions don&#8217;t see it). In this regional separation, LDP FECs are not
stitched by default between domain and distribution between domains 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (inter-region
LSPs) happen thru well defined local policies (it&#8217;s a local
implementation specific matter though). This specific use case of multiple 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; instance
case is inter-oping with vendors that don&#8217;t support or aware of
multi-instance. So in your words, this is the case of &#8220;cheating without 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; getting
caught&#8221;. <o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>For the case where
the label space portion of the LSR ID is zero (the<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>so-called
platform-wide label space), the implementation that has<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>multiple LSR IDs
needs to be careful about allocating labels in different<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>LDP Sessions &#8211;
but this is an implementation robustness issue, not a<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>standards \
issue.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>[Pranjal] This is why this draft describes
the cases of what do to when running || sessions between two nodes
(fate-separation case), LDP session<o:p></o:p></span></font></p>

capabilities, loop detection etc. The way
I see it as - with existing methodologies of RFC 5036, an LDP based application
mustn&#8217;t get into pathological <o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>case at any cost.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>It is my opinion that the draft authors have not given
sufficient thought<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>to what can be done using the current standards and a few
common<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>sense implementation rules</span></font></i></b><b><i><font
size=2 color=navy face=Calibri><span style='font-size:11.0pt;font-family:Calibri;
color:navy;font-weight:bold;font-style:italic'><o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'><o:p>&nbsp;</o:p></span></font></i></b></p>

[Pranjal] &nbsp;We are aware of the
current standard rules. As I mentioned, we are not talking theory but running
code.<o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>But when you want to use multiple
instances for fate separation, I am not quite sure you can convince an
implementer <o:p></o:p></span></font></p>

to ignore Node-ID TLV in order to keep the
existing LDP based applications sane. Currently, the fate separation cases \
<o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>(1 and 2 as discussed earlier) have been
working well with Node-ID TLV encoded as Vendor Private TLV &nbsp;(single \
<o:p></o:p></span></font></p>

Vendor implementation). I am perfectly OK
to keep the Node ID TLV as Vendor Private as long as &#8220;vendor being \
cheated&#8221;<o:p></o:p>

can guarantee that it handle any loop
cases that may arise due to mis-configuration etc. We can set the draft as \
BCP/<o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Informational.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>__________________________________________________________<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>I believe the
direction taken in section 3 &#8211; toward greater visibility of \
the<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>fact that an LSR
node has multiple LDP instance &#8211; is a mistake.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Calibri><span style='font-size:
11.0pt;font-family:Calibri;color:navy'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] I think I didn&#8217;t
understand your point well. Why do you say that it&#8217;s a mistake when
physical node has multiple<o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>LSRs and LSR represents an instance within
a single VPRN or Base Routing domain.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>The authors have
provided no example use case to support the assertion<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>that a loop may be
formed as a result for &quot;some applications&quot; with \
a<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>properly implemented
LSR.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] I agree, we fell short of
explaining applications (e.g H-VPLS) in adequate detail. We can discuss a few
applications at length 
on how loop can occur and can remove Node-ID TLV/Loop detection (Each
implementation finds smarter ways in their own).<o:p></o:p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>In my opinion, this draft needs to provide explicit examples
of where a<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>properly implemented/compliant LDP implementation would
cause a<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>pathological outcome if it is implemented in such a way that
a peer is<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>not able to detect that multiple LDP instances are
implemented by a<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><b><i><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>common physical node.<o:p></o:p></span></font></i></b></p>

<p class=MsoNormal><font size=2 color=blue face=Calibri><span style='font-size:
11.0pt;font-family:Calibri;color:blue'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] You have certainly raised a good
point and I agree with you. We will do so.<o:p></o:p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><b><i><u><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>Minor issues and Comments/Questions</span></font></u></i></b><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'>:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>For the paragraph
that starts on page 3 and continues onto page 4, the<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>first sentence has a
number of problems and does not parse without<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>making some
assumptions as to what the author(s) mean to say.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>In addition, it
would be useful if you could expand slightly on what you \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>mean by
&quot;routable&quot;&nbsp; IP addresses.&nbsp; To be more precise, the 32-bit
part<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>of the LSR ID that
is typically used corresponds to an IP address (one of<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>potentially very
many) that is assigned to the LSR node.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] Sure. We would describe in
detail. &#8220;Routability&#8221; of LSR-ID is a prevalent case esp. on the use
case <o:p></o:p>

mentioned in 3 (regional separation). You
use one loopback IP address for binding to everything in your <st1:place \
w:st="on"><st1:City \
w:st="on">OSS</st1:City></st1:place>,<o:p></o:p>

for IGP, an LDP LSR, OAM, etc. If the
local IP address to which LSR is bound to is also used as transport (or \
<o:p></o:p>

(requires reachability) then the loopback
IP must be routable. <o:p></o:p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>In fact, common
implementation considerations frequently lead to a<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>preference to use
the router ID (typically based on an internal assigned <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>&quot;loop-back&quot;
IP address) &#8211; for much the same reasons that routers \
use<o:p></o:p></span></font></p>

these addresses
(i.e. they are less likely to be impacted by removal of <o:p></o:p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>a physical
interface).<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Calibri><span style='font-size:
11.0pt;font-family:Calibri;color:blue'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] Perfectly agree. AFAIK, most of
implementations I have seen so far has adopted to mapping a local \
<o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>loopback IP address to 32-bit of LSR-ID,
except a few.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>If an IPv4 address
assigned to the LSR is used for this purpose, it is <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>clear that the
address is not only routable by assigned to a specific<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>network \
entity.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>[Pranjal] Yes, that&#8217;s \
correct.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>________________________________________________________<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>In section 2, it
looks as if we are conflating the meaning of &quot;label \
space&quot;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>(as a number &#8211;
zero, in this case), &quot;label context&quot; (not necessarily \
tied<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>to the label-space
number, but definitely tied to an LDP session) and <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>data plane.&nbsp; \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] The proposal mentioned in the
draft applies to global label space and as per RFC 5036 global 
label space is always identified by &#8216;0&#8217;. We are not saying that it
doesn&#8217;t work with per interface label space. 
We can clarify that explicitly into the draft. Thanks for pointing this \
out.<o:p></o:p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>As long as
implementations observe certain rules, there is no problem \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>in using the
existing protocol specifications when labels are assigned in \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>association with an
active session and apply to a common subset of <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>interfaces (possibly
including all interfaces).<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] Yes, that&#8217;s correct. But I
am not quite sure we can claim that <o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>&#8220;being cheated&#8221; would cater to
all applications running on LDP as an <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Infrastructure \
protocol.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>For example, as long
as the same label is not issued by two (or more)<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>LSR instances with a
different semantic meaning, that label does not<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>present any problems
when used (as intended) in the common data <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>plane.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>[Pranjal] &nbsp;On theory yes, but when we
are making a robust implementation of a protocol stack, every &#8211;ve case \
<o:p></o:p></span></font></p>

needs to be considered (Not IETF design
rule but software design rule). Ideally, a peer shouldn&#8217;t distribute \
<o:p></o:p>

duplicate labels but what if it does? A
receiver can get any message as defined in RFC 5036. I gave H-VPLS \
as<o:p></o:p>

another example where we can stitch FEC128
spoke to FEC 129 mesh PW. In that case if both are wrongly \
terminated<o:p></o:p>

in same node then existing LDP procedures
can&#8217;t determine the semantics of applications (e.g loop in MAC FIB). &nbsp;Can
<o:p></o:p>

we guarantee that the receiving LSR that
is well behaved would remain sane? From an implementation perspective \
<o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>we can&#8217;t see RFC 5036 only as LDP and
an implementation needs to take care of the larger picture &#8211; where \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>LDP becomes infrastructure provider on
which many solutions have been built upon.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>The obvious method
for doing this is for all LSR instances to share a<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>common label
management function &#8211; for at least the case where <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>labels allocated may
have meaning across multiple interfaces.&nbsp; This <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>has been done in LDP
implementations since before RFC 3036 (the<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>predecessor to RFC
5036) was published.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>[Pranjal] &#8220;</span></font><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'>for at least the case where labels allocated may have
meaning across multiple interfaces.&#8221;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Do you mean to say &#8220;same&#8221;
meaning or &#8220;different&#8221; meaning across multiple \
interfaces?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>Note that this is an
implementation choice.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>_________________________________________________________<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><b><i><u><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D;font-weight:bold;
font-style:italic'>NITs</span></font></u></i></b><font size=2 color="#1f497d"
face=Calibri><span style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>In the Introduction,
in (I believe) the 4<sup>th</sup> sentence of the 2<sup>nd</sup> \
paragraph,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>&quot;4 octets&quot;
should be &quot;first 4 octets&quot; (the preceding sentence talks \
about<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>the 6-octet LSR ID
and the next sentence talks about the last 2 octets).<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>The sentence, in the
penultimate paragraph of section 1 (Introduction),<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>that starts
&quot;Suc next-hop addresses&quot; was probably meant to say \
&quot;Such<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>next-hop
addresses&quot; &#8211; and there is probably supposed to be a \
space<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>after the period in
that sentence and before the first word (&quot;Thus&quot;) of \
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>the next \
sentence.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Calibri><span style='font-size:
11.0pt;font-family:Calibri;color:navy'><o:p>&nbsp;</o:p></span></font></p>

[Pranjal] Thanks. Would rectify the
errors.<o:p></o:p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>--<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>Eric<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--===============7948703063909019509==--

[prev in list] [next in list] [prev in thread] [next in thread] 