Extending VLAN's over public network..(Ethernet Over MPLS)

Hello Everybody,

I need some clarifications on extending VLAN's over public network. Initially VLAN concept is introduced
only for privately administered domains as per 802.1Q (Packet never pass through public domain). 

My question is, Is it possible to extend VLAN over public domain ? Martini's draft on "Ethernet Over MPLS"
talks about tranmitting Ethernet packet over MPLS. Is this the idea behind extending VLAN's across
public domain ?

If so, how a VLAN identifier (VLAN Id or tag) can be mapped to an LSP at the provider edge. Are they configured
manually or, are there any standards/protocol for this. 

Thanks in advance for your replies.

Regards,
Madhan

RE: Extending VLAN's over public network..(Ethernet Over MPLS)

Hi Madhan,

Refer to draft-ietf-pwe3-enet-mib and other related drafts in pwe3 working
group for further details.

Regards,
Srikanth.

-----Original Message-----
From: owner-mpls <at> uu.net [mailto:owner-mpls <at> uu.net]On Behalf Of Madhan
Kumar
Sent: Monday, 2 December 2002 1:04 PM
To: mpls <at> uu.net
Subject: Extending VLAN's over public network..(Ethernet Over MPLS)

Hello Everybody,

I need some clarifications on extending VLAN's over public network.
Initially VLAN concept is introduced only for privately administered domains
as per 802.1Q (Packet never pass through public domain).

My question is, Is it possible to extend VLAN over public domain ? Martini's
draft on "Ethernet Over MPLS" talks about tranmitting Ethernet packet over
MPLS. Is this the idea behind extending VLAN's across public domain ?

If so, how a VLAN identifier (VLAN Id or tag) can be mapped to an LSP at the
provider edge. Are they configured manually or, are there any
standards/protocol for this.

Thanks in advance for your replies.

RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt

Tom,

I notice that the latest MPLS TE and TC MIBs still have resource affinities
specified as "Exclude-all" rather than "Exclude-any".  Is this another
oversight, or did the authors decide that "Exclude-all" was preferred?

One other minor thing I've noticed:

-  The mplsTunnelOwner field is now read-only.  However, the comment talks
about not being able to modify the object if mplsTunnelRowStatus is active.
Surely one can't modify the object at all if it is read-only?  [Also, the
example in section 9 includes mplsTunnelOwner - I guess this should not be
present (and in any case, the given value is no longer correct given the
latest definition of the MplsOwner TC)].

Regards,

Ed

-----Original Message-----
From: Cisco - Thomas Nadeau 
Sent: 15 October 2002 15:22
To: Edward Harrison
Cc: 'jcucchiara <at> crescentnetworks.com'; Parama - Cheenu Srinivasan;
'arun <at> force10networks.com'; 'hans <at> ipunplugged.com'; mpls <at> UU.NET
Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt

>It's good to see the new revisions of the MPLS MIBs coming out.

         Slowly but surely. 8)

Re: Regarding LDP scalability

RE: Regarding LDP scalability

RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt

>I notice that the latest MPLS TE and TC MIBs still have resource affinities
>specified as "Exclude-all" rather than "Exclude-any".  Is this another
>oversight, or did the authors decide that "Exclude-all" was preferred?

         Oversight.   I think that you were supposed to remind us
about this during the last round of edits. *)

>One other minor thing I've noticed:
>
>-  The mplsTunnelOwner field is now read-only.  However, the comment talks
>about not being able to modify the object if mplsTunnelRowStatus is active.
>Surely one can't modify the object at all if it is read-only?

         This was discussed during the meeting, and as I recall the
conclusion was that the object's access was okay as it as it is given
that the text has to state that the agent MUST set the value to
the correct value.  Why would you want to change this after
the object/row is created?

>[Also, the
>example in section 9 includes mplsTunnelOwner - I guess this should not be
>present (and in any case, the given value is no longer correct given the
>latest definition of the MplsOwner TC)].

         Okay.

         --Tom

>Regards,
>
>Ed
>
>-----Original Message-----
>From: Cisco - Thomas Nadeau
>Sent: 15 October 2002 15:22
>To: Edward Harrison
>Cc: 'jcucchiara <at> crescentnetworks.com'; Parama - Cheenu Srinivasan;
>'arun <at> force10networks.com'; 'hans <at> ipunplugged.com'; mpls <at> UU.NET
>Subject: RE: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt
>
>
>
> >It's good to see the new revisions of the MPLS MIBs coming out.
>
>          Slowly but surely. 8)
>
> >One comment, though - the text describing MplsTunnelAffinity says that it
>is
> >used for Include-any, Include-all and Exclude-all constraints.  I think it
> >should say "Exclude-any" rather than "Exclude-all".
> >
> >I believe this has stemmed from a bug in the MPLS TE-MIB, which the authors
> >(or Tom at least!) said they were going to fix in the next revision.  [As a
> >reminder, section 4.7.2 of RFC 3209 shows the vectors describing resource
> >affinities are Exclude-any, Include-any and Include-all, however
> >draft-ietf-mpls-te-mib-08.txt includes the objects
> >mplsTunnelExcludeAllAffinity, mplsTunnelIncludeAllAffinity and
> >mplsTunnelIncludeAnyAffinity.]
>
>          Yes, thanks. That was a typo on my part. I will fix this during
>the next (and hopefully final) round of edits.
>
>          --Tom
>
>
>
> >Regards,
> >
> >Ed
> >
> >-----Original Message-----
> >From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
> >Sent: 14 October 2002 12:26
> >To: IETF-Announce
> >Cc: mpls <at> UU.NET
> >Subject: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt
> >
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >This draft is a work item of the Multiprotocol Label Switching Working
>Group
> >of the IETF.
> >
> >         Title           : Definitions of Textual for Multiprotocol Label
> >                           Switching (MPLS) Management
> >         Author(s)       : T. Nadeau et al.
> >         Filename        : draft-ietf-mpls-tc-mib-04.txt
> >         Pages           : 18
> >         Date            : 2002-10-11
> >
> >This memo describes Textual Conventions for use in definitions of
> >management information for Multiprotocol Label Switching (MPLS)
> >networks.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-04.txt
> >
> >To remove yourself from the IETF Announcement list, send a message to
> >ietf-announce-request with the word unsubscribe in the body of the message.
> >
> >Internet-Drafts are also available by anonymous FTP. Login with the
>username
> >"anonymous" and a password of your e-mail address. After logging in,
> >type "cd internet-drafts" and then
> >         "get draft-ietf-mpls-tc-mib-04.txt".
> >
> >A list of Internet-Drafts directories can be found in
> >http://www.ietf.org/shadow.html
> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> >Internet-Drafts can also be obtained by e-mail.
> >
> >Send a message to:
> >         mailserv <at> ietf.org.
> >In the body type:
> >         "FILE /internet-drafts/draft-ietf-mpls-tc-mib-04.txt".
> >
> >NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before the "FILE"
> >         command.  To decode the response(s), you will need "munpack" or
> >         a MIME-compliant mail reader.  Different MIME-compliant mail
>readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which have been split
> >         up into multiple messages), so check your local documentation on
> >         how to manipulate these messages.
> >
> >
> >Below is the data which will enable a MIME compliant mail reader
> >implementation to automatically retrieve the ASCII version of the
> >Internet-Draft.
>
>Success is relative; the more success, the more relatives. -Anonymous

Re: review of mpls-mgmt-overview revision 02

At 10:14 PM 11/29/2002 -0500, Adrian Farrel wrote:
>Bert,
>Thanks. All nits are most welcome. I, for one, welcome your efforts to get 
>RFCs
>in clear and correct English.
>
>A couple of follow-up questions/comments in the snipped text below...
>
>Cheers,
>Adrian
>----- Original Message -----
>From: "Wijnen, Bert (Bert)" <bwijnen <at> lucent.com>
>
>
> > A lot of it is indeed nits/spelling/grammar
> > stuff... do I have to repat that for all docs, or can I assume
> > that the authors/editors will seriously check those things
> > themselves?
>
>Hmmm. I know what you SHOULD be able to asume...
>
> > - I see you use mib module names with an underscore, for example
> >   MPLS-LDP_MIB, but the real module name is MPLS-LDP-MIB
> >   Better get that in sync. True for most mib module names I believe
>
>Ah! I made this global change after I thought I heard Tom suggest that you 
>said
>that the use of underscore was a requirement. At least one of us is out of 
>synch
>here - I will change back to hyphen.

         Shouldn't it be written as MPLS-LDP MIB when referring to the actual
MIB and not the SMI MODULE-NAME macro?

> > - Make descriptors consistent. Like
> >    - mplsLdpEntityFrameRelayXxxxx
> >    - mplsLdpEntityConfFrXxxx
> >   so either make all freme-relay stuff xxxFrameRelayYyy or xxxFrYyy
> >   but do not mix all that. I also wonder why in some case
> >   Fr comes before the Xxxx and in other cases after it.
> >    - mplsLdpEntityFrameRelayXxxxx
> >    - mplsLdpEntityConfFrXxxx
> >   why not mplsLdpEntityFrameRelayConfXxxx
> >  Are mplsTunnelResourceTable and mplsTunnelCRDLPResTable both "resource"
> >   tables? If so, then why not use "Resource" in both cases, or just "Res"
> >   in both cases?  Consistency please!!!!!
> >   So Tunnel Computed Hop Table is: mplsTunnelCHopTable
> >   and Tunnel Actual Hop Table is: mplsTunnelARHopTable
> >   is the R for Route? If so then add Route in there
>
>Agreed. This draft, however, can only report what is in the MIB modules
>themselves.
>
>Tom and Joan - relying on you to pick up these things and then I'll change the
>overview to match.
>
> >   Question: Is there also a mplsTunnelRSVPResTable? If yes, then I am
> >   missing it here, if no, then why is that not needed?
>
>Good question.
>No there is no RSVP resource table. CR-LDP resource specification is a 
>superset
>of RSVP resource specification.
>I will add a note explaining.
>
> > - sect 7.2
> >   ".. mplsTunnelMaxHops defines the size of route that may be configured
> >    on the LSR."
> >   I have difficulty understanding what that means.
> >   What is the "size of route"?
>
>Syntax is "size of route that", but I agree that this could be clearer.
>
> > - Your references to PWE3 and PPVPN WG docs are listed as normative.
> >   I doubt that they really are. In any event, if they are normative,
> >   then they will have to be ready for RFC at the same time that this
> >   doc goes to RFC.
>
>You're right. Old reference from when we thought we were going to include them
>in detail.
>
> > - Your split of references for the SNMP boilerplate text is not
> >   correct. The correct split is:
>[SNIP]
> > - We're working on the new MIB boilerplate. Much shorter. Not 100% stable
> >   yet. If you prefer to use it (I assume the new boiler plate will be
> >   stable by the time you go to RFC-Editor queue), then I can send you what
> >   the curretn text looks like.
>
>I will wait as late as I can and then include the most up-to-date version.
>But...
>Do you consider that the boilerplate is appropriate for inclusion in this
>overview or should I aim to hack it down? Actually, if the new material is
>shorter, perhaps it will be fine.

         I think that we had agreed during the meeting that we would not
wait for the updated boiler plate giving the timing issues.

         --Tom

Upstream Labels in GMPLS

Hi, 

I have some doubts on Upstream Labels in GMPLS.
First, GMPLS supports both "unidirectional LSPs" and "bidirectional LSPs" ???
I would like to know if when a initiator node send a request message
(Path/RSVP or Label Request/CR-LDP) with a Upstream Label, and this label is 
not suitable for use at the next LSR, it must reject the request message 
and send a "Error message" to the initiator node. In this case, the Error
message may include an acceptable Label Set to tell the Upstream LSR wich
labels would have been succeful.
But if Upstream LSR decide to fail the LSP set up, my doubt is: The
unidirectional LSP will set up and just the bidirectional LSP not is set
up ?? or both uniderectional and bidirectional will fail, and LSR
initiator will try again ??

Thanks, 

       Marcos

_________________________________________________________________

  Marcos Antônio de Almeida Corá    
  School of Electrical and Computer Engineering
  Departament of Telematics
  State University of Campinas/Brazil - UNICAMP
  Phone: +55 (19) 3788.3711 - Branch: 73723   
  Home Page: www.dt.fee.unicamp.br/~cora
_________________________________________________________________

Re: review of mpls-mgmt-overview revision 02

Aaagh!

Let's try to get this straight.

There is only one MIB.
There is a series of MIB documents, such as MPLS-TE MIB.
Each MIB document describes one or more MIB modules, such as MPLS-TE-MIB.

Is that agreed?

Adrian
(Sorry if I am stating the obvious, but I'd rather only make the change once!)

> > > - I see you use mib module names with an underscore, for example
> > >   MPLS-LDP_MIB, but the real module name is MPLS-LDP-MIB
> > >   Better get that in sync. True for most mib module names I believe
> >
> >Ah! I made this global change after I thought I heard Tom suggest that you
> >said
> >that the use of underscore was a requirement. At least one of us is out of
> >synch
> >here - I will change back to hyphen.
>
>          Shouldn't it be written as MPLS-LDP MIB when referring to the actual
> MIB and not the SMI MODULE-NAME macro?
>

Re: review of mpls-mgmt-overview revision 02

At 12:05 PM 12/2/2002 -0500, Adrian Farrel wrote:
>Aaagh!
>
>Let's try to get this straight.
>
>There is only one MIB.
>There is a series of MIB documents, such as MPLS-TE MIB.
>Each MIB document describes one or more MIB modules, such as MPLS-TE-MIB.
>
>Is that agreed?

         That jives with my understanding.

         --Tom

>Adrian
>(Sorry if I am stating the obvious, but I'd rather only make the change once!)
>
> > > > - I see you use mib module names with an underscore, for example
> > > >   MPLS-LDP_MIB, but the real module name is MPLS-LDP-MIB
> > > >   Better get that in sync. True for most mib module names I believe
> > >
> > >Ah! I made this global change after I thought I heard Tom suggest that you
> > >said
> > >that the use of underscore was a requirement. At least one of us is out of
> > >synch
> > >here - I will change back to hyphen.
> >
> >          Shouldn't it be written as MPLS-LDP MIB when referring to the 
> actual
> > MIB and not the SMI MODULE-NAME macro?
> >