headers
Wijnen, Bert (Bert | 1 Sep 2003 20:43
Picon
Favicon

MIB Doctor review:draft-ietf-mpls-telink-mib-03.txt

- Interesting that title page claims that doc expires feb 2003?
  You porobably mean feb 2004

- I get this WMICng warning:
  W: f(telink.mi2), (1564,19) MIN-ACCESS value identical to access 
     specified for "teLinkBandwidthUnreserved"
  Seems to me you can just remove that MIN-ACCESS from the MODULE
  COMPLIANCE.

- I see
    TeLinkSonetSdhIndication ::= TEXTUAL-CONVENTION
      STATUS       current
      DESCRIPTION
          "SONET/SDH indication type."
      SYNTAX       INTEGER {
                    standard(0),
                    arbitrary(1)
                }
   Since we normallyh do not start with zero (but with 1), I assume
   there is a reason you start with zero. Could that reason be described
   and is there a doc that explains this, so that you refernece it?

NITS:

- I see
    teLinkGroups
       OBJECT IDENTIFIER ::= { teLinkConformance 1 }

    teLinkCompliances
       OBJECT IDENTIFIER ::= { teLinkConformance 2 }
(Continue reading)

Permalink | Reply | 2 comments |
headers
Prabakaran T Sampath | 2 Sep 2003 12:58

RE: [MPLS-OPS]: Why Merging?

Hi Bhavesh Modi,

Whether we are distributing same Labels or different Labels to its upstream
LSRs,
if the LSR is merge capable and if the outgoing interface is same for the
upstream Labels(same or different) then as per RFC 3031, Section 3.26 - we
do merging (If there is any Hardware limitation exists then we got to
consider that too while doing merging).

         incoming labels             Switch	outgoing label
	                              __________
	--------- 10-----------------|          |
	--------- 25-----------------| ATM/MPLS |======10=========
	--------- 11-----------------|__________|

         incoming labels             Switch	outgoing label
	                              __________
	--------- 15-----------------|          |
	--------- 15-----------------| ATM/MPLS |======10=========
	--------- 15-----------------|__________|

Thanks and regards,
Prabakaran T.S.
Future Software Limited,
480-481, Anna Salai,
Chennai - 600035, India.
Web: www.futsoft.com
email: prabakarts <at> future.futsoft.com
Off Phone: 91-44-24330550 - Extn: 337
-------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas D. Nadeau | 2 Sep 2003 18:25
Picon
Favicon

RE: error in draft-ietf-mpls-te-mib-12.txt


	Yes, I caught this one just after I published
the TE MIB, and thought that I could re-publish
immediately version 12. Apparently the repository
ignored my second posting. Is the process now to
re-issue a new revision with this fixed post 
the last call period?

	--Tom

> -----Original Message-----
> From: owner-mpls <at> UU.NET [mailto:owner-mpls <at> UU.NET] On Behalf 
> Of Wijnen, Bert (Bert)
> Sent: Thursday, August 28, 2003 4:43 PM
> To: Mpls (E-mail)
> Cc: mail <at> stefan-winter.de
> Subject: FW: error in draft-ietf-mpls-te-mib-12.txt
> 
> 
> MPLS TE MIB authors... a comment that came back from 
> IETF Last Call
> 
> Thanks,
> Bert 
> 
> -----Original Message-----
> From: Stefan Winter [mailto:	
> Sent: donderdag 28 augustus 2003 11:00
> To: iesg <at> ietf.org
> Subject: error in draft-ietf-mpls-te-mib-12.txt
(Continue reading)

Permalink | Reply | 6 comments |
headers
Wijnen, Bert (Bert | 2 Sep 2003 18:09
Picon
Favicon

RE: error in draft-ietf-mpls-te-mib-12.txt

Yep. And I beleiev Last call ends on 9th of Sept, right?

Thanks,
Bert 

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau <at> cisco.com]
> Sent: dinsdag 2 september 2003 18:25
> To: 'Wijnen, Bert (Bert)'; 'Mpls (E-mail)'
> Cc: mail <at> stefan-winter.de
> Subject: RE: error in draft-ietf-mpls-te-mib-12.txt
> 
> 
> 
> 	Yes, I caught this one just after I published
> the TE MIB, and thought that I could re-publish
> immediately version 12. Apparently the repository
> ignored my second posting. Is the process now to
> re-issue a new revision with this fixed post 
> the last call period?
> 
> 	--Tom
> 
> 
> 
> > -----Original Message-----
> > From: owner-mpls <at> UU.NET [mailto:owner-mpls <at> UU.NET] On Behalf 
> > Of Wijnen, Bert (Bert)
> > Sent: Thursday, August 28, 2003 4:43 PM
> > To: Mpls (E-mail)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Prabakaran T Sampath | 2 Sep 2003 18:19

RE: RE: [MPLS-OPS]: Why Merging?

Hi Alok,

Yes, what ever you say is correct.  I meant for "n" no. of incoming
flows sending on the same outgoing interface with a single
label(we got to take care of all the h/w limitations, Traffic
engineering parameters if required like BW, cell interleave problem
in case of ATM, etc.,).  If your hardware supports LSP stitching
you can do so, but I guess, there is no Label merging concept
involved in LSP stitching.

In my understanding, a typical example for LSP stitching is,
when 2 LSPs fall in two different TED areas then we can stitch
the 2 different LSPs using cross-connect in the intermediate
router, so that from the ingress end if we do encapsulation,
we can do the decaptulation at the egress end.

For eg:
                                           |       |
        Traffic engineering domain 1       |       |         Traffic
engineering domain 2
                                           |       |
                 ----LSP 1-------------->  |       |----LSP 1--------->
        Router A ------------------------- Router B ------------------
Router C
                 ------Stitched LSP ---------------------------------->
                                           |       |
                                           |       |

In the above example, if we do not have LSP stitching means,
If we sending packet from Router A to Router C is encapsulated
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas D. Nadeau | 3 Sep 2003 06:29
Picon
Favicon

RE: error in draft-ietf-mpls-te-mib-12.txt


> Yep. And I beleiev Last call ends on 9th of Sept, right?

	Alex can confirm, but I think you are right.

	--Tom

> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tnadeau <at> cisco.com]
> > Sent: dinsdag 2 september 2003 18:25
> > To: 'Wijnen, Bert (Bert)'; 'Mpls (E-mail)'
> > Cc: mail <at> stefan-winter.de
> > Subject: RE: error in draft-ietf-mpls-te-mib-12.txt
> > 
> > 
> > 
> > 	Yes, I caught this one just after I published
> > the TE MIB, and thought that I could re-publish
> > immediately version 12. Apparently the repository
> > ignored my second posting. Is the process now to
> > re-issue a new revision with this fixed post
> > the last call period?
> > 
> > 	--Tom
> > 
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew G. Malis | 2 Sep 2003 22:20
Picon
Favicon

Re: wg last call on: draft-ietf-mpls-in-ip-or-gre-02.txt - update

Hi Dave,

MPLS in IP is already in the draft.

I'm curious what additional functionality MPLS in L2TPv3 would get you that 
GRE or direct IP encapsulation doesn't already provide.

Cheers,
Andy

-------

At 8/29/2003 10:26 AM -0700, David Meyer wrote:
>One thing that would appear to be useful is to generalize the
>draft just a bit to  mpls-in-ip-encapsulation and include L2TPv3.
>
>Dave
>
>On Fri, Aug 29, 2003 at 02:38:58PM +0200, Loa Andersson wrote:
> >> Working Group,
> >>
> >> when this WG Last Call was initiated it turned out that
> >> we had a temporary outage on the MPLS mail archive, this
> >> outage was still in effect when I resent the last call.
> >>
> >> However - the mail did go through to the mailing-list,
> >> so it is my take that the last call has been properly
> >> announced and still ends on:
> >>
> >> Monday September 9 23.59 Swedish time.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Loa Andersson | 3 Sep 2003 09:36
Picon

Re: Invitation to discuss: "P2MP problem statement"

Working Group,

it is almost three weeks since I sent this "invitation to
discuss the P2MP probelm statement". The tendency has been
mostly in favor of adding p2mp mpls as a new milestone to
our charter, but the discussion has not been that active,
so it is hard to decide one way or another. Apart from the
authors (the author groups is about 12 people) it is only
one person that has taken part in the discussion.

I'm aware of that we had a mailing list problem, but it is
my take that the mails gone through eventually, if you think
this is wrong please resend.

Before deciding I would like a quick "show of hands", just
positive or negative. If you have reasons not to send your
response to the list, you may send it directly to me.

I plan to make the call mid-next week.

/Loa

Loa Andersson wrote:

> Alan + both teams,
> 
> thanks for preparing this!
> 
> Working Group,
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jean Philippe Vasseur | 3 Sep 2003 12:07
Picon
Favicon

Re: Invitation to discuss: "P2MP problem statement"

Hi Loa,

Not sure my mails has been received ... So I just resend: strongly in favor.

JP.

At 09:36 AM 9/3/2003 +0200, Loa Andersson wrote:
>Working Group,
>
>it is almost three weeks since I sent this "invitation to
>discuss the P2MP probelm statement". The tendency has been
>mostly in favor of adding p2mp mpls as a new milestone to
>our charter, but the discussion has not been that active,
>so it is hard to decide one way or another. Apart from the
>authors (the author groups is about 12 people) it is only
>one person that has taken part in the discussion.
>
>I'm aware of that we had a mailing list problem, but it is
>my take that the mails gone through eventually, if you think
>this is wrong please resend.
>
>Before deciding I would like a quick "show of hands", just
>positive or negative. If you have reasons not to send your
>response to the list, you may send it directly to me.
>
>I plan to make the call mid-next week.
>
>/Loa
>
>Loa Andersson wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 3 Sep 2003 14:30
Picon
Favicon

RE: MIB Doctor review:draft-ietf-mpls-telink-mib-03.txt

Responses to those points where you had questions.
> > - I see:
> >     teLinkModuleReadOnlyCompliance MODULE-COMPLIANCE
> >       STATUS current
> >       DESCRIPTION
> >        "Compliance statement for agents that support the
> >         monitoring of TE link MIB module."
> >       MODULE -- this module
> >
> >       -- The mandatory groups have to be implemented
> >       -- by all devices supporting TE links. However, they may all
> >       -- be supported as read-only objects in the case where manual
> >       -- configuration is unsupported.
> >
> >       MANDATORY-GROUPS    { teLinkGroup,
> >                             teLinkBandwidthGroup,
> >                             componentLinkBandwidthGroup }
> >
> >    It seems to me that that all of those 4 comment lines are redundant.
> >    The idea of the MODULE-COMPLIANCE statements is that they are both
> >    human and machine readable.
> >
> 
> I am not sure I understand why the fact that the MODULE-COMPLIANCE
> statements are human and machine readable makes these 
> comments redundant.
> 
Well, let us check/evaluate:
    -- The mandatory groups have to be implemented
    -- by all devices supporting TE links.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane